Bug#783620: initramfs-tools: initramfs broken on first boot into Jessie, "Unable to mount root fs on unknown-block(0, 0)"
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 02.05.2015 21:26, Ben Hutchings wrote:
Hi,
>
> I can see that the GRUB menu entry for 3.16.0-4-amd64 does seem to
> include an initramfs. Unfortunately the frame rate is quite low so
> I don't see any messages from GRUB indicating whether it succeeded
> or failed to load the file.
Even directly in front of the console I can't make out any error
message, and if I change the filename to something non-existant I get
a error message and have to press a key to continue.
>>>> We still have the snapshot available, if you have an idea
>>>> please drop me a note.
>>>
>>> this means linux didn't get the initramfs passed by the
>>> bootloader.
>>>
>>> In the old days this happened when lilo was not run, these days
>>> it could be some grub modules out of sync (very wild guess).
>>> did you try before botting into that image to run install-grub
>>> in it?
>>
>> I don't have access to the snapshot until Monday, but I don't
>> think it will help. As you can see in the video a simple
>> fsck/mount in initrd in the old kernel is enough, and grub isn't
>> touched there.
>
> fsck.xfs does nothing (see the manual page). Mounting the
> filesystem, however, will replay any changes that were only written
> to the journal and not yet written to their usual locations on
> disk.
Should I be able to see that somehow (xfs_info from a rescue system or
something like that)? Doesn't xfs log anything when it replays the log
(I know ext4 does, but I don't recall seeing that for XFS ever)
> Is it possible that this system was not cleanly shut down following
> the upgrade? I don't think that GRUB reads journals so this would
> probably explain what you've shown.
The system is normally rebooted using /sbin/reboot soon after
dist-upgrade is finished. There are no errors and our customizations
don't touch the reboot part at all. If there was a problem with
unclean shutdown it would be a common error, we are seeing ~20%
failure rates on upgrades.
If I understand you correctly since grub isn't erroring out on the
initrd filename it is likely there on disk, but an out-of-date
version. I recall the initrd being generated twice, so maybe the file
that is on the disk (read by grub) is somehow incomplete and the first
boot syncs the updated image from journal to disk. Or maybe it is
really unreadable ... other guess would be a corruption that can be
replayed by 3.2.0, but not by 3.16.0 (seems unlikely)
If I mount the filesystem in a rescue system with norecovery and the
initrd is either different or missing that would narrow it down, no?
And a workaround would be calling "sync" before the reboot.
Bernhard
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJVRTYCAAoJEHdQeeW4ULyTj+YP/2HBbqdpJAckR1+l/W5UDjaN
c2hzPP9x5gEdrGStzigi6Z3KdM7m+EZZAmd8HRR0ZbBzjG5rvVris6HDe9q7ytIf
1ThPpd0Z67m1oWz+JSZ7V6Gh9sypJe+0EaStVoxd4ZN2tUdEFB4TN5DPubMAsslu
6fPIf/OSjc6ZL4SQbmGRmGjqDOJah8vdOu+YN/+X7FvBel/6Z54wqjqrtnXjIaEU
/1m0fas7/W1y278osGy9HNHsz/e/BVcW3dfFRm1XEJKGp7dglRTyPkC9+ITrW6Ci
qN3Bf5pevNl3vyfKuBlM8cqRhHsFrhyMxToMCFf8gUxwo+ZFXAhqIlEas+vT9R24
amKquDv79GdHta67WydqnUfW1EJe14eXinIgoB3tbplmRHD4l6vL7kqEro8SSjXS
Ggta+rDG3W/M3L20T9guDLKNa0x3e4RvQIKVHWNURiZCOz54eoOu1X+j/y+nZuYF
Ka5zPyN0D0f9MPPMX2K3PFBO8dNw42gWXR4ht2KCXxYz3edXSp4trWuP7BnnvmMy
YhEfOBKBF9IZ1DxOpbz97gXThU0RJDxMBkt6PR9IdDUqUUkC7mUuOgJWE2kOwtK4
6OMXxmhxe3BLeWIogzhpat2hJ7nT22bwRncZCgGIEwC4r5DZ+uCwYiOtTsqRg+iu
zuLjc4l8jDv0XAeHyUKu
=4CEw
-----END PGP SIGNATURE-----
Reply to: