Comment 6 for bug 1103187

Thanks for the http://sourceforge.net/projects/bootinfoscript/ suggestion.

Today I made quite few experiments, and the result in brief is:

no reboot problem after "dpkg-reconfigure grub-pc" and neither after the other two boot-tampering, in the 3 cases below:

        /boot/ tree is in a separated ext4 filesystem, root is xfs

        /boot/ tree is in a separated xfs filesystem, root is xfs

        /boot/ tree is in the root filesystem, which is ext4

deterministically appearing reboot problem in the original case:

        /boot/ tree is in the root filesystem, which is xfs

However I can not predict the prospective reboot error, today I saw additional 2 new kind of error messeges:

        "error: attempt to read or write outside of partition."

        "error: file `/boot/grub/i386-pc/normal.mod' not found."

At grub rescue prompt the command "ls /boot/grub/i386-pc/normal.mod" tend to give various error messages, like

        "error: not a correct XFS node."

sometimes even the /boot/grub appears to be empty, or one can see the entry i386-pc in it, but it can't be listed by ls /boot/grub/i386-pc, and so on.

While at the earlier missing initrd.img problem I could boot by hand, this reboot error gives no opportunity to boot by hand.

However if I boot by SYSRESCCD, and I do nothing else (or work for a while) and I reboot, than this second reboot is guaranted to be successful.

SYSRESCCD I think does not tamper the boot system, at least the bootinfoscript has an identical output before the unsuccessful boot, and after the successful boot.

Now I try to attach the 4 results.txt files, corresponding the 4 cases, according to whether the /boot/ tree is in separate partition, and whether the partition containing the /boot/ tree is xfs or ext4.

Comment: for testing the case of when /boot is in the root partition of type ext4, I installed a new Ubuntu on an other drive replaced into my linux box.