viking777 wrote:I have no idea how my boot system works, I don't even know if it is Uefi or legacy bios, I think it is Uefi for the following reasons:
First, it's critical to distinguish between two things:
- Whether your firmware is capable of booting in EFI mode.
- Whether a specific boot is in EFI mode.
Most (in fact all, to the best of my knowledge) x86-64 systems with EFI have the ability to boot in either BIOS/legacy/CSM mode or in EFI mode. Thus, being EFI-capable does not guarantee an EFI-mode boot. Some of your tests hint at EFI-mode capability and others hint at (or prove) actual EFI-mode boots.
Code: Select all
apt-cache policy grub-efi-amd64
grub-efi-amd64:
Installed: 2.00-7ubuntu11
Candidate: 2.00-7ubuntu11
Code: Select all
find /boot/efi/EFI -iname "*.efi"
/boot/efi/EFI/ubuntu/grubx64.efi
/boot/efi/EFI/mint/grub.efi
/boot/efi/EFI/Boot/bootx64.efi
/boot/efi/EFI/manjaro_grub/grubx64.efi
/boot/efi/EFI/manjaro_grub/grubx64_standalone.efi
/boot/efi/EFI/tools/Shell.efi
These are both suggestive, but not really conclusive evidence, of an EFI-mode install. You
can install an EFI boot loader on a BIOS-booting computer; it just won't do anything. Likewise, you can install an EFI-mode boot loader on an EFI-capable computer but then boot it in BIOS mode (assuming another BIOS-mode boot loader is also installed).
Code: Select all
ls /sys/firmware
acpi/ efi/ memmap/
Code: Select all
dmesg | grep EFI
[ 0.000000] efi: EFI v2.31 by Phoenix Technologies Ltd.
[ 0.000000] ACPI: UEFI 00000000dafe6000 0003E (v01 FUJ PC 00000001 FUJ 00000001)
[ 0.000000] ACPI: UEFI 00000000dafe5000 00042 (v01 PTL COMBUF 00000001 PTL 00000001)
[ 0.000000] ACPI: UEFI 00000000dafe3000 00292 (v01 FUJ PC 00000001 FUJ 00000001)
[ 0.538153] fb0: EFI VGA frame buffer device
[ 0.753276] EFI Variables Facility v0.08 2004-May-17
[ 18.129624] fb: conflicting fb hw usage inteldrmfb vs EFI VGA - removing generic driver
These are both conclusive evidence of an EFI-mode boot.
Quote from linlap.com re this machine.
Notes
This is an UEFI system.
Take this as seriously as you'd take anything else you read on the Web. Certainly it says nothing about a specific boot of the computer.
Excerpt from a boot-repair script
/boot/efi detected in the fstab of sda2: UUID=DDE9-FCDA (sda1)
ls: cannot access : No such file or directory
=================== UEFI/Legacy mode :
BIOS is EFI-compatible, and is setup in EFI-mode for this installed-session.
The presence of /boot/efi in /etc/fstab implies that the installer did its work in EFI mode; however, it could be that the installer was buggy or that you (or some other tool) added such an entry manually afterward, so it's not really conclusive. I don't know how the Boot Repair script is detecting the firmware's EFI capabilities. My guess is that it's checking for EFI runtime variables, which would be conclusive proof of an EFI-mode boot, albeit redundant with the conclusive evidence you posted earlier.
So that should be enough right? Why would it not be a Uefi install?
In your case,
the specific session you're running is an EFI-mode install. There's no mystery here. You've posted about this before, and I've said the same thing.
Because it is impossible to install anything else in Uefi mode and impossible to run the command efibootmgr.
It's hard to offer advice about your inability to boot in EFI mode because EFI user interfaces vary so much -- what works on one computer doesn't work on another one. As to efibootmgr, you're running into either a bug in efibootmgr or a bug in your firmware that's manifesting as an inability to use efibootmgr. Given the other information I have on your firmware, my guess is it's the latter.
Example: This Mint14 disk is clearly a Uefi capable disk
Code: Select all
find /media/LXFDVD167/Mint64/ -iname "*.efi"
/media/LXFDVD167/Mint64/EFI/BOOT/BOOTx64.EFI
/media/LXFDVD167/Mint64/EFI/BOOT/grubx64.efi
But when booting from the disk and running ls /sys/firmware the efi directory does not exist, which in turn means the dvd is booted in legacy mode, which in turn means that if I installed from it, it would install in legacy mode.
EFI boots using
El Torito, in which a FAT filesystem is stored in a file and used as if it were a boot floppy. Thus, the presence or absence of .efi files on the ISO-9660 filesystem are actually irrelevant. Most bootable Linux discs contain such files as duplicates of what's in the El Torito image, but this isn't guaranteed. Also, an improperly-prepared El Torito image can produce a disc that's unbootable in EFI mode despite the presence of .efi files in the ISO-9660 filesystem. To make matters worse, many Linux installation disk images use a "hybrid" (ISO-9660/MBR) format that enables them to be either burned to an optical disc or written to a USB flash drive. Such formats are fairly tortuous and can fail on some firmware (either BIOS or EFI).
That said, your conclusion that you've booted in BIOS mode because of the absence of a /sys/firmware/efi directory is almost certainly correct. It's possible you could force an EFI-mode boot by removing BIOS-boot support from the boot medium. This is likely to be tricky for a CD/DVD boot because of the need to prepare an El Torito image with EFI but not BIOS support. It could be easier with a USB flash drive, though: Just prepare a USB flash drive with a FAT filesystem and do a file-level copy of everything in the ISO-9660 filesystem to the flash drive. OTOH, the installer might want to see a filesystem with a particular name, so you might need to set it appropriately or use a combination of the DVD and the USB flash drive to boot the computer to run the installer.
So simple, go into your bios settings and enable Uefi.
My bios settings screen has no entries even remotely relating to Uefi. I can't take screenshots of my bios settings so you will have to believe me on this.
I believe you. This means you've got a bad firmware user interface. Blame your computer's manufacturer.
Why not look in your motherboard manual for details of how to enable/disable Uefi?
I have two words in answer to that - find one!
Here are all the details I have of my motherboard (courtesy of hwinfo I think it was).
Board Info: #18
Manufacturer: "FUJITSU"
Product: "FJNBB1C"
Serial: "578703-01R2704024"
Type: 0x0a (Motherboard)
Features: 0x01
Hosting Board
Try for yourself if you like - a lot of those entries are 'googlewhacks'!
To the best of my knowledge, Fujitsu doesn't make motherboards for desktop computers, but they do make laptop computers. You're more likely to find manuals for laptops if you search on the laptop's model number rather than the model number of the motherboard in the laptop. Checking Fujitsu's site for manuals might yield fruit; however, when I Googled the information you provided, I was led to a Fujitsu laptop model AH532, for which Fujitsu has
this page, which has no obvious manual. Maybe it's hidden somewhere else, or maybe you've got another model for which Fujitsu actually has a manual; but based on my limited search, I'd say that Fujitsu is being anal-retentive with information about their products.
So why not boot with Refind and use it to boot the dvd in Uefi mode?
Because Refind doesn't see any efi entries on my dvd drive, in fact it doesn't see any entries on my dvd drive (or the shell entry in my ESP).
Sometimes these devices are hidden from rEFInd if the firmware doesn't scan them. You might be able to get some entries by using your firmware's own boot manager or by adjusting firmware boot options to explicitly include the optical drive in the boot list.
Another option is to prepare a hard disk partition that's at least as large as the disk and then do a low-level copy of the DVD to that partition, as in "sudo dd if=/dev/sr0 of=/dev/sda8" (or "sudo dd if=diskimage.iso of=/dev/sda8" to copy a disc image file), changing "/dev/sda8" as necessary. You can then install the rEFInd ISO-9660 driver and it should be able to boot from the image on the hard disk.
If anyone would like to have a stab at explaining all that then good luck to you, it has me completely beaten. Obviously my motherboard has the Uefi implementation from hell,
You've already explained it: Your EFI implementation is bug-ridden. It
might be possible for Linux developers to include workarounds or fixes in tools like efibootmgr and rEFInd, but this would require that the developers have access to the hardware, or for somebody who owns the hardware and who has sufficient programming experience to submit a patch to the relevant application developers. (Speaking as the developer of rEFInd, I don't own any Samsung computer, and I lack the sort of budget that would enable me to buy one just to experiment with a known-buggy EFI implementation. If you care to lend me the computer, I can have a look at it, but I can't make any promises about finding fixes.)
A less radical solution is to check with Samsung to see if they've got an updated firmware. If not, contact tech support.
You might also try using Fedora and, if it has problems, contact
Matthew Garrett. He's doing much of the really low-level EFI stuff for Linux, and so might know of solutions or at least be able to direct you to somebody who's working on whatever subsystem is causing problems. I suggested installing Fedora because Garrett was, until recently, a Red Hat employee and is still closely involved in the Fedora project. Thus, he might be more receptive to helping if you can reproduce problems in Fedora. Also, Fedora is well ahead of the pack in terms of EFI support. I'd say that Mint is somewhere in the middle, which really is not very good, since Linux as a whole is behind where it should be. This
will improve with time, but it will take time to get the support to where it should be.
but I would love to be able to do three things, run efibootmgr, boot shell.efi and install other distros in Uefi mode.
You can boot an EFI shell from rEFInd: Install it in the EFI/tools directory or the root directory on the ESP and it should show up as an option in the rEFInd menu, on the second row of (smaller) icons. (It should be called shellx64.efi.) Note that there are several EFI shell binaries, and not all of them will work. You probably need a 64-bit shell, not a 32-bit shell of a "fat" (32-/64-bit) binary. There are also version 1 and version 2 shells, with version 2 shells being more troublesome. (Theoretically, the troubles should be gone with an EFI as recent as yours, but given your other problems, I wouldn't rule anything out in terms of problems.)
As far as I can tell, your problems aren't with UEFI generally, but with
Samsung's UEFI implementation. This is nothing new: We've had buggy BIOSes for years. Linux has had 20 years to come to grips with these problems, so the workarounds are mature, and BIOSes from the last decade or so have had fewer problems than the BIOSes from the 1980s and early 1990s. EFI is newer, manufacturers have rushed their EFI implementations out with insufficient testing, and the Linux community has neglected the coming EFI storm for too long, leading to the sorts of problems you're having. They
will subside with time.
One more comment: Given the severity of your problems, you should seriously consider ditching EFI-mode booting on your computer. This is most easily done by wiping the hard disk, creating a new MBR partition table on it, and re-installing everything; however, you can do it by converting from GPT to MBR and converting your existing OS installations, if necessary.