Bug 1271847

Summary:	ext4 journal support missing/broken?
Product:	[Fedora] Fedora	Reporter:	David Woodhouse <dwmw2>
Component:	grub2	Assignee:	Peter Jones <pjones>
Status:	CLOSED EOL	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	22	CC:	bcl, dwmw2, lkundrak, mads, pjones
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-07-19 18:13:13 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description David Woodhouse 2015-10-14 21:12:10 UTC

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?

Comment 1 Brian Lane 2015-10-15 00:18:45 UTC

Does the system have secure boot enabled?

Does this happen if you don't use SysRq (eg. sync; sleep 60; reboot)?

Comment 2 David Woodhouse 2015-10-15 11:53:07 UTC

(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.

Comment 3 David Woodhouse 2015-10-15 12:10:48 UTC

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.

Comment 4 Fedora End Of Life 2016-07-19 18:13:13 UTC

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.