Control: reassign -1 init-select Control: severity -1 grave On Wed, Feb 19, 2014 at 09:40:44PM -0500, Ron Murray wrote: > Since the last grub update in testing, update-grub appears to fail > during 30_init-select and doesn't include Windows partitions in > grub.cfg, although it sees them: > > > khufu:~# update-grub > > Generating grub.cfg ... > > Found background image: /usr/share/images/desktop-base/desktop-grub.png > > Found linux image: /boot/vmlinuz-3.13.3-khufu-2 > > Found initrd image: /boot/initrd.img-3.13.3-khufu-2 > > Found linux image: /boot/vmlinuz-3.13.2-khufu-0 > > Found initrd image: /boot/initrd.img-3.13.2-khufu-0 > > Found memtest86+ image: /memtest86+.bin > > Found memtest86+ multiboot image: /memtest86+_multiboot.bin > > Found GRUB Invaders image: /boot/invaders.exec > > Found Windows 8 (loader) on /dev/sda1 > > Found Windows 8 (loader) on /dev/sdc1 > > done > > Last lines of grub.cfg, however, come out as: > > > ### BEGIN /etc/grub.d/22_invaders ### > > menuentry "GRUB Invaders" { > > insmod part_msdos > > insmod xfs > > set root='hd1,msdos1' > > if [ x$feature_platform_search_hint = xy ]; then > > search --no-floppy --fs-uuid --set=root --hint-bios=hd1,msdos1 > > --hint-efi=hd1,msdos1 --hint-baremetal=ahci1,msdos1 --hint='hd1,msdos1' > > 47193b17-a99a-4a83-8818-fc54982e3996 > > else > > search --no-floppy --fs-uuid --set=root > > 47193b17-a99a-4a83-8818-fc54982e3996 > > fi > > multiboot /invaders.exec > > } > > ### END /etc/grub.d/22_invaders ### > > > > ### BEGIN /etc/grub.d/30_init-select ###
Thanks for your report. /etc/grub.d/30_init-select is provided by the init-select package, not by grub2 itself. Reassigning. Even under the best circumstances where all prior output has been flushed (not, I think, guaranteed), the effect of the "sed -i" in init-select is going to be to break grub-mkconfig's open redirection to /boot/grub/grub.cfg.new, which is probably what's going wrong here; that will then break all output from later scripts, hence the grave severity. init-select should really be extending the kernel arguments in an /etc/default/grub.d/ file instead, as I think I've advised before; I don't think its current strategy is ever going to work reliably. Cheers, -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org