Bug#774138: grub-efi-amd64: Update freeze with kernel oops for EFI (2.02~beta2-{18 -> 19})
On Wed, 2014-12-31 at 12:08 +0100, Axel Angel wrote: > > You might find that adding "noexec=off" to your kernel command line > > worksaround this issue. > > I can give it a try. Question: isn't it dangerous to enable this flag in > normal use? I guess so. It's not really dangerous as such, there would be a slight decrease in resistance to certain classes of security vulnerability is all. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#774138: grub-efi-amd64: Update freeze with kernel oops for EFI (2.02~beta2-{18 -> 19})
> Was this in the state where things crashed or the "working" state (but > with the second issue you mentioned occurring)? This is the diff between -18 and -19 when nothing crash in both case. This shows there is a visible change for efibootmgr. > I think there is a pretty good chance that this is therefore a firmware > issue. I'd recommend the first thing to try would be to see if an > updated firmware is available for your system and if so then install it. You mean the motherboard firmware right? There seem to be only minor changes according to the changelog of Gigabyte on their website. I'm always worried about upgrading firmwares, I could give a try though as a last resort. > Your kernel stack trace shows that the CPU has tried to execute code > from a region of RAM which has been marked non-executable when calling > into the firmware. I'm not familiar enough with EFI to know if > responsibility for this lies with the firmware or the kernel and have a > feeling it might be the two in concert. > > You might find that adding "noexec=off" to your kernel command line > worksaround this issue. I can give it a try. Question: isn't it dangerous to enable this flag in normal use? I guess so. > Sounds like a firmware issue to me, if an upgrade doesn't help I'd > recommend to start by reporting against efibootmgr. I thought the issue may be related so I hope I didn't confuse you more with this information. > Once you've updated the firmware I think I'd suggest starting by > reassigning this crash issue to the Linux package (I can help with the > mechanics of that if you need). The thing about the delete boot entries > probably ought to start with efibootmgr (I could clone this report, but > I think a fresh one dedicated to that issue would be better). Thanks for the help. Let's report it to efibootmgr after I tried the two things you mentionned above. Thanks! signature.asc Description: Digital signature
Bug#774138: grub-efi-amd64: Update freeze with kernel oops for EFI (2.02~beta2-{18 -> 19})
On Tue, 2014-12-30 at 21:32 +0100, Axel Angel wrote: > @@ -7511,7 +7511,6 @@ > grub-install: info: executing efibootmgr --version /dev/null. > grub-install: info: executing modprobe -q efivars. > grub-install: info: executing efibootmgr -c -d /dev/sda -p 1 -w -L debian -l > \EFI\debian\grubx64.efi. > - > -Could not prepare boot variable: No such file or directory > - > +efibootmgr: Could not set variable Boot: No such file or directory > +efibootmgr: Could not prepare boot variable: No such file or directory > Installation finished. No error reported. Was this in the state where things crashed or the "working" state (but with the second issue you mentioned occurring)? [...] > So, I tried many things and found that indeed the new version is not the > source of the problem. In fact the system before the upgrade exhibits the > same problem under a simple condition: when the system was resumed from > disk. I found that everything is fine when it is freshly booted, > whichever the version -18 or -19. I think there is a pretty good chance that this is therefore a firmware issue. I'd recommend the first thing to try would be to see if an updated firmware is available for your system and if so then install it. Your kernel stack trace shows that the CPU has tried to execute code from a region of RAM which has been marked non-executable when calling into the firmware. I'm not familiar enough with EFI to know if responsibility for this lies with the firmware or the kernel and have a feeling it might be the two in concert. You might find that adding "noexec=off" to your kernel command line worksaround this issue. > I upgraded all the package again and reproduced my problem with -19. > I have the kernel log when it crashed but not the log of grub-install > because it froze immediately this time, I couldn't save it. I have a > photo of the last lines nonetheless, that may help. > > Moreover it has been since a few months that efibootmgr didn't work > properly for my motherboard. I noticed that since it broke, efibootmgr > deletes every boot entries, moreover its own is not visible afterward. I > had to place the grub binary myself into the generic location > "/boot/efi/EFI/BOOT/BOOTx64.efi" to make my system boots, and it works. Sounds like a firmware issue to me, if an upgrade doesn't help I'd recommend to start by reporting against efibootmgr. > I own a thinkpad x220 and indeed I don't suffer these problems. That > means either one of these: as you said the firmware is bugged or the > support for my MB is not fully complete. > > I am no expert on the matter, if you have any clue whether I should > report it to an other package like efibootmgr or how can I find more > informations? Once you've updated the firmware I think I'd suggest starting by reassigning this crash issue to the Linux package (I can help with the mechanics of that if you need). The thing about the delete boot entries probably ought to start with efibootmgr (I could clone this report, but I think a fresh one dedicated to that issue would be better). Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#774138: grub-efi-amd64: Update freeze with kernel oops for EFI (2.02~beta2-{18 -> 19})
On Mon, 2014-12-29 at 11:30 +0100, Axel wrote: > Package: grub-efi-amd64 > Version: 2.02~beta2-19 > Severity: important > > Dear Maintainer, > >* What led up to the situation? > Usual daily upgrade. Including grub-efi-amd64: > 2.02~beta2-18 -> 2.02~beta2-19~i (is ~i a typo here?) The functional changes between -18 and -19 were pretty minor, just: + * Handle case insensitivity of VFAT filesystem on /boot/EFI when installing +extra cpoy of grub-efi to the removable media path +/boot/efi/EFI/BOOT/BOOT$ARCH.EFI (Closes: #773092) + * Make the force_efi_extra_removable debconf prompt only show up when +configuring grub-*efi*. Closes: #773004 plus a boatload of translation updates. The second on is obviously not the problem and since your debconf data contains : grub2/force_efi_extra_removable: false I think none of the code involved in the first case will be getting run for you. So I think you are probably correct to consider other things which have been upgraded as in your follow up. Could you try running "grub-install -v" please. Please could you also try downgrading this and some of the other packages which you think might be at fault one at a time to see if you can nail the culprit. Another possibility is that the firmware is a bit b0rked wrt efivars handling (I've heard some nasty things about some firmwares in this regard) and its just a coincidence that this was the upgrade which triggered it. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#774138: grub-efi-amd64: Update freeze with kernel oops for EFI (2.02~beta2-{18 -> 19})
Package: grub-efi-amd64 Version: 2.02~beta2-19 Severity: important Dear Maintainer, * What led up to the situation? Usual daily upgrade. Including grub-efi-amd64: 2.02~beta2-18 -> 2.02~beta2-19~i * What exactly did you do (or not do) that was effective (or ineffective)? The effect of the upgrade is a freeze of the entire computer after a few tens of seconds when the aforementionned package is configured, the process hangs while it's saying "Installing for x86_64-efi platform." several kernel oops'es appeared in the logs (see below), after 20-30 seconds the system hanged: the mouse is unresponsive, I cannot change the tty, caps lock cannot be toggled, processes seem still running (continue to hear music) and sysreq keys are working, I can safely sync and reboot. At this point, when I reboot the package is still not configured, thus I can reproduce the bug indefinitely by running: sudo dpkg --configure -a If I interrupt the configuration with ^C before any kernel oops appeared, my computer doesn't crash, but the package remain unconfigured. I could downgrade to beta2-18 without any problem and everything is working as beforehand. I re-upgraded and can still confirm the issue remains. ** The output of dpkg --configure: > sudo dpkg --configure -a Setting up grub-efi-amd64 (2.02~beta2-19) ... Installing for x86_64-efi platform. ^ last message before freeze ** The content of kern.log during the upgrade (after the "Installing" message): Dec 29 10:56:51 nyx kernel: [ 677.520408] general protection fault: [#1] SMP Dec 29 10:56:51 nyx kernel: [ 677.520425] Modules linked in: btrfs xor raid6_pq ufs qnx4 hfsplus hfs minix ntfs msdos jfs xfs libcrc32c rpcsec_gss_krb5 nfsv4 dns_resolver cpufreq_userspace cpufreq_powersave cpufreq_conservative cpufreq_stats nfsd auth_rpcgss oid_registry nfs_acl nfs lockd fscache sunrpc tun it87 hwmon_vid nls_utf8 nls_cp437 vfat fat loop fuse parport_pc ppdev lp parport snd_hda_codec_realtek snd_hda_codec_hdmi snd_hda_codec_generic x86_pkg_temp_thermal intel_powerclamp intel_rapl arc4 coretemp kvm_intel kvm crc32_pclmul ghash_clmulni_intel iwldvm aesni_intel aes_x86_64 mac80211 lrw iTCO_wdt snd_hda_intel radeon i915 gf128mul evdev iTCO_vendor_support glue_helper efi_pstore iwlwifi ttm ablk_helper snd_hda_controller drm_kms_helper cryptd snd_hda_codec cfg80211 psmouse pcspkr snd_hwdep drm serio_raw efivars i2c_i801 rfkill mei_me lpc_ich i2c_algo_bit snd_pcm mfd_core mei i2c_core snd_timer snd tpm_infineon tpm_tis soundcore tpm shpchp processor video button battery ext4 crc16 mbcache jbd2 hid_generic usbhid hid dm_mod sg sd_mod crc_t10dif crct10dif_generic ahci libahci crct10dif_pclmul crct10dif_common libata crc32c_intel ehci_pci xhci_hcd ehci_hcd scsi_mod alx mdio e1000e usbcore ptp thermal fan pps_core usb_common thermal_sys Dec 29 10:56:51 nyx kernel: [ 677.520768] CPU: 7 PID: 13729 Comm: efibootmgr Not tainted 3.16.0-4-amd64 #1 Debian 3.16.7-ckt2-1 Dec 29 10:56:51 nyx kernel: [ 677.520785] Hardware name: Gigabyte Technology Co., Ltd. Z87N-WIFI/Z87N-WIFI, BIOS F4 08/03/2013 Dec 29 10:56:51 nyx kernel: [ 677.520802] task: 88043cc43530 ti: 8800a7cd4000 task.ti: 8800a7cd4000 Dec 29 10:56:51 nyx kernel: [ 677.520817] RIP: 0010:[] [] efi_call+0x7c/0x100 Dec 29 10:56:51 nyx kernel: [ 677.520835] RSP: 0018:8800a7cd7d70 EFLAGS: 00010002 Dec 29 10:56:51 nyx kernel: [ 677.520845] RAX: 88043b9d6000 RBX: 88043b9d6000 RCX: 88043b9d6000 Dec 29 10:56:51 nyx kernel: [ 677.520859] RDX: 88043b9d6400 RSI: 88043b9d6000 RDI: 0f6a210041005400 Dec 29 10:56:51 nyx kernel: [ 677.520873] RBP: 88043b9d6400 R08: 88043b9d6820 R09: 88043b9d6410 Dec 29 10:56:51 nyx kernel: [ 677.520886] R10: 1000 R11: 0246 R12: 88043b9d6820 Dec 29 10:56:51 nyx kernel: [ 677.520900] R13: 88043b9d6410 R14: 88043b9d6418 R15: 0009a000 Dec 29 10:56:51 nyx kernel: [ 677.520913] FS: 7f74ed9b8700() GS:88044f3c() knlGS: Dec 29 10:56:51 nyx kernel: [ 677.520929] CS: 0010 DS: ES: CR0: 80050033 Dec 29 10:56:51 nyx kernel: [ 677.520939] CR2: 7f74ece4b110 CR3: 0009a000 CR4: 001407e0 Dec 29 10:56:51 nyx kernel: [ 677.520953] Stack: Dec 29 10:56:51 nyx kernel: [ 677.520958] 8803 01ff8800a7cd7f3c 880433223b48 88044e418198 Dec 29 10:56:51 nyx kernel: [ 677.520974] 88043b9d6418 88043b9d6000 8800a7cd7e18 80050033 Dec 29 10:56:51 nyx kernel: [ 677.520991] Dec 29 10:56:51 nyx kernel: [ 677.521008] Call Trace: Dec 29 10:56:51 nyx kernel: [ 677.521015] [] ? virt_efi_get_variable+0x4b/0x60 Dec 29 10:56:51 nyx kernel: [ 677
