Your message dated Sun, 21 Jul 2013 15:53:10 +0200
with message-id <[email protected]>
and subject line dealing with old debian-installer bugs
has caused the Debian Bug report #701223,
regarding post-install boot failure with ext2 + TTY-only (desktop tasksel
skipped) installation
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
701223: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701223
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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?
--- End Message ---
--- Begin Message ---
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
signature.asc
Description: This is a digitally signed message part.
--- End Message ---
