Bug#701223: post-install boot failure with ext2 + TTY-only (desktop tasksel skipped) installation
Package: debian-installer
Version: 6.0.6
I'm trying to build a text-only (no graphical desktop) Debian system
with ext2 instead of the default ext3, but the resulting install is
unbootable due to a bad grub configuration. To reproduce:
1) I used the 6.0.6 netboot installer (tried both 32-bit and 64-bit)
2) Went with default responses, with two deviations:
2A) Instead of guided partitioning, manually set a / partition and a
swap partition, with / formatted as ext2
2B) When tasksel came up with the defaults of graphical desktop and
standard system utilities, I unchecked graphical desktop
3) Upon reboot, the grub menu comes up, then grub loads the kernel
and initrd, then the usual "Loading, please wait...", but a little while
later we get "Gave up waiting for root device" and it drops into the
rescue shell.
The culprit is line 6 of the GRUB configuration:
1: insmod part_msdos
2: insmod ext2
3: set root='(hd0,msdos1)'
4: search --no-floppy --fs-uuid --set ####
5: echo 'Loading Linux 2.6.32-5-amd64 ...'
6: linux /boot/vmlinuz-2.6.32-5-amd64 root=/dev/sde1 ro
7: echo 'Loading initial ramdisk ...'
8: initrd /boot/initrd.img-02.6.32-5-amd64
The target hard drive was indeed /dev/sde when the installer was running
(due to USB card reader devices taking up earlier slots), yet it seems
that at boot time the hard drive is now /dev/sda. If I use the built-in
GRUB editor to on-the-fly change that line to have "root=/dev/sda1",
then the system boots fine. Once booted, if I then run "update-grub",
the new GRUB configuration has "root=UUID=####" instead of
"root=/dev/sde1", and everything works fine.
If I start over and reinstall with ext3 instead of ext2, then the GRUB
configuration already has "root=UUID=####", whence everything works
fine. It also works fine with ext4. Thus there seems to be a bug in the
Debian Installer when it comes to writing the GRUB configuration,
specifically in the case of using ext2.
In fact, if I drop into a shell at the end of installation but before
the reboot, I observe that grub-probe returns the correct UUID of the
partition, but the /target/dev/disk/by-uuid/ directory contains a BOGUS
value! Hence the grub-mkconfig script doesn't trust the UUID and doesn't
write it into the GRUB config. However, after reboot (via on-the-fly
GRUB editing), the /dev/disk/by/uuid/ directory contains the correct
value, explaining why update-grub at this point does the right thing.
I also stumbled on a mysterious different way to avoid triggering the
bug: if I start over and reinstall, again with ext2, but this time
allowing the graphical desktop in tasksel, then the GRUB configuration
ends up with the desired "root=UUID=####"! I'm at a complete loss to
explain this. Can the installation of the graphical desktop task somehow
cause /target/dev/disk/by/uuid/ to get corrected? I'm guessing that task
subsequently invokes "update-grub" after installing the background
graphics for the GRUB menu, but how are the udev links getting corrected
by the graphical desktop task?
Reply to: