Description of problem: I tried to install Fedora 16 Beta on Lenovo Ideapad S205, which has Phoenix SecureCore Tiano bios and it doesn't offer a possibility to use a legacy BIOS mode. It seems that UEFI bios requires GPT layout and EFI System partition. The UEFI installation was done using the file efidisk.img from the <dvd>/image/ directory and failed, all packages were successfully installed, but bootloader was not in place. The EFI image uses the legacy grub, Anaconda tries to install both grub and grub2, the result is a conflict during dependency resolution (screenshot_1.png) and the end the boot loader is not installed correctly (screenshot_2.png). There is no boot record in NVRAM, the EFI BootOption is not set. How reproducible: Always. Steps to Reproduce: 1. Copy efidisk.img on a USB stick 2. Try to install Fedora 16 in standard way. 3. Actual results: A broken system without a functional boot loader. Expected results: The boat loader should be installed and system bootable. Additional info:
Created attachment 529704 [details] the package conflict
Created attachment 529705 [details] the installation of the boot loader failed
Created attachment 529707 [details] anaconda logs
I tested Fedora 16 TC(2) and the conflict during installation was fixed. The problem with installation of the boot loader remain. It looks like, that grubby doesn't create the configuration file grub.conf in /boot/efi/EFI/redhat/. When the configuration file is manually created and grub.efi is run from EFI Shell, the system boots.
I have the same problem with the Ideapad s205. I installed with the nightly image from yesterday (29. october) - but the installation failed. The bios does not even load grub from the disk, just refuses to boot. In Ubuntu 11.10 installation works. It installs grub2 - what is a problem, because this difficult device needs grub legacy to be able to suspend.
Hi Bjorn, it looks like that F16 has some problem to update NVRAM records in UEFI and doesn't generate the grub configuration file. A temporary solution is to create grub.conf and run grub.efi from EFI Shell (let me know, if you need a help with that). Do you have the problem described here: https://bugzilla.redhat.com/show_bug.cgi?id=748210 When you switch off/on the backlight, the system crashes.
Requesting blocker review. Does this still happen with Final RC2? There isn't much time left before F16, so please test RC2 ASAP. Thanks.
This may also be happening in trying to create a EFI boot USB for f16-RC2-live-Soasx86_64 for Booting USB in MacBook Pro i7. it gets to a blue screen and a cursor at top left corner and goes no farther. f15 works fine: http://wiki.sugarlabs.org/go/Community/Distributions/Fedora-SoaS#MacBook_Persistent_SoaS_v5_USB_EFI_Boot
The log files on this issue is "old", and after comment 4 none of them are relevant. "new" logs are IMHO a must before this issue can be processed further. I do however note a couple of odd things in the old logs: anaconda: dispatch: Can not reschedule step 'bootloader' from 'skipped' to 'requested' That could explain why no boot loader was installed. How could this happen? The "speed" error is bug 743787 and should be fixed ... but how could that happen on real hardware which (presumably) doesn't use serial console?
We really need logs from post-Beta, it's impossible to investigate without them. It's also not clear if you are all experiencing the same problem or not without any logs. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Discussed at 2011-10-31 blocker review meeting. We need more information to be able to consider this bug a blocker. If we do not have info by the time of the go/no-go meeting, and other EFI install tests succeed, we will likely reject this bug. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
The newer logs are here - Fedora 16 TC - a different bug, but still the same problem with the boot loader: https://bugzilla.redhat.com/show_bug.cgi?id=748274 If you need to test something, if you have a newer image let me know; the netbook is just a playground to test F16. Regarding the NVRAM, I found out, that the variable BootXXXX is updated and active. The variable BootOrder is unchanged, so the Fedora's boot record is not taken into account.
Yes, please test the latest RC (currently RC2): http://alt.fedoraproject.org/pub/alt/stage/16.RC2/ Thanks.
"Regarding the NVRAM, I found out, that the variable BootXXXX is updated and active. The variable BootOrder is unchanged, so the Fedora's boot record is not taken into account." AIUI, usually when you add a new entry with efibootmgr - as clearly happens at the end of your log - it becomes the default. can you boot to anaconda's rescue mode and run 'efibootmgr -v' so we can examine the configuration present after the 'failed' install? what *exactly* is the problem you are seeing? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
f16 gnome3-shell 3.2.1 with livecd-tools-16.8-1.fc16.x86_64.rpm installed: http://alt.fedoraproject.org/pub/alt/stage/16.RC2/Spins/x86_64/Fedora-16-x86_64-Live-SoaS.iso I still get an non booting EFI USB. It finds EFI on MacBook Pro i7 then goes to the boot screen then to blue screen with cursor in upper left corner and stops. sudo livecd-iso-to-disk --format --efi --overlay-size-mb 300 --home-size-mb 175 --delete-home --unencrypted-home Fedora-15-x86_64-Live-SoaS.iso /dev/sd(x) (x)=device name works fine for same version of file for f15 Is this due to grub vs grub2?
no, because we don't use grub2 for efi, and we don't use grub on the live images at all. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Charles: Downloading. Adam, this is the output of "efibootmgr -v": //----------------------------------------------------- BootCurrent: 0007 Timeout: 0 seconds BootOrder: 0007,0002,0003,0004,0005 Boot0000 Setup Boot0001 Boot Menu Boot0002* USB FDD: 030a2400d23878bc820f604d8316c068ee79d25b6ff015a28830b543a8b8641009461e49 Boot0003* ATA HDD0: WDC WD2500BPVT-24ZEST0 ACPI(a0341d0,0)PCI(11,0)ATAPI(0,0,0)..bYVD.A...O.*.. Boot0004* USB HDD: 030a2400d23878bc820f604d8316c068ee79d25b33e821aaaf33bc4789bd419f88c50803 Boot0005* USB CD: 030a2400d23878bc820f604d8316c068ee79d25b86701296aa5a7848b66cd49dd3ba6a55 Boot0006* PCI LAN: Realtek PXE B02 D00 BIOS(6,0,5265616c74656b20505845204230322044303000)..................@.......@...@.............................................A..................... Boot0007* Fedora HD(1,800,64000,84f99a07-a721-45c1-9d86-3fc638296e1c)File(\EFI\redhat\grub.efi) //----------------------------------------------------- Anaconda added the record Boot0007, but it didn't update BootOrder; I had to do that manually after the installation. This the output of "gdisk -l /dev/sda": //----------------------------------------------------- PT fdisk (gdisk) version 0.7.2 Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. Disk /dev/sda: 488397168 sectors, 232.9 GiB Logical sector size: 512 bytes Disk identifier (GUID): EC218E35-CA75-488E-9368-0CB499FE2546 Partition table holds up to 128 entries First usable sector is 34, last usable sector is 488397134 Partitions will be aligned on 2048-sector boundaries Total free space is 2349 sectors (1.1 MiB) Number Start (sector) End (sector) Size Code Name 1 2048 411647 200.0 MiB EF00 EFI System Partition 2 411648 1435647 500.0 MiB 0700 3 1435648 8054783 3.2 GiB 8200 4 8054784 112912383 50.0 GiB 0700 5 112912384 488396799 179.0 GiB 0700 //----------------------------------------------------- Look at the disk identifier, it is a different value than in the Fedora's UEFI boot record. What happened: (1) Fedora Beta was installed, the installation of the boot loader failed. (2) I erased the whole disk and created a new GPT table. (3) Fedora TC was installed, the installation of the boot loader again failed. Based on that: (a) Fedora TC didn't update the boot record created by Fedora Beta or (b) Fedora TC set a wrong disk GUID. Could the wrong disk GUID be a reason, why grub.conf is not created?
I think I recall pjones saying you can't actually expect those values to match. I'm going to test an EFI install here and see if they do. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
1) I downloaded the image RC2, verified the checksum; 2) mounted the iso image and extracted "efidisk.img"; 3) dd-ed the image to USB stick, read it back and verified the checksum; 4) using "efibootmgr" deleted boot record from NVRAM; 5) wiped out all Fedora's partition from the hardisk; 6) loaded default BIOS setting. The booting of "efidisk.img" from RC2 failed If I use Beta or TC(2) I can boot the system. I am downloading RC1, just to test, when the regression happened.
yeah, I just tested on my system: the value in gdisk -l doesn't match the value that's in both efibootmgr and grub.conf, but the system boots. For some reason those two UUIDs are not expected to be the same. I can't reproduce the failure; I did an install from RC2 DVD, booted via EFI, and the installed system boots fine. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
efidisk.img is known to be broken in RC2. there's no need to use efidisk.img now, though, the instructions to do so are outdated. You can write the DVD to an actual disc and it will be EFI bootable, or you can write the DVD ISO, boot.iso, or any live image to USB using livecd-iso-to-disk with the --efi parameter and the resulting USB stick will be EFI bootable.
Thanks, I am going to try it. Lenovo has really dodgy UEFI implementation, I want my good old pre-historical BIOS back! The RC2 efidisk.img is weird, my attempts to mount it failed. //----------------------------------------------------- $ parted efidisk.img WARNING: You are not superuser. Watch out for permissions. GNU Parted 2.3 Using /home/vamo/efidisk.img Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) unit Unit? [compact]? B (parted) p Model: (file) Disk /home/vamo/efidisk.img: 140781568B Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End Size File system Name Flags 1 17408B 140764671B 140747264B EFI System Partition boot (parted) q $ sudo mount -o loop,ro,offset=17408 efidisk.img ~/mnt mount: you must specify the filesystem type $ sudo mount -t vfat -o loop,ro,offset=17408 efidisk.img ~/mnt mount: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so $ gdisk -l efidisk.img GPT fdisk (gdisk) version 0.8.1 Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. Disk efidisk.img: 274964 sectors, 134.3 MiB Logical sector size: 512 bytes Disk identifier (GUID): 3CE394B0-3F94-43A2-B4BE-382E2D14E409 Partition table holds up to 128 entries First usable sector is 34, last usable sector is 274930 Partitions will be aligned on 2-sector boundaries Total free space is 0 sectors (0 bytes) Number Start (sector) End (sector) Size Code Name 1 34 274930 134.2 MiB EF00 EFI System Partition $
yes, we know. https://bugzilla.redhat.com/show_bug.cgi?id=750228 -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I tested boot.iso and the standard DVD. Both are hybrid images so I tried dd to USB and an external USB DVD drive. Everything failed. The netbook was able to boot, but not in *EFI mode*. As a result of that, anaconda complained, that the partition was wrong (must have msdos) and proposed a layout without the EFI system partition. The usb disk created using "livecd-iso-to-disk --efi --format ..." didn't boot at all. It seems to me, that Lenovo UEFI requires a proper GPT to boot and the only way which has worked so far was "efidisk.img" (well, partly worked).
when you boot a lenovo in bios mode it won't write a GPT partition table; we blacklisted them from using GPT in BIOS mode due to https://bugzilla.redhat.com/show_bug.cgi?id=749325 . -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
dd wouldn't make them USB bootable, you have to use 'livecd-iso-to-disk --format --reset-mbr --efi' .
er, I meant 'EFI bootable'.
I used that, F14 livecd-tools, it worked only for F16 LiveCD: sudo livecd-iso-to-disk --format --reset-mbr --efi Fedora-16-x86_64-netinst.iso /dev/sdb Verifying image... /home/vamo/not_backupped/fedora-16/Fedora-16-x86_64-netinst.iso: b5c9eb0f10996d3e0cb97e9e776c3d43 Fragment sums: 11466c6aa9c7457a1fb7ed2a4a48ea7cd25ad56dfa4bd384d9177555bc63 Fragment count: 20 Press [Esc] to abort check. Checking: 100.0% The media check is complete, the result is: PASS. It is OK to use this media. WARNING: THIS WILL DESTROY ANY DATA ON /dev/sdb!!! Press Enter to continue or ctrl-c to abort Waiting for devices to settle... mkdosfs 3.0.9 (31 Jan 2010) 1+0 records in 1+0 records out 16 bytes (16 B) copied, 7.8713e-05 s, 203 kB/s /home/vamo/not_backupped/fedora-16/Fedora-16-x86_64-netinst.iso uses initrd.img w/o install.img ERROR: This live image does not support EFI booting Cleaning up to exit... $ rpm -qa livecd-tools livecd-tools-14.2-1.fc14.i686
that's not this bug, and now I'm confused. ignore the problem with writing EFI USB sticks in F14. Once you write an EFI F16 RC2 / RC3 stick, does it work? efidisk.img from RC3 works, btw, so you can try that. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
sudo livecd-iso-to-disk --format --efi --overlay-size-mb 300 --home-size-mb 175 --delete-home --unencrypted-home Fedora-15-x86_64-Live-SoaS.iso /dev/sd(x) (x)=device name makes a persistent EFI USB that boots properly on a MacBook Pro i7 (using f16 gnome3-shell 3.2.1 PC on my Acer Aspire One N450 to built it) f16 x86-64 Soas RC2 and RC3.iso EFI USB does not boot on the MacBook Pro i7 using the same USB stick and script . USB boots to initial screen then goes to a blue background with a cursor in top left corner and proceeds no farther.
sat: that's sounding like our new blocker, https://bugzilla.redhat.com/show_bug.cgi?id=748516 . i'll have a boot.iso up for testing of that soon. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
An update for F16 RC3 and Lenovo S205 I am able to boot efidisk.img and install the system. During the installation, there are no conflicts and no errors*, the grub.conf was created. However, the system is not bootable, because the installer did not create the EFI boot record. * no errors related to this topic.
Created attachment 531173 [details] The F13 RC3 Installation logs: root, var, grub.
Okay, so there's clearly something very wacky going on at the end of program.log. It installs the Fedora efibootmgr entry, which seems to go fine, then runs efibootmgr -v again (that's normal), and gets some very wacky output: 17:46:53,994 INFO program: Running... efibootmgr -v 17:46:54,084 INFO program: BootCurrent: 0004 17:46:54,085 INFO program: Timeout: 0 seconds 17:46:54,085 INFO program: BootOrder: 0007,0002,0003,0004,0005 17:46:54,086 INFO program: Boot0000 Setup 17:46:54,086 INFO program: Boot0001 Boot Menu 17:46:54,087 INFO program: Boot0002* USB FDD: 030a2400d23878bc820f604d8316c068ee79d25b6ff015a28830b543a8b8641009461e49 17:46:54,087 INFO program: Boot0003* ATA HDD0: WDC WD2500BPVT-24ZEST0 ACPI(a0341d0,0)PCI(11,0)ATAPI(0,0,0)..bYVD.A...O.*.. 17:46:54,088 INFO program: Boot0004* USB HDD: 030a2400d23878bc820f604d8316c068ee79d25b33e821aaaf33bc4789bd419f88c50803 17:46:54,089 INFO program: Boot0005* USB CD: 030a2400d23878bc820f604d8316c068ee79d25b86701296aa5a7848b66cd49dd3ba6a55 17:46:54,089 INFO program: Boot0006* PCI LAN: Realtek PXE B02 D00 BIOS(6,0,5265616c74656b20505845204230322044303000)..................@.......@...@.............................................A..................... that's...not right. The S205 does appear to be somewhat 'infamous' if you Google it; there seems to be all sorts of trouble getting any kind of Linux to install onto it. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
so this was discussed at the 2011-11-01 emergency blocker review meeting: we're fairly sure that whatever Vaclav is hitting is a single-system issue, no-one else's EFI symptoms seem to match his and we're fairly sure we've identified the other bugs. So this is rejected on the basis that the impact isn't broad enough to qualify as a blocker.
I wonder if the S205's firmware does something wrong with the EFI boot manager entries it creates, such that the end of the last firmware-created entry is wrong, and when efibootmgr creates a Fedora entry 'correctly', it winds up merging with the last firmware-created entry into some sort of hideous hybrid, aka what shows up at the end of the efibootmgr output above? Just guessing.
I agree, it does not make sense to waste time with that. It seems that efibootmgr and Lenovo Ideapad S205 are not compatible and the result might be at least corrupted boot options in NVRAM. Above that, in my case, the serial number and model identifier, as displayed in UEFI setup, are corrupted now as well. Thanks all for your help and time.
http://dl.fedoraproject.org/pub/alt/stage/16.RC3/Spins/x86_64/Fedora-16-x86_64-Live-SoaS.iso 01-Nov-2011 03:20 442M still fails to boot on USB on MacBook Pro i7 4GB USB formatted in f16 diskutility Ms Dos /dev/sdb fat /dev/sdb1 I tried /dev/sdb1 dos partition then /dev/sdb gpt partition (Same USB) on same USB failed to boot past blue screen with cursor in left top corner both times.
http://alt.fedoraproject.org/pub/alt/stage/16.RC4/Spins/x86_64/Fedora-16-x86_64-Live-SoaS.iso boots fine as an EFI USB on My MacBook Pro i7..thanks http://kojipkgs.fedoraproject.org/packages/kernel/3.1.0/7.fc16/x86_64/kernel-3.1.0-7.fc16.x86_64.rpm fixed boot problems (It is in RC4)
So, I now tested again on my Ideapad s205. I used the RC5 dvd image, used partition layout as suggested by anaconda. Result was bad. S205 does not find grub and doesn't find a device it can boot from.
Hi Bjorn, it seems to be a problem of Ideapad S205. All Linux distros use efibootmgr to update boot records in NVRAM, unfortunately in case of S205 it very often fails, due to *buggy* firmware. First of all, you must install Fedora in *EFI mode*. To verify that, boot to the rescue mode using the installation DVD and display the partition layout (command "parted -l /dev/sda"). You should see something like this: ... Number Start End Size File system Name Flags 1 1049kB 211MB 210MB fat32 EFI System Partition boot ... The EFI System Partition is a must. If you have it, you can do as a workaround the following steps: 1) Download https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/ShellBinPkg/UefiShell/X64/Shell.efi and rename it to bootx64.efi 2) On EFI system partition create directory EFI/boot/ and copy there the file bootx64.efi 3) In the same directory create file startup.nsh, with the following content: fs0: EFI\redhat\grub.efi At the end, your EFI System partition should look like this: . └── EFI ├── boot │ ├── bootx64.efi │ └── startup.nsh └── redhat ├── device.map ├── grub.conf └── grub.efi The directory EFI/redhat and the files device.map, grub.conf and grub.efi are created by Anaconda during installation. To make it easier, I attached the needed files (bootx64.efi, startup.nsh).
Created attachment 531891 [details] bootx64.efi startup.nsh The UEFI shell is downloaded from http://sourceforge.net/apps/mediawiki/tianocore , the licence is OK.
updating the description to be a little more precise, and re-assigning. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Just out of interest, have you tried with the latest S205 'BIOS'? It seems to have a fairly recent update upstream: http://consumersupport.lenovo.com/us/en/DriversDownloads/drivers_show_4919.html Release Date 2011-08-17 With a possibly-related changelog note: "4BCN24WW: Fix the hang up issue when installing non-OEM version Windows 7 Operation system." Adding a CommonBugs note so we can document this for S205 users. Reporter says there's no BIOS compatibility mode, which would be a first in 'in the wild' hardware so far as we know.
Thanks for your hints Vaclav, I will try it out as soon as I have time for that. To answer the questions, no I don't use the recent bios, but two versions before. Simple reason: I don't know how to upgrade without windows. Lenovo does only provide a Win-exe - no cd iso images as for ThinkPads. Just a note: Ubuntu 11.10 is able to install and boot grub2 on this machine. They must have worked around the issue.
that seems odd. afaict, nothing has been touched in efibootmgr since 2008 upstream, or in ubuntu. i suppose one of the two changes we put in *fedora's* efibootmgr since then might be involved? * Wed Dec 01 2010 Peter Jones <pjones> - 0.5.4-10 - Add support for bootable devices with 4kB sectors. * Wed Apr 14 2010 Peter Jones <pjones> - 0.5.4-9 - Make \EFI\redhat\grub.efi the default bootloader Resolves: rhbz#579665 -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
i did find an interesting post in a somewhat-related ubuntu bug: https://bugs.launchpad.net/debian/+source/linux-2.6/+bug/721576/comments/29 seems like it may be the way to do BIOS boot on the s205?
No, the machine does not boot any grub no matter whether I choose Ubuntu (what must be a remain of the previous Ubuntu-installation) or the HDD directly.
-- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Okay, I looked through Vaclavs comment. In my installation the boot directory was missing on the efi partition. I copied the content from vaclav in their - and now it boots. It's missing a device.map and it is using grub-legacy.
Huh. Can't see why it'd be missing. Use of grub-legacy is intentional - we use grub-legacy for EFI installs in F16 just because grub2's EFI support is rather buggy. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #45) > Thanks for your hints Vaclav, I will try it out as soon as I have time for > that. > > To answer the questions, no I don't use the recent bios, but two versions > before. Simple reason: I don't know how to upgrade without windows. Lenovo does > only provide a Win-exe - no cd iso images as for ThinkPads. > > Just a note: Ubuntu 11.10 is able to install and boot grub2 on this machine. > They must have worked around the issue. No, on my s205, Ubuntu 11.10 does not boot. With Fedora 16 fresh install, I only see the GRUB> for like a second and it's all reboot again.
Currently Ubuntu 11.10 does not work for me too. It worked flawlessly before I played with Fedora. Now it fails. Actually Ubuntu installed a msdos partition table on the disk, what caused the Ideapad to freeze at boot time. After putting the Ubuntu in a GPT-disk partition, the boot process does not freeze anymore - grub just is not found. I'm quite fed up with this system. Never had that much problems with a hardware.
(In reply to comment #53) > Currently Ubuntu 11.10 does not work for me too. It worked flawlessly before I > played with Fedora. Now it fails. > > Actually Ubuntu installed a msdos partition table on the disk, what caused the > Ideapad to freeze at boot time. > > After putting the Ubuntu in a GPT-disk partition, the boot process does not > freeze anymore - grub just is not found. > > I'm quite fed up with this system. Never had that much problems with a > hardware. Currently I'm running Fedora 15 which installs and boots OK. I definitely believe the problem is with grub2 and the s205's uefi firmware. I tried installing Fedora and then using the liveusb to chroot into the grub partion, remove grub 2 and then reinstall grub legacy, still no luck. However, this guy here says he got the box to boot http://helms-deep.cable.nu/~rwh/blog/?p=177
If F15 / grub1 works, you have the option of installing F15 then yum upgrading to F16, which should leave grub1 in the MBR and hence the system bootable. It would not switch to grub2 in the MBR unless you manually ran grub2-mkconfig / grub2-install. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #55) > If F15 / grub1 works, you have the option of installing F15 then yum upgrading > to F16, which should leave grub1 in the MBR and hence the system bootable. It > would not switch to grub2 in the MBR unless you manually ran grub2-mkconfig / > grub2-install. > > > > -- > Fedora Bugzappers volunteer triage team > https://fedoraproject.org/wiki/BugZappers OK. I was thinking same but was not sure if grub would be over written. I couldn't get anything from Google on that. But once you've confirmed, I'll give it a try and report back. Bandwidth is quite expensive here so this may take some time. I'm also thinking of upgrading the bios as per comment 44 above
salman: yup. Just to make it absolutely clear: a yum upgrade will not overwrite the MBR, only anaconda does that. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Is this due to something like http://forum-en.msi.com/index.php?topic=153411.0 ?
Hard to say for sure, but my guess would be no. It doesn't look like the firmware tries to filter out the entry that's added by efibootmgr, it just seems like somehow it doesn't handle the addition of entries quite correctly. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Hi, in IBM Rack Server X3650 M3, Fedora 16 X86_64 DVD not boot (kernel Panic) The image with error: http://cali.latinoaustralia.com/server/fedora%2016%20kernel%20panic%20ibm%20x3650%20m3.jpg
That's a kernel crash, so I'm not sure why you're posting in this bug. Please file a new one. Thanks! -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #61) I believe that it is related to UEFI problem. > That's a kernel crash, so I'm not sure why you're posting in this bug. Please > file a new one. Thanks! > > > > -- > Fedora Bugzappers volunteer triage team > https://fedoraproject.org/wiki/BugZappers
You should still file a new bug. It's not the same problem as in this bug. There is not just One Universal EFI Bug. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.