Re: [gentoo-user] UEFI booting again - FIXED
On Monday, 19 October 2020 18:08:53 -00 Michael wrote: > However, I don't think anyone would argue against empirical repeatable > outcomes. :-) :) -- Regards, Peter.
Re: [gentoo-user] UEFI booting again - FIXED
On Monday, 19 October 2020 17:10:57 BST Peter Humphrey wrote: > On Monday, 19 October 2020 14:08:05 -00 Michael wrote: > > Are you saying calling 'efibootmgr -v' lists a different UEFI boot menu? > > No, I'm saying that I appear to be able to create a BIOS entry using > efibootmgr, but when I reboot and enter BIOS setup, the entry often isn't > there. Or if it is, either the kernel won't boot, or it does but the > resulting system is incomplete. > > When I bought this system I failed entirely to install grub - I followed the > instructions slavishly and received much help from those more knowledgeable > on this list at the time, but never got the system to boot. Then, groping > about trying to understand efibootmgr, bootctl and UEFI generally, I may > have done some combination of things that prevented those tools from ever > working again. For me. On this machine. > > So the summary is: I can preserve the ESP using Windows's system image > creation and recovery tool, but not with those two Linux tools. > > I've wasted several months wrestling with this, and I've finished up with > what I've described. I see. What you describe is interesting, because the UEFI firmware GUI, efibootmgr, and MSWindows are all meant to be accessing the *same* database of editable entries on the firmware, using the UEFI API. I have not looked into bootctl more than once to know what it does with any clarity. However, I don't think anyone would argue against empirical repeatable outcomes. :-) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] UEFI booting again - FIXED
On Monday, 19 October 2020 14:08:05 -00 Michael wrote: > Are you saying calling 'efibootmgr -v' lists a different UEFI boot menu? No, I'm saying that I appear to be able to create a BIOS entry using efibootmgr, but when I reboot and enter BIOS setup, the entry often isn't there. Or if it is, either the kernel won't boot, or it does but the resulting system is incomplete. When I bought this system I failed entirely to install grub - I followed the instructions slavishly and received much help from those more knowledgeable on this list at the time, but never got the system to boot. Then, groping about trying to understand efibootmgr, bootctl and UEFI generally, I may have done some combination of things that prevented those tools from ever working again. For me. On this machine. So the summary is: I can preserve the ESP using Windows's system image creation and recovery tool, but not with those two Linux tools. I've wasted several months wrestling with this, and I've finished up with what I've described. -- Regards, Peter.
Re: [gentoo-user] UEFI booting again - FIXED
On Monday, 19 October 2020 13:08:35 BST Peter Humphrey wrote: > On Sunday, 11 October 2020 23:21:49 -00 pe...@prh.myzen.co.uk wrote: > > Can anyone please tell me precisely where 'efibootmgr -c ...' writes a > > boot > > record, or whatever it's called? My machine seems unable to store what I > > give it, and I suspect that the BIOS ROM has failed. Big expense if so. > > I have a bootable system again. > > In one line: I need Windows as part of my system maintenance. > > Yes, I did mean to write that. Let me explain. > > Every attempt of mine to write bootable images failed. I still don't know > why, but while I was trying everything I could think of, I ran Windows (on > /dev/ sdb) to restore a system image (from /dev/sda; /root is on > /dev/nvme0n1). On rebooting, lo! and behold! there was a boot menu! It was > an old one, dating from when I created the system image in Windows, but > after booting from USB and adding the right kernels and /boot/loader/ > structure, and running 'bootclt update', a reboot showed me the proper boot > menu. > > A kernel upgrade arrived today, so after installing it and updating the > /boot/ loader config, I ran Windows again to create a new system image. > > So on my machine, efibootmgr is no use. I have to use bootctl from > systemd-boot to manage my bootable images. And Windows to preserve them. > > I've attached a shot of the boot menu I've been referring to in this thread. > It's not pretty, but there's only so much I can do with a curved screen and > a hand-held phone. I am confused ... Are you saying calling 'efibootmgr -v' lists a different UEFI boot menu? o_O signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: [gentoo-user] UEFI booting again
On Monday, 12 October 2020 17:43:04 BST Michael wrote: > The UEFI firmware contains a number of variables in key/value pairs, stored > on NVRAM. One of these is a table containing a Boot Menu within an > editable area of the firmware, which can be manipulated with the EFI shell > (efibootmgr) to set, rename, delete bootable .efi images. [...etc] Thanks Michael; more-or-less what I thought. -- Regards, Peter.
Re: [gentoo-user] Re: [gentoo-user] UEFI booting again
On Monday, 12 October 2020 10:15:16 BST pe...@prh.myzen.co.uk wrote: > On 2020-10-12 12:26 AM, "Jack" wrote: > > On 10/11/20 7:37 PM, Jude DaShiell wrote: > > > If you followed the handbook /dev/sda2 would be where the boot record > > > lives.> > > I don't think so, but the terminology is certainly confusing. Peter > > asked where efibootmgr writes something. What is on /dev/sda2 could be > > grub.cfg if it were mounted at /boot, and the grub booting stub (I > > forget the correct name, but grubx64.efi) might be on /dev/sda2 if it > > were mounted at /boot/EFI. However, efibootmgr doesn't mess with either > > of those. It deals with what is stored in the UEFI boot firmware. That > > entry, which is read by the UEFI at boot time, runs the entry in the EFI > > disk partition (usually under /boot/EFI), which then runs the kernel > > (and possibly initramfs) in /boot. Unfortunately, "boot record" is > > probably too general a term. > > Yes, I meant the equivalent of that in an MBR system. Where the bootable > kernel image lives is another matter. The MBR's architecture is a bit different to UEFI. Legacy BIOS in CMOS has a jump command to the MBR 'boot sector', stored @sector 0, which in the first 446 bytes contains a bootstrap code and thereafter a partition table. The bootstrap code signature is checked by BIOS and loaded in RAM where it is executed as a boot loader. The bootstrap code (a.k.a. boot.img) contains a pointer to either Stage 1.5 or Stage 2. Stage 1.5 starts on Sector 1 and has any filesystem drivers needed to access and read Stage 2. Some boot loaders jump into a partition and load hardcoded sectors into RAM, which then run in order to load the rest of the OS boot image and execute it. These are Stage 1 boot loaders. Other boot loaders like GRUB, load Stage 1 drivers and use these to access the stage 2 files in /boot, present a boot menu and load an OS kernel image. With UEFI a lot of the above is stored in the much larger compared to CMOS UEFI firmware NVRAM. The UEFI has its own bootstrap code, plus a boot manager, boot menu table and requisite device drivers, to access the ESP, or other bootable devices. UEFI can load and execute any compatible UEFI applications from ESP, including OS boot loaders. > I haven't been using grub, just efibootmgr to declare the image to the UEFI > BIOS, and bootctl from systemd-boot to show a list of boot options. > > I assume there's something like an EEPROM on the motherboard to contain > pointers (what I called boot records) to the the bootable kernel images. > That's what I was asking about. I'm pretty sure that that table doesn't > live on the disk. (Followers of this tale may remember that I had a problem > with the NVMe disk; it turned out to be faulty, and I've replaced it. > Windows could still boot on another disk without any intervention by me.) > > Can someone confirm or refute those ideas? The UEFI firmware contains a number of variables in key/value pairs, stored on NVRAM. One of these is a table containing a Boot Menu within an editable area of the firmware, which can be manipulated with the EFI shell (efibootmgr) to set, rename, delete bootable .efi images. Upon a reboot the UEFI boot manager will scan the ESP and other similar VFAT partitions and bootable devices (CD/USB) for executable UEFI applications, to re-list any .efi bootable images it finds in its GUI boot menu. If the previously configured boot menu order is lost/corrupted, a rescanned ESP may not arrive at the same order of bootable images. As I understand it the concern of the OP here is the EEPROM chip may have corrupted its editable content. Different OEMs have different solutions, with OOB hypervisors managing backup/restore functions, to using a secondary Boot Block found in the main Firmware chip, but at an alternate address location, to using two separate EEPROM chips and so on and using some jumper to restore from the backup. If major firmware malfunction is suspected, then re-flashing the MoBo with the latest version of OEM firmware should hopefully restore sanity. If the MoBo chip is faulty, or on its way out, then the failure mode will soon repeat itself. signature.asc Description: This is a digitally signed message part.
[gentoo-user] Re: [gentoo-user] UEFI booting again
On 2020-10-12 12:26 AM, "Jack" wrote: > On 10/11/20 7:37 PM, Jude DaShiell wrote: > > If you followed the handbook /dev/sda2 would be where the boot record lives. > > I don't think so, but the terminology is certainly confusing. Peter > asked where efibootmgr writes something. What is on /dev/sda2 could be > grub.cfg if it were mounted at /boot, and the grub booting stub (I > forget the correct name, but grubx64.efi) might be on /dev/sda2 if it > were mounted at /boot/EFI. However, efibootmgr doesn't mess with either > of those. It deals with what is stored in the UEFI boot firmware. That > entry, which is read by the UEFI at boot time, runs the entry in the EFI > disk partition (usually under /boot/EFI), which then runs the kernel > (and possibly initramfs) in /boot. Unfortunately, "boot record" is > probably too general a term. Yes, I meant the equivalent of that in an MBR system. Where the bootable kernel image lives is another matter. I haven't been using grub, just efibootmgr to declare the image to the UEFI BIOS, and bootctl from systemd-boot to show a list of boot options. I assume there's something like an EEPROM on the motherboard to contain pointers (what I called boot records) to the the bootable kernel images. That's what I was asking about. I'm pretty sure that that table doesn't live on the disk. (Followers of this tale may remember that I had a problem with the NVMe disk; it turned out to be faulty, and I've replaced it. Windows could still boot on another disk without any intervention by me.) Can someone confirm or refute those ideas? > > Jack > > > On Sun, 11 Oct 2020, pe...@prh.myzen.co.uk wrote: > > > >> Date: Sun, 11 Oct 2020 19:21:49 > >> From: pe...@prh.myzen.co.uk > >> Reply-To: gentoo-user@lists.gentoo.org > >> To: gentoo-user@lists.gentoo.org > >> Subject: [gentoo-user] UEFI booting again > >> > >> I'm still wrestling with my system and its not booting. > >> > >> Can anyone please tell me precisely where 'efibootmgr -c ...' writes a > >> boot record, or whatever it's called? My machine seems unable to store > >> what I give it, and I suspect that the BIOS ROM has failed. Big expense if > >> so. > >> > >> TiA. >
Re: [gentoo-user] UEFI booting again
On 10/11/20 7:37 PM, Jude DaShiell wrote: If you followed the handbook /dev/sda2 would be where the boot record lives. I don't think so, but the terminology is certainly confusing. Peter asked where efibootmgr writes something. What is on /dev/sda2 could be grub.cfg if it were mounted at /boot, and the grub booting stub (I forget the correct name, but grubx64.efi) might be on /dev/sda2 if it were mounted at /boot/EFI. However, efibootmgr doesn't mess with either of those. It deals with what is stored in the UEFI boot firmware. That entry, which is read by the UEFI at boot time, runs the entry in the EFI disk partition (usually under /boot/EFI), which then runs the kernel (and possibly initramfs) in /boot. Unfortunately, "boot record" is probably too general a term. Jack On Sun, 11 Oct 2020, pe...@prh.myzen.co.uk wrote: Date: Sun, 11 Oct 2020 19:21:49 From: pe...@prh.myzen.co.uk Reply-To: gentoo-user@lists.gentoo.org To: gentoo-user@lists.gentoo.org Subject: [gentoo-user] UEFI booting again I'm still wrestling with my system and its not booting. Can anyone please tell me precisely where 'efibootmgr -c ...' writes a boot record, or whatever it's called? My machine seems unable to store what I give it, and I suspect that the BIOS ROM has failed. Big expense if so. TiA.
Re: [gentoo-user] UEFI booting again
In gentoo in order to make a uefi system is it necessary to use douefi as a boot parameter when starting the install? If so, it wasn't in the handbook I read. If not, my guess would be gentoo discovers this information for itself. --
Re: [gentoo-user] UEFI booting again
If you followed the handbook /dev/sda2 would be where the boot record lives. On Sun, 11 Oct 2020, pe...@prh.myzen.co.uk wrote: > Date: Sun, 11 Oct 2020 19:21:49 > From: pe...@prh.myzen.co.uk > Reply-To: gentoo-user@lists.gentoo.org > To: gentoo-user@lists.gentoo.org > Subject: [gentoo-user] UEFI booting again > > I'm still wrestling with my system and its not booting. > > Can anyone please tell me precisely where 'efibootmgr -c ...' writes a boot > record, or whatever it's called? My machine seems unable to store what I give > it, and I suspect that the BIOS ROM has failed. Big expense if so. > > TiA. > > > > > > > --
Re: [gentoo-user] UEFI booting again
On 23:21 Sun 11 Oct 2020, pe...@prh.myzen.co.uk wrote: I'm still wrestling with my system and its not booting. Can anyone please tell me precisely where 'efibootmgr -c ...' writes a boot record, or whatever it's called? My machine seems unable to store what I give it, and I suspect that the BIOS ROM has failed. Big expense if so. TiA. You might give it a shot like this : https://github.com/unixbhaskar/UEFI_Linux_Boot_Process_From_Userland Good luck! signature.asc Description: PGP signature
Re: [gentoo-user] UEFI booting
On Sunday 28 Aug 2016 10:26:15 Mike Gilbert wrote: > On Sun, Aug 28, 2016 at 6:55 AM, Peter Humphrey wrote: --->8 > > ... part of the output of "bootctl status": > > > > Boot Loader Binaries: > > ESP: > > /dev/disk/by-partuuid/f3fa7b95-0a65-4716-924a-ae3f30811de5 > > > > File: └─/EFI/systemd/systemd-bootx64.efi (systemd-boot 231) > > File: └─/EFI/BOOT/BOOTX64.EFI > > > > Those binaries have been built on my system: by what process? > > When you run bootctl install, it copies > /usr/lib/systemd/boot/efi/systemd-bootx64.efi to > /boot/EFI/systemd/systemd-bootx64.efi and /boot/EFI/BOOT/BOOTX64.EFI. Ah, so when one of those is started, all it does (for present purposes) is to load the kernel specified in the appropriate /boot/loader/entries entry. > BOOTX64.EFI is only there as a fallback; if your EFI variables get > reset for some reason, most EFI firmwares will look for a file by that > name as a failsafe. I think I'd more-or-less inferred that, but thanks for the confirmation. -- Rgds Peter
Re: [gentoo-user] UEFI booting
On Sun, Aug 28, 2016 at 6:55 AM, Peter Humphrey wrote: > On Sunday 28 Aug 2016 10:55:56 Neil Bothwick wrote: >> On Sun, 28 Aug 2016 10:43:17 +0100, Peter Humphrey wrote: >> > I'd still like to know where the directory /usr/lib64/systemd/boot/efi >> > came from though. >> >> Surely it's from systemd-boot, it is installed by systemd here. What does >> qfile tell you? >> >> $ qfile /usr/lib/systemd/boot/efi > > Yes, it is. I was puzzling over the wrong thing. Here's part of the output > of "bootctl status": > > Boot Loader Binaries: > ESP: /dev/disk/by-partuuid/f3fa7b95-0a65-4716-924a-ae3f30811de5 > File: └─/EFI/systemd/systemd-bootx64.efi (systemd-boot 231) > File: └─/EFI/BOOT/BOOTX64.EFI > > Those binaries have been built on my system: by what process? When you run bootctl install, it copies /usr/lib/systemd/boot/efi/systemd-bootx64.efi to /boot/EFI/systemd/systemd-bootx64.efi and /boot/EFI/BOOT/BOOTX64.EFI. BOOTX64.EFI is only there as a fallback; if your EFI variables get reset for some reason, most EFI firmwares will look for a file by that name as a failsafe.
Re: [gentoo-user] UEFI booting
On Sunday 28 Aug 2016 10:55:56 Neil Bothwick wrote: > On Sun, 28 Aug 2016 10:43:17 +0100, Peter Humphrey wrote: > > I'd still like to know where the directory /usr/lib64/systemd/boot/efi > > came from though. > > Surely it's from systemd-boot, it is installed by systemd here. What does > qfile tell you? > > $ qfile /usr/lib/systemd/boot/efi Yes, it is. I was puzzling over the wrong thing. Here's part of the output of "bootctl status": Boot Loader Binaries: ESP: /dev/disk/by-partuuid/f3fa7b95-0a65-4716-924a-ae3f30811de5 File: └─/EFI/systemd/systemd-bootx64.efi (systemd-boot 231) File: └─/EFI/BOOT/BOOTX64.EFI Those binaries have been built on my system: by what process? -- Rgds Peter
Re: [gentoo-user] UEFI booting
On Sun, 28 Aug 2016 10:43:17 +0100, Peter Humphrey wrote: > I'd still like to know where the directory /usr/lib64/systemd/boot/efi > came from though. Surely it's from systemd-boot, it is installed by systemd here. What does qfile tell you? $ qfile /usr/lib/systemd/boot/efi -- Neil Bothwick I get enough exercise just pushing my luck. pgpYREJBNQBOP.pgp Description: OpenPGP digital signature
Re: [gentoo-user] UEFI booting
On Friday 26 Aug 2016 16:13:53 Mike Gilbert wrote: > On Fri, Aug 26, 2016 at 4:32 AM, Peter Humphrey wrote: > > In my search for a suitable boot method, I'm trying Mike G's > > systemd-boot > > ebuild. I've installed it with no problem, and now I reach the heart-in- > > mouth stage of actually replacing gummiboot with it. But first, the > > backup, including dd of what used to be called the MBR (what is it > > now?). > It should be basically a drop-in replacement, with a slightly > different name. It should not require any modification to your disk > layout. I've learned a few things over the last day, and now I have systemd-boot installed and gummiboot gone (late and somewhat lamented). # bootctl status System: Firmware: UEFI 2.31 (American Megatrends 5.09) Secure Boot: disabled Setup Mode: setup Loader: Product: systemd-boot 231 Partition: /dev/disk/by-partuuid/f3fa7b95-0a65-4716-924a-ae3f30811de5 File: └─/EFI/SYSTEMD/SYSTEMD-BOOTX64.EFI Boot Loader Binaries: ESP: /dev/disk/by-partuuid/f3fa7b95-0a65-4716-924a-ae3f30811de5 File: └─/EFI/systemd/systemd-bootx64.efi (systemd-boot 231) File: └─/EFI/BOOT/BOOTX64.EFI Boot Loader Entries in EFI Variables: Title: Linux Boot Manager ID: 0x0001 Status: active, boot-order Partition: /dev/disk/by-partuuid/f3fa7b95-0a65-4716-924a-ae3f30811de5 File: └─/EFI/SYSTEMD/SYSTEMD-BOOTX64.EFI Title: UEFI OS ID: 0x000C Status: active, boot-order Partition: /dev/disk/by-partuuid/f3fa7b95-0a65-4716-924a-ae3f30811de5 File: └─/EFI/BOOT/BOOTX64.EFI I'd still like to know where the directory /usr/lib64/systemd/boot/efi came from though. https://wiki.archlinux.org/index.php/systemd-boot was the last link I needed; I hadn't realised until then that bootctl uses the same /boot/loader/... arrangement as gummiboot, Mike's "drop-in replacement" comment notwithstanding. I suggest that the Gentoo docs could use a version of this web page. > Also, you should be able to configure your firmware to load either > gummiboot or systemd-boot, so you have a fallback if the new code > fails. I did that, but now I'm happy with bootctl I've removed gummiboot. I took the opportunity of changing the partition layout somewhat. When I restored all my backups I found errors from polkit and dbus, which were preventing KDE from running properly. I assume this was because the partitions had new UUIDs. A quick "emerj -1av $(eix -cI# polkit)" and ditto dbus fixed it. alias emerj='sudo emerge --jobs=24 --load-average=48 --keep-going --nospinner' So thanks to Mike I now have a stable, maintainable system that suits me. -- Rgds Peter
Re: [gentoo-user] UEFI booting
On Friday 26 Aug 2016 16:13:53 Mike Gilbert wrote: > On Fri, Aug 26, 2016 at 4:32 AM, Peter Humphrey wrote: > > In my search for a suitable boot method, I'm trying Mike G's > > systemd-boot > > ebuild. I've installed it with no problem, and now I reach the heart-in- > > mouth stage of actually replacing gummiboot with it. But first, the > > backup, including dd of what used to be called the MBR (what is it > > now?). > It should be basically a drop-in replacement, with a slightly > different name. It should not require any modification to your disk > layout. After running "bootctl install" I now have bootctl the binary from the systemd-boot package, gummiboot the binary from the gummiboot package. They each install a loader called "Linux Boot Loader" into the EFI variables, as you can see from this: # bootctl status System: Firmware: UEFI 2.31 (American Megatrends 5.09) Secure Boot: disabled Setup Mode: setup Loader: Product: systemd-boot 231 Partition: /dev/disk/by-partuuid/e41cc9a5-fb7e-4d73-a7ee-7f36757137c8 File: └─/EFI/Boot/bootx64.efi Boot Loader Binaries: ESP: /dev/disk/by-partuuid/e41cc9a5-fb7e-4d73-a7ee-7f36757137c8 File: └─/EFI/systemd/systemd-bootx64.efi (systemd-boot 231) File: └─/EFI/BOOT/bootX64.efi (systemd-boot 231) Boot Loader Entries in EFI Variables: Title: Linux Boot Manager ID: 0x0002 Status: active, boot-order Partition: /dev/disk/by-partuuid/e41cc9a5-fb7e-4d73-a7ee-7f36757137c8 File: └─/EFI/GUMMIBOOT/GUMMIBOOTX64.EFI Title: Linux Boot Manager ID: 0x0005 Status: active, boot-order Partition: /dev/disk/by-partuuid/e41cc9a5-fb7e-4d73-a7ee-7f36757137c8 File: └─/EFI/SYSTEMD/SYSTEMD-BOOTX64.EFI Title: UEFI OS ID: 0x0007 Status: active, boot-order Partition: /dev/disk/by-partuuid/e41cc9a5-fb7e-4d73-a7ee-7f36757137c8 File: └─/EFI/BOOT/BOOTX64.EFI This makes identifying them a matter of informed guesswork. Mike, if you intend to keep a version of gummiboot around, it might be helpful if it used a different entry title. > Also, you should be able to configure your firmware to load either > gummiboot or systemd-boot, so you have a fallback if the new code > fails. It does appear to have worked so far, though I can't be sure which loader I started since they both showed the same list of gummiboot loader entries. I think. Another question is where the directory /usr/lib64/systemd/boot/efi came from, which bootctl reads from to get its binaries for efivars. My next step is to create a new partition layout and populate it from backups, apart from /boot/EFI and /boot/loader, and omitting gummiboot. -- Rgds Peter
Re: [gentoo-user] UEFI booting
On Saturday 27 Aug 2016 10:19:48 Peter Humphrey wrote: > On Friday 26 Aug 2016 12:33:47 Mick wrote: > > On Friday 26 Aug 2016 09:32:25 Peter Humphrey wrote: > > > In my search for a suitable boot method, I'm trying Mike G's > > > systemd-boot ebuild. I've installed it with no problem, and now I reach > > > the heart-in-mouth stage of actually replacing gummiboot with it. But > > > first, the backup, including dd of what used to be called the MBR (what > > > is it now?). > > > > > > # parted -l > > > Model: Unknown (unknown) > > > Disk /dev/nvme0n1: 256GB > > > Sector size (logical/physical): 512B/512B > > > Partition Table: gpt > > > Disk Flags: > > > > > > Number Start End SizeFile system Name Flags > > > > > > 1 1049kB 3146kB 2097kB uefi bios_grub > > > 2 3146kB 144MB 141MB fat32 boot boot, esp > > > 3 144MB 4504MB 4360MB linux-swap(v1) swap > > > 4 4504MB 15.0GB 10.5GB ext4rescuesys > > > 5 15.0GB 32.2GB 17.2GB ext4gentoo > > > 6 32.2GB 36.5GB 4295MB ext4var > > > 7 36.5GB 45.1GB 8590MB ext4home > > > > > > [...] > > > > > > That start block of the uefi partition looks odd to me. > > > > The 'Name' of the 1st partition is the label you have provided when you > > created it. It is NOT the type of the partition, which is shown under the > > 'Flags' column as 'bios_grub'. > > Yes, I know that of course. I called the first partition "uefi" because > that's what the wiki used, and nothing more suitable suggested itself. > > > The 1st partition was created to accommodate Grub's boot code. > > Now that I didn't know. Well, I was hazy about it anyway. > > > It starts on the first cylinder (change the units in parted to cyl and > > you'll see it starts at '0 cyl') and has no fs on it. > > Indeed, except that parted doesn't want to use cylinders in its list output. Run parted: parted /dev/sda then set the units e.g. to "MiB", or sectors "s", or cylinders "cyl": (parted) unit MiB (parted) p to see the result. Then q to quit without changing the table. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] UEFI booting
On Friday 26 Aug 2016 16:13:53 Mike Gilbert wrote: > On Fri, Aug 26, 2016 at 4:32 AM, Peter Humphrey wrote: > > In my search for a suitable boot method, I'm trying Mike G's > > systemd-boot > > ebuild. I've installed it with no problem, and now I reach the heart-in- > > mouth stage of actually replacing gummiboot with it. But first, the > > backup, including dd of what used to be called the MBR (what is it > > now?). > It should be basically a drop-in replacement, with a slightly > different name. It should not require any modification to your disk > layout. No, just the risk of failing to boot. (I'm not paranoid - they really are out to get me!) > Also, you should be able to configure your firmware to load either > gummiboot or systemd-boot, so you have a fallback if the new code > fails. Ah, so I can have both at the same time for testing. That makes me feel less nervous. :) -- Rgds Peter
Re: [gentoo-user] UEFI booting
On Friday 26 Aug 2016 12:33:47 Mick wrote: > On Friday 26 Aug 2016 09:32:25 Peter Humphrey wrote: > > In my search for a suitable boot method, I'm trying Mike G's > > systemd-boot ebuild. I've installed it with no problem, and now I reach > > the heart-in-mouth stage of actually replacing gummiboot with it. But > > first, the backup, including dd of what used to be called the MBR (what > > is it now?). > > > > # parted -l > > Model: Unknown (unknown) > > Disk /dev/nvme0n1: 256GB > > Sector size (logical/physical): 512B/512B > > Partition Table: gpt > > Disk Flags: > > > > Number Start End SizeFile system Name Flags > > > > 1 1049kB 3146kB 2097kB uefi bios_grub > > 2 3146kB 144MB 141MB fat32 boot boot, esp > > 3 144MB 4504MB 4360MB linux-swap(v1) swap > > 4 4504MB 15.0GB 10.5GB ext4rescuesys > > 5 15.0GB 32.2GB 17.2GB ext4gentoo > > 6 32.2GB 36.5GB 4295MB ext4var > > 7 36.5GB 45.1GB 8590MB ext4home > > > > [...] > > > > That start block of the uefi partition looks odd to me. > > The 'Name' of the 1st partition is the label you have provided when you > created it. It is NOT the type of the partition, which is shown under the > 'Flags' column as 'bios_grub'. Yes, I know that of course. I called the first partition "uefi" because that's what the wiki used, and nothing more suitable suggested itself. > The 1st partition was created to accommodate Grub's boot code. Now that I didn't know. Well, I was hazy about it anyway. > It starts on the first cylinder (change the units in parted to cyl and > you'll see it starts at '0 cyl') and has no fs on it. Indeed, except that parted doesn't want to use cylinders in its list output. > > I'm pretty sure I didn't specify a start position to parted when I was > > constructing the partition layout six months ago, preferring to let the > > program choose a value itself. > > Parted and friends will create this partition for Grub at the very start > of the disk, when you use GPT. Quite so. > > I do remember, though, that parted had a strange idea of what > > 2MB meant: it's turned out to be 2097kB. > > You are mixing decimal and binary. 2MiB = 2 x 1024^2 = 2,097,152 Well, it isn't me who's mixing them, but parted. I was operating in MiB throughout, as far as I could tell. > > My question for the panel is whether I need to do anything about that > > partition layout. What do you think? > > You don't have to do something about it, if you want to retain the ability > to use Grub. If you will no longer use grub then you probably do not > need the first grub-specific partition. I hope I never have to look at grub-2 again. All the same, 2MiB is a small enough price to pay for flexibility. > As shown above the second partition is your EFI partition. 141MB may not > be enough to store many kernel images, but it depends on how many kernel > images and initramfs you keep in there at any time. I expect to hold two or three kernels in the boot partition: the latest, a recent known-working one and perhaps a long-term one. I haven't needed an initramfs yet. -- Rgds Peter
Re: [gentoo-user] UEFI booting
On Fri, Aug 26, 2016 at 4:32 AM, Peter Humphrey wrote: > In my search for a suitable boot method, I'm trying Mike G's systemd-boot > ebuild. I've installed it with no problem, and now I reach the heart-in- > mouth stage of actually replacing gummiboot with it. But first, the backup, > including dd of what used to be called the MBR (what is it now?). It should be basically a drop-in replacement, with a slightly different name. It should not require any modification to your disk layout. Also, you should be able to configure your firmware to load either gummiboot or systemd-boot, so you have a fallback if the new code fails.
Re: [gentoo-user] UEFI booting
On Fri, 26 Aug 2016 12:33:47 +0100, Mick wrote: > You don't have to do something about it, if you want to retain the > ability to use Grub. If you will no longer use grub then you probably > do not need the first grub-specific partition. You don't need to anyway. You only need that partition when using GPT on a non-UEFI system. GRUB will boot from the UEFI ESP quite happily, although not on Peter's system for some reason. This is how I have partitioned my NVMe drive for UEFI booting (using bootctl, which is the same as systemd-boot) GPT fdisk (gdisk) version 1.0.1 Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. Disk /dev/nvme0n1: 250069680 sectors, 119.2 GiB Logical sector size: 512 bytes Disk identifier (GUID): 0EB51C66--494C-80F3-9ACB1D95325D Partition table holds up to 128 entries First usable sector is 34, last usable sector is 250069646 Partitions will be aligned on 2048-sector boundaries Total free space is 2014 sectors (1007.0 KiB) Number Start (sector)End (sector) Size Code Name 12048 2099199 1024.0 MiB EF00 boot 2 209920018876415 8.0 GiB 8200 swap 318876416 250069646 110.2 GiB 8300 root -- Neil Bothwick Never ask a geek why, just nod your head and slowly back away pgpWTKnEPhaVh.pgp Description: OpenPGP digital signature
Re: [gentoo-user] UEFI booting
On Friday 26 Aug 2016 09:32:25 Peter Humphrey wrote: > Hello list, > > In my search for a suitable boot method, I'm trying Mike G's systemd-boot > ebuild. I've installed it with no problem, and now I reach the heart-in- > mouth stage of actually replacing gummiboot with it. But first, the backup, > including dd of what used to be called the MBR (what is it now?). > > # parted -l > Model: Unknown (unknown) > Disk /dev/nvme0n1: 256GB > Sector size (logical/physical): 512B/512B > Partition Table: gpt > Disk Flags: > > Number Start End SizeFile system Name Flags > 1 1049kB 3146kB 2097kB uefi bios_grub > 2 3146kB 144MB 141MB fat32 boot boot, esp > 3 144MB 4504MB 4360MB linux-swap(v1) swap > 4 4504MB 15.0GB 10.5GB ext4rescuesys > 5 15.0GB 32.2GB 17.2GB ext4gentoo > 6 32.2GB 36.5GB 4295MB ext4var > 7 36.5GB 45.1GB 8590MB ext4home > [...] > > That start block of the uefi partition looks odd to me. The 'Name' of the 1st partition is the label you have provided when you created it. It is NOT the type of the partition, which is shown under the 'Flags' column as 'bios_grub'. The 1st partition was created to accommodate Grub's boot code. It starts on the first cylinder (change the units in parted to cyl and you'll see it starts at '0 cyl') and has no fs on it. > I'm pretty sure I > didn't specify a start position to parted when I was constructing the > partition layout six months ago, preferring to let the program choose a > value itself. Parted and friends will create this partition for Grub at the very start of the disk, when you use GPT. If you stay with a conventional msdos partition table, then the first partition starts at cylinder 63 allowing enough space for MBR to store its boot code in the unallocated cylinders 0 to 62. > I do remember, though, that parted had a strange idea of what > 2MB meant: it's turned out to be 2097kB. You are mixing decimal and binary. 2MiB = 2 x 1024^2 = 2,097,152 > My question for the panel is whether I need to do anything about that > partition layout. What do you think? You don't have to do something about it, if you want to retain the ability to use Grub. If you will no longer use grub then you probably do not need the first grub-specific partition. As shown above the second partition is your EFI partition. 141MB may not be enough to store many kernel images, but it depends on how many kernel images and initramfs you keep in there at any time. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] UEFI booting [solved]
On 08/17/2015 11:37 PM, Jeremi Piotrowski wrote: On Mon, 17 Aug 2015, Rod wrote: Hi list, Hi I'm trying to figure out how to make my boot partition to boot from UEFI, I have grub2 installed, but I keep getting a error when I ask it to install the boot information. First things first, are you installing gentoo from an UEFI booted installation media? From what I know the gentoo minimal install cd does not allow for this, and I will assume you are using that. If you're using some other installation method, check whether the directory /sys/firmware/efi/efivars has any content, try to mount efivarfs following the instructions in this link: https://wiki.gentoo.org/wiki/Efibootmgr#Configuration and then check again. # efibootmgr efibootmgr: EFI variables are not supported on this system. # grub2-install --target=x86_64-efi /dev/sdc Installing for x86_64-efi platform. efibootmgr: EFI variables are not supported on this system. efibootmgr: EFI variables are not supported on this system. Installation finished. No error reported. In your case it seems that the system is not in an UEFI-booted state. But we can work around this by using a nice part of the UEFI specification, details below. mount /dev/sdc1 201633156 201478 1% /boot/efi I have the /boot/efi part mounted ok.. Before we go further make sure that the partition is a valid EFI boot partition: code EF00 (gdisk), partition flags boot/esp (for parted). How can I get this UEFI be become bootable without media to make it boot in to that mode to begin with ? It's actually much easier than it may seem, and it's outlined here: https://wiki.gentoo.org/wiki/GRUB2#Alternative:_using_the_default_UEFI_firmware_location Basically, for all sorts of removable media there must be a way to tell UEFI what to boot without having to hardcode the entries into NVRAM (like efibootmgr does). Therefore UEFI firmware is supposed to check for the first ESP partition on a drive and boot \EFI\boot\bootx64.efi from it. This also works for harddrives, and since you can access a FAT partition even when booted in bios mode you just put grub there. Now this works perfectly well for a linux kernel with efi stub and cmdline built-in, but grub may have trouble finding it's configuration files, I do not know. So I suggest you try it. Find grubx64.efi in /boot/efi and copy it to /boot/efi/EFI/BOOT/BOOTX64.EFI. Voila, should boot just fine. On my first UEFI install I did not know about this, efibootmgr did not work, but the handbook says to place the kernel at /EFI/boot/bootx64.efi and it just magically worked. Generally you will find that provided the UEFI implementation of your vendor is not complete shit (lots of them exist) UEFI makes it generally easier to handle booting. One partition and the EFI variables and you can boot anything, no more hidden sectors. Ok, thnks for your help, all was checked out as you said, the boot partition was correct, boot, esp which was a good thing. Just found a slight problem, my .efi program that the system was trying to boot was /boot/efi/EFI/gentoo/grubx64.efi copying the .efi to /boot/efi/EFI/BOOT changed nothing, I filed to notice that the name was incorrect, as installing the UEFI with the bootloader (without the efivar loaded) resulted in a file named "grubx86.efi" which doesn't work when copied in to the BOOT directory :( Renaming this file-> mv grubx86.efi bootx86.efi System now happily boots in UEFI mode, I guess I didn't read "Find grubx64.efi in /boot/efi and copy it to /boot/efi/EFI/BOOT/BOOTX64.EFI" correctly :P during this time, the original sda drive I was using failed (SMART was reporting that I should replace it soon) and I guess it was slightly too soon, but I did have the chance to rsync the filesystem across :P Thanks heaps for your help :) -- --- Regards, Rod Smart 0417 513 286
Re: [gentoo-user] UEFI booting
2015-08-17 20:59 GMT+08:00 Rod : > Hi list, > > I'm trying to figure out how to make my boot partition to boot from > UEFI, I have grub2 installed, but I keep getting a error when I ask it to > install the boot information. > > mount > /dev/sdc1 201633156 201478 1% /boot/efi > > I have the /boot/efi part mounted ok.. > > # efibootmgr > efibootmgr: EFI variables are not supported on this system. > > > # grub2-install --target=x86_64-efi /dev/sdc > Installing for x86_64-efi platform. > efibootmgr: EFI variables are not supported on this system. > efibootmgr: EFI variables are not supported on this system. > Installation finished. No error reported. > > I have this disk as my 1st boot drive in BIOS, the 2nd is the normal > drive. > > Boot order is EFI then Legacy (EFI only tells me "Insert boot disk and > hit Enter) > if you see "Insert boot disk and hit Enter" then you are not using EFI mode. it is printed by MS DOS bootloader, aka , the MBR. > > I'm assuming the "variables not supported" is blocking the install. > > > BIOS reports the 1st disk to boot is > > EFI: ST2000DM001-1ER1 > > > Mobo is a Gigabyte Z68X-UD3H-B3 (with the latest UEFI firmware) > > How can I get this UEFI be become bootable without media to make it boot > in to that mode to begin with ? > > -- > --- > > Regards, > Rod Smart > 0417 513 286 > >
Re: [gentoo-user] UEFI booting
On Mon, 17 Aug 2015, Rod wrote: > Hi list, Hi > I'm trying to figure out how to make my boot partition to boot from UEFI, > I have grub2 installed, but I keep getting a error when I ask it to install > the boot information. First things first, are you installing gentoo from an UEFI booted installation media? From what I know the gentoo minimal install cd does not allow for this, and I will assume you are using that. If you're using some other installation method, check whether the directory /sys/firmware/efi/efivars has any content, try to mount efivarfs following the instructions in this link: https://wiki.gentoo.org/wiki/Efibootmgr#Configuration and then check again. > # efibootmgr > efibootmgr: EFI variables are not supported on this system. > > > # grub2-install --target=x86_64-efi /dev/sdc > Installing for x86_64-efi platform. > efibootmgr: EFI variables are not supported on this system. > efibootmgr: EFI variables are not supported on this system. > Installation finished. No error reported. In your case it seems that the system is not in an UEFI-booted state. But we can work around this by using a nice part of the UEFI specification, details below. > mount > /dev/sdc1 201633156 201478 1% /boot/efi > > I have the /boot/efi part mounted ok.. Before we go further make sure that the partition is a valid EFI boot partition: code EF00 (gdisk), partition flags boot/esp (for parted). > How can I get this UEFI be become bootable without media to make it boot > in to that mode to begin with ? It's actually much easier than it may seem, and it's outlined here: https://wiki.gentoo.org/wiki/GRUB2#Alternative:_using_the_default_UEFI_firmware_location Basically, for all sorts of removable media there must be a way to tell UEFI what to boot without having to hardcode the entries into NVRAM (like efibootmgr does). Therefore UEFI firmware is supposed to check for the first ESP partition on a drive and boot \EFI\boot\bootx64.efi from it. This also works for harddrives, and since you can access a FAT partition even when booted in bios mode you just put grub there. Now this works perfectly well for a linux kernel with efi stub and cmdline built-in, but grub may have trouble finding it's configuration files, I do not know. So I suggest you try it. Find grubx64.efi in /boot/efi and copy it to /boot/efi/EFI/BOOT/BOOTX64.EFI. Voila, should boot just fine. On my first UEFI install I did not know about this, efibootmgr did not work, but the handbook says to place the kernel at /EFI/boot/bootx64.efi and it just magically worked. Generally you will find that provided the UEFI implementation of your vendor is not complete shit (lots of them exist) UEFI makes it generally easier to handle booting. One partition and the EFI variables and you can boot anything, no more hidden sectors.
Re: [gentoo-user] UEFI booting
On Mon, Aug 17, 2015 at 10:59:30PM +1000, Rod wrote: > Hi list, > > # efibootmgr > efibootmgr: EFI variables are not supported on this system. > > > # grub2-install --target=x86_64-efi /dev/sdc > Installing for x86_64-efi platform. > efibootmgr: EFI variables are not supported on this system. > efibootmgr: EFI variables are not supported on this system. > Installation finished. No error reported. > I haven't done a UEFI install in a while, but the first thing that comes to mind is that you haven't booted your install medium in UEFI mode. What install media are you using and how did you boot it? Alec