Bug#699038: grub-efi-amd64-bin: Transition grub-pc -> grub-efi fails due to missing FS driver module
Hi! sorry for taking so long to respond. My starting point was a working grub-pc (squeeze, amd64) setup. I then installed grub-efi version 1.99-26 (wheezy, amd64) via aptitude/synaptic so grub-pc probably was uninstalled but not purged (it is purged now). I used hints gleaned from bug report #623297 to avoid pitfalls. On Mon, Jan 28, 2013 at 11:58:00AM +, Colin Watson wrote: > On Sat, Jan 26, 2013 at 05:56:02PM +0100, Jens G wrote: > > After successfully installing Grub to the ESP and getting the UEFI to run > > grubx64.efi Grub (after welcomming me) complained: > > > > | error: invalid arch independent ELF magic. > > | grub rescue> As I wrote in my original bug report: |at this prompt I could list the available partitions but I |couldn't access their content via "ls (hdx,gpty)". Commands |other than "ls" weren't accessible either, Therefor, I assume that grubx64.efi was unable to find or load it's modules. I checked the *.mod files from the grub-pc AMD64 and grub-efi* AMD64 packages: 'file' reports grub-pc's are 32bit ELF binaries while grub-efi's are 64bit binaries. Taking grubx64.efi's error message into account I theorize that it was finding and trying to use grub-pc's 32bit modules and failed, resulting in an absolutly bare rescue shell. Bug report #680718 seems to be about a similar or identical problem with regard to the *.mod files > This probably means that it's trying to load modules from /boot/grub/ > and they're actually for grub-pc rather than grub-efi-amd64. What is > $prefix set to? (You can inspect it in the rescue shell using 'set'.) Then | I installed Grub under a second label and added --modules="part_gpt ext2" with two consequences: 1. Both grubx64.efi binaries have the same size but different MD5sums. 2. IIRC the 1st grubx64.efi suddenly worked (I switched to the 2nd now) This looks like grub-install does not move *.mod and/or other files to their right place at least some of the time. Maybe the --modules option forces an overwrite of existing files because you wrote > I doubt this was necessary. grub-install autodetects the > necessary modules already, In my quest to get this to work I relied heavily on <https://wiki.archlinux.org/index.php/GRUB2> and guessed educatedly which command line options exist/to use in this version. Unless newer packages work differently it would be very helpful to include a small README with a list of low level commands to build necesary files and move files to the right places manually. This old Grub 1.x way to install by hand was cumbersome but would provide a safety net until an automated install works reliably. Cheers Jens p.s. No news on > > This happend when running grubx64.efi from an EFI-shell (v1) and with the > > normal UEFI boot sequence. However, when I used the previously installed > > rEFInd boot manager to launch grubx64.efi, Grub worked just fine. > > That's a little mysterious. I may contact Rod Smith, the author of rEFInd. BTW he has some IMHO helpful documentation on UEFI/Linux as well at <http://www.rodsbooks.com/efi-bootloaders/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#699186: dvd+rw-tools: growisofs, unformatted BD-R: Wrong estimate of available space for data
Package: dvd+rw-tools Version: 7.1-6 Severity: normal Hi! I tried to burn some data on a BD-R. Growisofs formatted the disc but ran out of space when writing the data. Using xorriso for the same set of data revealed that through formatting the available space on the BD-R shrank below what was needed for this set of data. I assume that growisofs doesn't take the space needed for formatting/defect management into account when examining an unformatted BD-R, resulting in a botched burn. The best solution would be to take this space into account when it encounters an unformatted BD before formatting or at least examine the available space (again) before actually writing the data. I think not formatting by default, formatting without defect management or additional command line options would be against growisofs's design idea of getting the data onto disc easily and safely. Since growisofs was moved to it's own package in wheezy/testing this might affect that package as well. Regards Jens -- System Information: Debian Release: 6.0.6 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'proposed-updates'), (181, 'testing'), (180, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.35 (SMP w/6 CPU cores) Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=UTF-8) (ignored: LC_ALL set to de_DE.utf8) Shell: /bin/sh linked to /bin/dash Versions of packages dvd+rw-tools depends on: ii genisoimage 9:1.1.11-1 Creates ISO-9660 CD-ROM filesystem ii libc6 2.11.3-4 Embedded GNU C Library: Shared lib ii libgcc1 1:4.4.5-8 GCC support library ii libstdc++64.4.5-8The GNU Standard C++ Library v3 dvd+rw-tools recommends no packages. Versions of packages dvd+rw-tools suggests: ii cdrskin0.8.0.pl00-2+squeeze1 command line CD/DVD/BD writing too -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#699038: grub-efi-amd64-bin: Transition grub-pc -> grub-efi fails due to missing FS driver module
Package: grub-efi-amd64-bin Version: 1.99-26 Severity: important Hi, I recently moved from grub-pc/GPT to grub-efi/GPT (dual boot with Win 8). After successfully installing Grub to the ESP and getting the UEFI to run grubx64.efi Grub (after welcomming me) complained: | error: invalid arch independent ELF magic. | grub rescue> At this prompt I could list the available partitions but I couldn't access their content via "ls (hdx,gpty)". Commands other than "ls" weren't accessible either, so the system was "user-unbootable". I assume Grub could not access it's grub.cfg or remaining modules. This happend when running grubx64.efi from an EFI-shell (v1) and with the normal UEFI boot sequence. However, when I used the previously installed rEFInd boot manager to launch grubx64.efi, Grub worked just fine. AFAIK rEFInd contains some file system drivers. So I installed Grub under a second label and added | --modules="part_gpt ext2" to the grub-install invocation. This produced a different grubx64.efi but with the same size as the first one. Accidently running the FIRST grubx64.efi, it now worked using either UEFI boot or EFI-shell! Does grub-efi use the GPT boot partition similar to grub-pc? If so, did grub-install add the ext2.mod there so that both Grub instances can now access the remaining modules on the (separate) ext3 /boot partition? If more information is needed I'll try to help but I tried an awful lot of things to get the UEFI/Win8/GPT/Linux/Grub thingy working, may not remember /all/ of it and am loth to do anything disruptive at this point. Regards Jens -- System Information: Mainboard: Asus M5A99X EVO, BIOS:1604 Debian Release: 6.0.6 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'proposed-updates'), (181, 'testing'), (180, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-0.bpo.4-amd64 (SMP w/6 CPU cores) Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=UTF-8) (ignored: LC_ALL set to de_DE.utf8) Shell: /bin/sh linked to /bin/dash Versions of packages grub-efi-amd64-bin depends on: ii efibootmgr0.5.4-2Interact with the EFI Boot Manager ii grub-common 1.99-26GRand Unified Bootloader (common f grub-efi-amd64-bin recommends no packages. grub-efi-amd64-bin suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#698628: firmware-realtek: rtl8168e-3.fw conflict with fglrx
Package: firmware-realtek Version: 0.28+squeeze1 Severity: important Hi, I ran into the conflict between the RTL8111e chip and fglrx version 1:12-3-3~bpo60+1 causing the system to freeze when halting. In my case the system freezes some steps after completing file system unmounting. It loads the firmware file rtl8168e-3.fw. However, I experienced freezes before file system unmounting. I may have been experimenting with firmware-realtek version 0.35~bpo60+1 at the time. If that is correct this bug may have the potential for data loss and therefore be more severe and be relevant for wheezy/testing. I found 2 workarounds: 1.) I simply don't use package firmware-realtek. It doesn't seem to have any effect on network performance. 2.) I manually ´rmmod r8169´ before halting the system. While 1.) works for me 2.) may point to a more general solution: There could be a script in /etc/rc0.d that detects a loaded r8169 module und rmmod it. Since the standard Debian kernels are modular that should work in most cases. A warning message while installing firmware-realtek or relevant fglrx-packages and in README files could cover those installing custom kernels. I did no tests on a custom kernel with a compiled in r8169. Please note that (while troubleshooting) I tried removing only the fglrx module. It may have moved the point of freeze to after FS unmounting (see above) but didn't solve the problem. This and the fact that my solution deals with the r8169 module/firmware are the reasons I am submitting this bug report against firmware-realtek instead of the fglrx or kernel packages. Please feel free to reassign this bug to a more appropriate package/severity. Regards Jens -- System Information: Debian Release: 6.0.6 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'proposed-updates'), (199, 'testing'), (198, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-0.bpo.4-amd64 (SMP w/6 CPU cores) Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=UTF-8) (ignored: LC_ALL set to de_DE.utf8) Shell: /bin/sh linked to /bin/dash firmware-realtek depends on no packages. firmware-realtek recommends no packages. Versions of packages firmware-realtek suggests: ii initramfs-tools 0.99~bpo60+1 tools for generating an initramfs ii linux-image-2.6.32-5-am 2.6.32-46Linux 2.6.32 for 64-bit PCs ii linux-image-3.2.0-0.bpo 3.2.35-2~bpo60+1 Linux 3.2 for 64-bit PCs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
