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?

It occurs to me that the BOGUS value in /target/dev/disk/by-uuid might
be a spurious filesystem signature left over from a previous install?
I've noticed that the partman ext2 formatting goes really fast compared
to the ext3 and ext4 formatting, so presumably less data is being
written, perhaps allowing old superblocks to survive. One might
furthermore presume that the installer code doing population of
/target/dev/disk/by-uuid/ is different from the code doing the
population upon reboot, and one could then theorize that the installer
version incorrectly pays attention to leftover superblocks that aren't
really part of the ext2 partition. However, this theory doesn't explain
how the graphical desktop task ends up fixing everything prior to reboot.

Hi,

Alexander Perlis <aperlis@math.lsu.edu> wrote:

Could you try to reproduce this bug with the latest debian-installer being
prepared for 7.0 ?
Take the mini.iso from
http://ftp.nl.debian.org/debian/dists/testing/main/installer-i386/current/images/netboot/gtk/


Thanks
Holger

Hi,

Unfortunately same outcome. At the final
be-sure-to-eject-CD-before-reboot message, I dropped into a shell, and
both /dev/disk/by-uuid and /target/dev/disk/by-uuid contain the same
BOGUS uuid, whereas the 'search' line in /target/boot/grub/grub.cfg
contains the CORRECT uuid.

Alex

tags 697985 + moreinfo
tags 647406 + wontifx
thanks

Hi,

thank you for submitting bug reports concering debian-installer, much
appreciated.

I read through all the bugs mentioned here (and I'm sure they were read by
several people at the time they were submitted) and am closing them now as/if
- they (finally) indicated success and/or
- I know from first hand experience that the functionality is working in
Wheezy and/or
- they only contained very little information and/or
- they contained user errors and/or
- they have been from a development phase where things were not stable and/or
- they are very old and/or
- they are wishlist but rather special + exotic and not have been acted on for
years. (See http://blog.liw.fi/posts/wishlist-bugs/ why it's often useful to
close wishlist bugs.)

If I've closed a bug incorrectly please do reply (it's easy to reopen and I'll
do if requested) or just file a new one - and that's often better, as the bug
log will be clearer and shorter and not contain cruft.


cheers,
        Holger