Bug#410878: d-i uses mirror/http/proxy setting when it (probably) shouldn't
The bug Roland reported is real, and occurs in 2013 with Debian 6 installer. There should indeed be a distinction between an APT proxy and a general-purpose HTTP proxy. Our APT proxy knows how to serve up files related to Debian mirrors, but can't do general-purpose HTTP retrievals such as preseed/run files from our PXE server. Currently mirror/http/proxy affects http_proxy globally, for all subsequent calls to wget. Might be better to not do that; instead, on each APT-related call to wget, if mirror/http/proxy has a value, then temporarily store it in http_proxy, call wget, and then restore http_proxy to its prior value. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5135087b.8080...@math.lsu.edu
Bug#701223: post-install boot failure with ext2 + TTY-only (desktop tasksel skipped) installation
Hi, On 02/23/2013 02:14 AM, Holger Wansing wrote: 1) I used the 6.0.6 netboot installer (tried both 32-bit and 64-bit) 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/ 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 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/512b9fc8.1050...@math.lsu.edu
Bug#701223: follow-up thoughts
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. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51283fab.9090...@math.lsu.edu
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? -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5128355e.8070...@math.lsu.edu
Bug#642159: debian-installer preseed broken with apt-cacher-ng mirror
This debian-installer bug is perhaps more serious than might seem from the original bug report. It affects preseed/run and preseed/include. Not clear how to adapt the work-around from the original bug report. The bug also affects fetching in preseed/late_command, as well as subsequent attempts to re-fetch the original preseed file (which comes up if you have priority=low or some other installer error to bring up the installer menu, and as you proceed through the steps it will direct you to the preseed fetch menu option). Particularly confusing is that Ctrl-Alt-F4 shows a wget 403 error yet tcpdump on port 80 on the preseed server shows no activity, and furthermore if you go into BusyBox in the installer and do a manual wget there is no error. I can't determine a work-around, which might for example be to tell apt-cacher-ng to serve up (and not cache) local files, but no luck so far. I considered replacing apt-cacher-ng with two copies of approx (one for debian, one for ubuntu), but approx seems to be a more apt specific cache that won't serve up arbitrary local files. Consequently I avoid fetching additional preseed files entirely, with a growing "one-liner" script in preseed/late_command. It seems that much of the additional power of preseeding is unavailable right now, in the context of an apt proxy cache, until this debian-installer bug can be addressed. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5125093a.6030...@math.lsu.edu
