| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 43 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 95:35:30 |
| Calls: | 290 |
| Files: | 904 |
| Messages: | 76,423 |
The boot device is currently /dev/sdb which has a GPT partition table, and its first few partitions are
number size mount point
1 953MB /boot
2 2GB /
3 10GB /usr
11 9GB /home
13 48GB swap
5 953MB unmounted, filesystem="grub2 core.img", flags="bios_grub"
I swear I ran a program that showed me EFI boot vars (if they exist)
and it showed nothing. But now I can't remember what that program
was.
How can I ensure that I'm actually booted using EFI?
How can I
ensure that I'm actually booted using EFI?
Hi,...
On Sun, Dec 29, 2024 at 11:26:38AM -0500, Eben King wrote:
The boot device is currently /dev/sdb which has a GPT partition table, and >> its first few partitions are
number size mount point
Does UEFI booting not require an EFI System Partition (ESP) of type vfat typically mounted at /boot/efi on Debian?
I swear I ran a program that showed me EFI boot vars (if they exist)
and it showed nothing. But now I can't remember what that program
was.
Probably "efivar --list". It's in the "efivar" package and not installed
by default.
How can I ensure that I'm actually booted using EFI?
If you're booted by UEFI then /sys/firmware/efi/ will exist.
My motherboard is a Gigabyte H170
My motherboard is a Gigabyte H170 with 32 GiB RAM and I run Debian 12.8. I
swear I ran a program that showed me EFI boot vars (if they exist) and it showed nothing. But now I can't remember what that program was. How can I ensure that I'm actually booted using EFI?
Eben King <eben@gmx.us> wrote:OK, the manual covers two models, GA-H170-Gaming3 and GA-H170-Gaming3 DDR3. Mine's the one that isn't DDR3. How would I tell if my BIOS is licensed or not?
My motherboard is a Gigabyte H170
That doesn't seem to be precise enough. They make multiple boards with
that general name and all but one support UEFI. But the GA-H170TN does
not mention UEFI, although its spec does say "Use of licensed AMI UEFI
BIOS".
On 12/29/24 11:38, Andy Smith wrote:
Hi,
On Sun, Dec 29, 2024 at 11:26:38AM -0500, Eben King wrote:...
The boot device is currently /dev/sdb which has a GPT partition
table, and its first few partitions are
number size mount point
Does UEFI booting not require an EFI System Partition (ESP) of type
vfat typically mounted at /boot/efi on Debian?
eben@cerberus:~$ ls /boot/efi
ls: cannot access '/boot/efi': No such file or directory
Fudge.
I swear I ran a program that showed me EFI boot vars (if they
exist) and it showed nothing. But now I can't remember what that
program was.
Probably "efivar --list". It's in the "efivar" package and not
installed by default.
Thanks. It was probably in a live CD environment.
How can I ensure that I'm actually booted using EFI?
If you're booted by UEFI then /sys/firmware/efi/ will exist.
eben@cerberus:~$ ls -ld /sys/firmware/efi
ls: cannot access '/sys/firmware/efi': No such file or directory
Bummer. OK. Has anyone booted using EFI with this motherboard?
Either I've done something wrong, or its EFI implementation is shoddy
or remarkable forgiving of incompetent installations.
Good luck with yours. FINALLY fixing this a couple years ago was so empowering. Without boot, we got no computers. :)
I think I've done everything reasonable in my firmware to ensure booting by EFI. I have:maybe this will help.
Storage boot option control UEFI only
Other PCI device ROM priority UEFI only
(other options for both are "Legacy only" and "Disabled")
other systems<UEFI - Windows Boot Manager
The boot device is currently /dev/sdb which has a GPT partition table, and its first few partitions are
number size mount point
1 953MB /boot
2 2GB /
3 10GB /usr
11 9GB /home
13 48GB swap
5 953MB unmounted, filesystem="grub2 core.img", flags="bios_grub"
The first four are ext4.
I do recall it was a pain to make d-i keep the GPT table not overwrite it with an MBR one.
My motherboard is a Gigabyte H170 with 32 GiB RAM and I run Debian 12.8. I swear I ran a program that showed me EFI boot vars (if they exist) and it showed nothing. But now I can't remember what that program was. How can I ensure that I'm actually booted using EFI?
On 12/29/24 12:51, debian-user@howorth.org.uk wrote:
Eben King <eben@gmx.us> wrote:
My motherboard is a Gigabyte H170
That doesn't seem to be precise enough. They make multiple boardsOK, the manual covers two models, GA-H170-Gaming3 and GA-H170-Gaming3
with that general name and all but one support UEFI. But the
GA-H170TN does not mention UEFI, although its spec does say "Use of licensed AMI UEFI BIOS".
DDR3. Mine's the one that isn't DDR3. How would I tell if my BIOS is licensed or not?
On 12/29/24 08:26, Eben King wrote:
I think I've done everything reasonable in my firmware to ensure
booting by EFI. I have:
Storage boot option control UEFI onlymaybe this will help.
Other PCI device ROM priority UEFI only
(other options for both are "Legacy only" and "Disabled")
Debian, and others show in GRUB, but not windows 10.
HP workstation: I press F9 on boot for a boot menu
I get a listing:
UEFI - debian
other systems<UEFI - Windows Boot Manager
It boots fine.
Restart and I get GRUB, but without a windows option
On Sun, 29 Dec 2024 11:07:18 -0800
Peter Ehlert <peter@sdi-baja.com> wrote:
On 12/29/24 08:26, Eben King wrote:If you run update-grub, do you see a warning that os-prober will not be executed? After installation or upgrade to grub, os-prober is disabled
I think I've done everything reasonable in my firmware to ensuremaybe this will help.
booting by EFI. I have:
Storage boot option control UEFI only
Other PCI device ROM priority UEFI only
(other options for both are "Legacy only" and "Disabled")
Debian, and others show in GRUB, but not windows 10.
HP workstation: I press F9 on boot for a boot menu
I get a listing:
UEFI - debian
>other systems<
UEFI - Windows Boot Manager
It boots fine.
Restart and I get GRUB, but without a windows option
and will not detect Windows or any other OS that may be installed.
https://forum.manjaro.org/t/grub2-why-is-os-prober-now-disabled-by-default/57599
The answer is to modify /etc/default/grub and run update-grub again:
To restore the old behavior, open a terminal and issue sudo echo
GRUB_DISABLE_OS_PROBER=false >> /etc/default/grub && sudo update-grub
Note that you will need to do this again when grub is upgraded.
If you run update-grub, do you see a warning that os-prober will
not be executed? After installation or upgrade to grub, os-prober
is disabled and will not detect Windows or any other OS that may be installed.
os-prober is activated. the other Linux distros are listed.
Top big must-have *for me* was a dedicated partition for EFI.
Somewhere
I read that HAS to be an extremely early partition on the hard drive.
Today I learned it can be anywhere so the problems I had years ago were
NOT due to that. [0]
Additionally, until now I've always had an MBR partition at the front of
my hard drives. Thanks to your question, I've just now learned that is
NOT recommended and might cause compatibility issues, too. [1] Each User
has to decide what to do there based on what their multiple operating
systems demand for booting. I simply reformatted mine as EXT4 (for now).
My UEFI partition is formatted as FAT32 then I manually verify that it's flagged as msftdata. I use Gparted that is being a tiny bit unpredictble
if left on its own to perform that function.
My /etc/fstab mounts EFI partition to Debian and GRUB's default
/boot/efi hierarchy. The "type" (third declaration on EFI's fstab line)
is "vfat".
[0] https://superuser.com/questions/1834990/how-do-i-rearrange-a-wrong-order-of-efi-and-boot-partitions
[1] https://superuser.com/questions/739153/uefi-with-mbr-partition-table
The answer is to modify /etc/default/grub and run update-grub again:
To restore the old behavior, open a terminal and issue sudo echo
GRUB_DISABLE_OS_PROBER=false >> /etc/default/grub && sudo update-grub
Note that you will need to do this again when grub is upgraded.
Create EFI System Partition: it should have proper partition type UUID and
it is not recommended to make it too small (<500 MB).
My fault, I forgot to post a link with some reasoning: <https://fedoraproject.org/wiki/Changes/BiggerESP>
Nicolas, I am not trying to force *you* to resize ESP partitions on your machines. However I consider it safer to use bigger partition in general case, especially due to some uncertainties in respect to specific configuration.
Are you sure that fwupd will never try put a large enough file to update firmware of some device?
My experience is that laptop firmware updater,
launched from a USB stick, creates some files on the internal drive. Are you
sure that unified kernel images will not become default before the user replaces their drive?