-----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----- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55453602.2050...@birkenwald.de