scp arch/x86/boot/bzImage target:/boot/vmlinuz On target, SysRq-S (and wait for it to complete), SysRq-B. Grub2 (EFI) fails to boot. Boot a *different* kernel, check the md5sum of the vmlinuz file, and it's fine. Reboot, and it works. Was my kernel still in the journal, and is grub failing to read the journal correctly?
Does the system have secure boot enabled? Does this happen if you don't use SysRq (eg. sync; sleep 60; reboot)?
(In reply to Brian Lane from comment #1) > Does the system have secure boot enabled? > > Does this happen if you don't use SysRq (eg. sync; sleep 60; reboot)? Not on the first test (without the sleep; that shouldn't be needed). [target] # scp buildbox:bzImage /boot/vmlinuz ; sync ; reboot -nf That *did* work. But maybe it just got lucky. I'll do some more testing. No Secure Boot.
Changing the sync and reboot to just echo 's' and 'b' to /proc/sysrq-trigger, respectively, lets the problem occur. I had to add a sleep between the two, since otherwise it doesn't wait for the 'Emergency Sync complete' as is my wont when I'm going it manually over the serial port. So yes, there is a discrepancy between the sync(1) behaviour and the SysRq sync action. But I think that's irrelevant. The fact remains that the data *have* hit the disk when I use the sysrq method. All I need to do is boot a different kernel and then the new image is bootable by grub.
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.