Bug#778810: grub-efi-amd64-bin: boot/bootx86.efi problems
Control: severity -1 important Control: tags -1 +unreproducible +moreinfo On Wed, 2015-02-25 at 12:19 +, Ian Campbell wrote: On Sat, 2015-02-21 at 23:27 +0900, Mark Brown wrote: On Sat, Feb 21, 2015 at 10:31:19AM +, Ian Campbell wrote: On Sat, 2015-02-21 at 11:39 +0900, Mark Brown wrote: Neither of these appears to have disrupted the boot partition though so I'm not sure what's been doing that :/ . Does dpkg-reconfigure grub-efi-amd64 or apt-get install --reinstall grub-efi-amd64 trigger the bad behaviour? No. How frustrating. I guess it's possible some old version had this issue and I didn't notice due to lack of reboots? Or some other package perhaps? Perhaps reconfigure/reinstall anything in dpkg -l \*grub\* and then chalk it up to gremlins unless/until it happens again? Which I think for now translates into a lower severity and +unreproducible +moreinfo. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778810: grub-efi-amd64-bin: boot/bootx86.efi problems
On Sat, 2015-02-21 at 23:27 +0900, Mark Brown wrote: On Sat, Feb 21, 2015 at 10:31:19AM +, Ian Campbell wrote: On Sat, 2015-02-21 at 11:39 +0900, Mark Brown wrote: Neither of these appears to have disrupted the boot partition though so I'm not sure what's been doing that :/ . Does dpkg-reconfigure grub-efi-amd64 or apt-get install --reinstall grub-efi-amd64 trigger the bad behaviour? No. How frustrating. I guess it's possible some old version had this issue and I didn't notice due to lack of reboots? Or some other package perhaps? Perhaps reconfigure/reinstall anything in dpkg -l \*grub\* and then chalk it up to gremlins unless/until it happens again? Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778810: grub-efi-amd64-bin: boot/bootx86.efi problems
On Sat, 2015-02-21 at 11:39 +0900, Mark Brown wrote: On Fri, Feb 20, 2015 at 02:32:34PM +, Steve McIntyre wrote: In fact, for EFI just grub-install -v should tell you a lot more. ...and here's the Acer. Thanks. Neither of these appears to have disrupted the boot partition though so I'm not sure what's been doing that :/ . Does dpkg-reconfigure grub-efi-amd64 or apt-get install --reinstall grub-efi-amd64 trigger the bad behaviour? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778810: grub-efi-amd64-bin: boot/bootx86.efi problems
On Sat, Feb 21, 2015 at 10:31:19AM +, Ian Campbell wrote: On Sat, 2015-02-21 at 11:39 +0900, Mark Brown wrote: Neither of these appears to have disrupted the boot partition though so I'm not sure what's been doing that :/ . Does dpkg-reconfigure grub-efi-amd64 or apt-get install --reinstall grub-efi-amd64 trigger the bad behaviour? No. How frustrating. I guess it's possible some old version had this issue and I didn't notice due to lack of reboots? Or some other package perhaps? signature.asc Description: Digital signature
Bug#778810: grub-efi-amd64-bin: boot/bootx86.efi problems
On Fri, Feb 20, 2015 at 09:25:52AM +, Ian Campbell wrote: On Fri, 2015-02-20 at 14:21 +0900, Mark Brown wrote: This sounds, if I'm interpreting the paths correctly, like it relates somehow to the stuff Steve was doing in #708430, in as much as it sounds like your system is one which would benefit from enabling that new workaround (grub2/force_efi_extra_removable in debconf). Yes, that looks like the same thing. For some reason this system had previously worked with the currently released installer, it's only had issues with the jessie stuff. This is a 1st gen Lenovo Yoga, the other machine that's broken with a fresh install is an Acer Aspire E11 (with BIOS 1.13 IIRC). I can supply more specific data on both if you tell me what you're looking for (I see some talk of a blacklist in the bug though I'm not sure that made it into the code). The blacklist *would* be very nice. Do you have that new option enabled or disabled? It appears to be set to false in my configuration. That said, even with the workaround disabled for some reason removing an existing boot/bootx86.efi doesn't sound right to me. Not that I have any how or why it would be happening :-/. Yes, and me either. Looking at the code the only things I see which touch boot/bootx86.efi are behind the new force_efi_extra_removable option which attempts to update the binary -- I wonder if it is possible to fail half way and actually only remove the old one? (Some sort of weird vfat interaction?) Tha shouldn't be happening from the sounds of it since the debconf variable is set false and therefore the workaround shouldn't have been kicking in (I'll go off and figure out how to set it though since I appear to need it). Apologies if this is filed against the wrong package, I'm not 100% clear what is responsible for installing these files. It might actually be grub-efi-amd64, but I think you were close enough ;-). I did ask Steve on IRC (but wasn't that specific about the bug I was intendeding to file) so any credit is his. signature.asc Description: Digital signature
Bug#778810: grub-efi-amd64-bin: boot/bootx86.efi problems
(Steve is probably best placed to say something sensible about this, but he's away at the moment so I'll see if I can avoid sounding too dumb...) On Fri, 2015-02-20 at 14:21 +0900, Mark Brown wrote: Package: grub-efi-amd64-bin Version: 2.02~beta2-20 Severity: critical On a couple of occasions recently my system has been updated to remove boot/bootx86.efi from the EFI boot partition, and on a new install on a separate machine this file was not installed at all. Instead debian/grubx86.efi was left installed. Unfortunately on both systems my BIOS ignores this file and will only boot boot/bootx86.efi so these updates make the system unbootable. This sounds, if I'm interpreting the paths correctly, like it relates somehow to the stuff Steve was doing in #708430, in as much as it sounds like your system is one which would benefit from enabling that new workaround (grub2/force_efi_extra_removable in debconf). Do you have that new option enabled or disabled? That said, even with the workaround disabled for some reason removing an existing boot/bootx86.efi doesn't sound right to me. Not that I have any how or why it would be happening :-/. Looking at the code the only things I see which touch boot/bootx86.efi are behind the new force_efi_extra_removable option which attempts to update the binary -- I wonder if it is possible to fail half way and actually only remove the old one? (Some sort of weird vfat interaction?) Apologies if this is filed against the wrong package, I'm not 100% clear what is responsible for installing these files. It might actually be grub-efi-amd64, but I think you were close enough ;-). Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778810: grub-efi-amd64-bin: boot/bootx86.efi problems
On Fri, 2015-02-20 at 18:39 +0900, Mark Brown wrote: This is a 1st gen Lenovo Yoga, the other machine that's broken with a fresh install is an Acer Aspire E11 (with BIOS 1.13 IIRC). I can supply more specific data on both if you tell me what you're looking for (I see some talk of a blacklist in the bug though I'm not sure that made it into the code). If you can reproduce the issue then identifying the exact grub-install command line which the postinst is invoking might be of interest, as would then rerunning that same command manually under strace. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778810: grub-efi-amd64-bin: boot/bootx86.efi problems
On Fri, Feb 20, 2015 at 10:07:01AM +, Ian Campbell wrote: On Fri, 2015-02-20 at 18:39 +0900, Mark Brown wrote: This is a 1st gen Lenovo Yoga, the other machine that's broken with a fresh install is an Acer Aspire E11 (with BIOS 1.13 IIRC). I can supply more specific data on both if you tell me what you're looking for (I see some talk of a blacklist in the bug though I'm not sure that made it into the code). If you can reproduce the issue then identifying the exact grub-install command line which the postinst is invoking might be of interest, as would then rerunning that same command manually under strace. In fact, for EFI just grub-install -v should tell you a lot more. -- Steve McIntyre, Cambridge, UK.st...@einval.com I've only once written 'SQL is my bitch' in a comment. But that code is in use on a military site... -- Simon Booth -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778810: grub-efi-amd64-bin: boot/bootx86.efi problems
Package: grub-efi-amd64-bin
Version: 2.02~beta2-20
Severity: critical
On a couple of occasions recently my system has been updated to remove
boot/bootx86.efi from the EFI boot partition, and on a new install on a
separate machine this file was not installed at all. Instead
debian/grubx86.efi was left installed. Unfortunately on both systems my
BIOS ignores this file and will only boot boot/bootx86.efi so these
updates make the system unbootable.
Severity critical due to the deletion of existing boot/bootx86.efi - one
on occasion this caused my system to boot into the Windows recovery
partition which proceeded to unconditionally start repartitioning the
system destroying data and without recovery media to hand it renders the
system unusuable even without that.
Apologies if this is filed against the wrong package, I'm not 100% clear
what is responsible for installing these files.
-- Package-specific info:
*** BEGIN /proc/mounts
/dev/disk/by-uuid/6424c5eb-8fa3-46fd-af94-8a581aa54f14 / ext4
rw,relatime,errors=remount-ro,data=ordered 0 0
/dev/sda1 /boot/efi vfat
rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=utf8,shortname=mixed,errors=remount-ro
0 0
*** END /proc/mounts
*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
set have_grubenv=true
load_env
fi
if [ ${next_entry} ] ; then
set default=${next_entry}
set next_entry=
save_env next_entry
set boot_once=true
else
set default=0
fi
if [ x${feature_menuentry_id} = xy ]; then
menuentry_id_option=--id
else
menuentry_id_option=
fi
export menuentry_id_option
if [ ${prev_saved_entry} ]; then
set saved_entry=${prev_saved_entry}
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z ${boot_once} ]; then
saved_entry=${chosen}
save_env saved_entry
fi
}
function load_video {
if [ x$feature_all_video_module = xy ]; then
insmod all_video
else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
fi
}
if [ x$feature_default_font_path = xy ] ; then
font=unicode
else
insmod part_gpt
insmod ext2
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2
--hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2
6424c5eb-8fa3-46fd-af94-8a581aa54f14
else
search --no-floppy --fs-uuid --set=root 6424c5eb-8fa3-46fd-af94-8a581aa54f14
fi
font=/usr/share/grub/unicode.pf2
fi
if loadfont $font ; then
set gfxmode=auto
load_video
insmod gfxterm
set locale_dir=$prefix/locale
set lang=en_GB
insmod gettext
fi
terminal_output gfxterm
if [ ${recordfail} = 1 ] ; then
set timeout=-1
else
if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
# Fallback normal timeout code in case the timeout_style feature is
# unavailable.
else
set timeout=5
fi
fi
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_gpt
insmod ext2
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2
--hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2
6424c5eb-8fa3-46fd-af94-8a581aa54f14
else
search --no-floppy --fs-uuid --set=root 6424c5eb-8fa3-46fd-af94-8a581aa54f14
fi
insmod png
if background_image /usr/share/images/desktop-base/lines-grub.png; then
set color_normal=white/black
set color_highlight=black/white
else
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###
### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload=${1}
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu
--class os $menuentry_id_option
'gnulinux-simple-6424c5eb-8fa3-46fd-af94-8a581aa54f14' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2
--hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2
6424c5eb-8fa3-46fd-af94-8a581aa54f14
else
search --no-floppy --fs-uuid --set=root
6424c5eb-8fa3-46fd-af94-8a581aa54f14
fi
echo'Loading Linux 3.18.0-trunk-amd64 ...'
linux /boot/vmlinuz-3.18.0-trunk-amd64
root=UUID=6424c5eb-8fa3-46fd-af94-8a581aa54f14 ro quiet
echo'Loading initial ramdisk ...'
initrd /boot/initrd.img-3.18.0-trunk-amd64
}
submenu 'Advanced
