Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
On Mon, May 6, 2019 at 1:16 PM Lev Serebryakov wrote: > On 01.05.2019 0:15, Warner Losh wrote: > > > I think all the features are there. You can install loader.efi as you > > used to install boot1.efi and have it work as well or better than > boot1.efi. > Thank you! > > > > > > But then again, if you are using stock (generic) OS on embedded > > system, you are already doing it wrong and will get into the trouble > > sooner or later:) > > I can not say, is NanoBSD "stock" or not :-) > > > > > > One of the big reasons I did the latest changes was to make it possible > > for NanoBSD to work better. > Could you please look at, which helps NanoBSD to work better with > strange/broken hardware? > > https://reviews.freebsd.org/D17102 > https://reviews.freebsd.org/D17103 Done. commented on the review. (I don't know do we need this for UEFI loader, though). > UEFI is weird, wrt resets and such. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
On 01.05.2019 0:15, Warner Losh wrote: > I think all the features are there. You can install loader.efi as you > used to install boot1.efi and have it work as well or better than boot1.efi. Thank you! > > > But then again, if you are using stock (generic) OS on embedded > system, you are already doing it wrong and will get into the trouble > sooner or later:) > I can not say, is NanoBSD "stock" or not :-) > > > One of the big reasons I did the latest changes was to make it possible > for NanoBSD to work better. Could you please look at, which helps NanoBSD to work better with strange/broken hardware? https://reviews.freebsd.org/D17102 https://reviews.freebsd.org/D17103 (I don't know do we need this for UEFI loader, though). -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
On Mon, Jan 21, 2019 at 6:13 AM Lev Serebryakov wrote: > On 21.01.2019 15:59, Toomas Soome wrote: > > > Is too complicated? Boot1.efi doesn't allow that, but loader.efi > does. > loader.efi lives on ESP partition, do I understand it right? So, it > could not be damaged with "bad" upgrade? > >>> > >>> It could, unless the backup is created. > >> Does it live on code (root) FS or ESP? I understand, that when you > >> upgrade ESP partition, you could ruin it, but typically root FS is > >> upgraded much more often than ESP/boot0/boot1 parts. > > > > If you are using boot1.efi, the loader.efi is in OS /boot/loader.efi > annd boot1.efi is stored to ESP and will execute loader.efi as bios boot2 > programs do. > So, Warner's advice to use > > set currdev=diskXpY: > boot > > with loader.efi is not direct replacement to choosing boot partition > via boot0 now (as "boot1.eif doesn't allow that" and /boot/loader.efi > could be broken with unsuccessful upgrade), am I right? > Yes. And after my latest fixes, you can add 'set currdev=diskXpY' to ESP's /efi/freebsd/loader.env as well. boot1.efi is really super limited and tries too much DWIM to be useful, so it's being retired in favor of loader.efi. > > we will drop boot1.efi (it is already dropped in illumos btw), and will > only use loader.efi - and in this case, the loader.efi is installed to ESP > and will only start the kernel. > Ok, I need to wait for it. > I think all the features are there. You can install loader.efi as you used to install boot1.efi and have it work as well or better than boot1.efi. > > But then again, if you are using stock (generic) OS on embedded system, > you are already doing it wrong and will get into the trouble sooner or > later:) > I can not say, is NanoBSD "stock" or not :-) > One of the big reasons I did the latest changes was to make it possible for NanoBSD to work better. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
On Fri, 2019-01-18 at 21:24 +0300, Lev Serebryakov wrote: > On 18.01.2019 21:14, Toomas Soome wrote: > > > errm.. you press a key and enter device and or loader path. if it is not > > working - the code is there to be fixed. > > And loader looks to "bootme" attribute and try to boot from partition > which has one, even if it is loaded from other partition itself. > I am catching up, very late, on this old thread. What Toomas was describing does work, but it was broken for a long time. It got fixed in r341071 last November. I hate the syntax, but at the gptboot boot prompt (boot:) you can enter "da(D,P)" and gptboot will run loader(8) from that drive number D, partition number P, and (after r341071) it will pass that info properly so that loader(8) will attempt to load the kernel from the same drive/partition. IMO, it would be nice if "currdev syntax" worked too, so you could just enter disk3p4 or similar. I may look into adding that to the code. -- Ian > > GPT does not have the concept of active partition. > > It has "bootme" / "bootonce" attributes. And [zfs]gptboot doesn't have > any tools to set these attributes, AFAIK. Same for UEFI boot code. > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
On 21.01.2019 15:59, Toomas Soome wrote: > Is too complicated? Boot1.efi doesn't allow that, but loader.efi does. loader.efi lives on ESP partition, do I understand it right? So, it could not be damaged with "bad" upgrade? >>> >>> It could, unless the backup is created. >> Does it live on code (root) FS or ESP? I understand, that when you >> upgrade ESP partition, you could ruin it, but typically root FS is >> upgraded much more often than ESP/boot0/boot1 parts. > > If you are using boot1.efi, the loader.efi is in OS /boot/loader.efi annd > boot1.efi is stored to ESP and will execute loader.efi as bios boot2 programs > do. So, Warner's advice to use set currdev=diskXpY: boot with loader.efi is not direct replacement to choosing boot partition via boot0 now (as "boot1.eif doesn't allow that" and /boot/loader.efi could be broken with unsuccessful upgrade), am I right? > we will drop boot1.efi (it is already dropped in illumos btw), and will only > use loader.efi - and in this case, the loader.efi is installed to ESP and > will only start the kernel. Ok, I need to wait for it. > But then again, if you are using stock (generic) OS on embedded system, you > are already doing it wrong and will get into the trouble sooner or later:) I can not say, is NanoBSD "stock" or not :-) -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
> On 21 Jan 2019, at 14:45, Lev Serebryakov wrote: > > On 21.01.2019 15:39, Toomas Soome wrote: > Is too complicated? Boot1.efi doesn't allow that, but loader.efi does. >>> loader.efi lives on ESP partition, do I understand it right? So, it >>> could not be damaged with "bad" upgrade? >> >> It could, unless the backup is created. > Does it live on code (root) FS or ESP? I understand, that when you > upgrade ESP partition, you could ruin it, but typically root FS is > upgraded much more often than ESP/boot0/boot1 parts. > > -- > // Lev Serebryakov > If you are using boot1.efi, the loader.efi is in OS /boot/loader.efi annd boot1.efi is stored to ESP and will execute loader.efi as bios boot2 programs do. As UEFI does not *replace* the program which did call StartImage() but both do stay in memory (so you have both boot1.efi and loader.efi in memory), and boot1.efi does not add any significant features, we will drop boot1.efi (it is already dropped in illumos btw), and will only use loader.efi - and in this case, the loader.efi is installed to ESP and will only start the kernel. This also does mean that in ideal world, the update should create backup of boot program in ESP (this actually also does apply to boot1.efi), but the default ESP created by FreeBSD used to be too small for that. With normal systems it should not be an issue because you can always boot from usb stick/cd (image), but with embedded systems it may be significant issue. But then again, if you are using stock (generic) OS on embedded system, you are already doing it wrong and will get into the trouble sooner or later:) rgds, toomas ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
On 21.01.2019 15:39, Toomas Soome wrote: >>> Is too complicated? Boot1.efi doesn't allow that, but loader.efi does. >> loader.efi lives on ESP partition, do I understand it right? So, it >> could not be damaged with "bad" upgrade? > > It could, unless the backup is created. Does it live on code (root) FS or ESP? I understand, that when you upgrade ESP partition, you could ruin it, but typically root FS is upgraded much more often than ESP/boot0/boot1 parts. -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
> On 21 Jan 2019, at 14:15, Lev Serebryakov wrote: > > On 20.01.2019 20:05, Warner Losh wrote: > >> Is too complicated? Boot1.efi doesn't allow that, but loader.efi does. > loader.efi lives on ESP partition, do I understand it right? So, it > could not be damaged with "bad" upgrade? > > -- > // Lev Serebryakov > It could, unless the backup is created. rgds, toomas ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
On 20.01.2019 20:05, Warner Losh wrote: > Is too complicated? Boot1.efi doesn't allow that, but loader.efi does. loader.efi lives on ESP partition, do I understand it right? So, it could not be damaged with "bad" upgrade? -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
On Sun, Jan 20, 2019, 9:29 AM Lev Serebryakov Hello Rebecca,
>
> Sunday, January 20, 2019, 7:27:56 AM, you wrote:
>
> > Ultimately, UEFI doesn't care about disks and partitions: it only really
> knows
> > about ESPs -- FAT12/16/32 formatted partitions that contain the EFI
> directory
> > structure. For now, that means /EFI/BOOT/BOOT{x64,i386,aa64,arm}.efi,
> the
> > Microsoft boot loader in /EFI/Microsoft and GRUB/shim in /EFI/fedora,
> /EFI/
> > opensuse etc.
> Problem is (for me), our code we put in ESP partition doesn't care about
> several FreeBSD partitions and ability to continue boot from any of them in
> simple way.
set currdev=diskXpY:
boot
Is too complicated? Boot1.efi doesn't allow that, but loader.efi does.
I have been said, that code in ESP partition looks and some EFI
> variables (BootNext & Co), and I could "Set them in BIOS", but all this
> thread doesn't have any clues HOW could I set them in BIOS. Need I EFI
> shell
> (which, according to this message must be installed separately!), or
> something?
>
The EFI shell let's you select which .efi to run in a generic way. Most
BIOSes have the ability to boot to this. There are multiple ways to do
this. There are other things that could also be done, true, and it would be
cool if we had it in the menu...
So many things you'd want to be able to do you can. There are gaps we can
fill in, but booting the FreeBSD on a different partition is easy today
from the loader prompt...
And I repeat for 4th or 5th time: subject is about GPT. GPT/Legacy has same
> problem :-)
>
I don't care about that as much :). Others might, and I'd integrate
reasonable changes here. I care a lot UEFI, and have put a ton of work into
making it more than the most minimal thing to boot.
Warner
--
> Best regards,
> Levmailto:l...@freebsd.org
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
Hello Rebecca,
Sunday, January 20, 2019, 7:27:56 AM, you wrote:
> Ultimately, UEFI doesn't care about disks and partitions: it only really knows
> about ESPs -- FAT12/16/32 formatted partitions that contain the EFI directory
> structure. For now, that means /EFI/BOOT/BOOT{x64,i386,aa64,arm}.efi, the
> Microsoft boot loader in /EFI/Microsoft and GRUB/shim in /EFI/fedora, /EFI/
> opensuse etc.
Problem is (for me), our code we put in ESP partition doesn't care about
several FreeBSD partitions and ability to continue boot from any of them in
simple way. I have been said, that code in ESP partition looks and some EFI
variables (BootNext & Co), and I could "Set them in BIOS", but all this
thread doesn't have any clues HOW could I set them in BIOS. Need I EFI shell
(which, according to this message must be installed separately!), or something?
And I repeat for 4th or 5th time: subject is about GPT. GPT/Legacy has same
problem :-)
--
Best regards,
Levmailto:l...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
On Sat, Jan 19, 2019 at 11:54:25PM +0300, Lev Serebryakov wrote: > Hello Rebecca, > > Saturday, January 19, 2019, 6:06:52 PM, you wrote: > > > Ok, I've checked my desktop Asus Z170-A, but it is graphical and I could > > not find or understand anything in this home-rown UI with crazy-fast mouse. > > On ASUS systems you normally press F8 during POST to bring up the boot > > menu, and F11 on Supermicro systems. > Yes, I know. But what should I do next? There is no "Set UEFI Boot Var" > item in it. You could select different physical drives (but not partitions > of the drives) and network cards (if PXE is enabled), and, sometimes, "EFI > Shell" which is not documented anywhere, and it doesn't work always. > > When I google "ASUS EFI Shell", for example, all results says about > preparing USB stick with EFI shell and such, not about commands and > variables of EFI shell. > > I don't say, that it is impossible, I only could not find good (or any) > documentation. The specification for EFI Shell is available together with other UEFI specifications, at http://www.uefi.org/specifications. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
On Saturday, 19 January 2019 13:54:25 MST Lev Serebryakov wrote:
> Yes, I know. But what should I do next? There is no "Set UEFI Boot Var"
> item in it. You could select different physical drives (but not partitions
> of the drives) and network cards (if PXE is enabled), and, sometimes, "EFI
> Shell" which is not documented anywhere, and it doesn't work always.
>
> When I google "ASUS EFI Shell", for example, all results says about
> preparing USB stick with EFI shell and such, not about commands and
> variables of EFI shell.
>
> I don't say, that it is impossible, I only could not find good (or any)
> documentation.
Yeah, the documentation is definitely lacking.
If you want to specifically run the EFI Shell, then you'll need to either
install Shell_Full.efi from https://github.com/tianocore/edk2/tree/UDK2014.SP1/
EdkShellBinPkg/FullShell/X64 as Shellx64.efi on a USB stick formatted as FAT16
or FAT32 - or, install the shell as EFI/BOOT/BOOTx64.efi on an ESP.
For booting FreeBSD, you might want to consider installing rEFInd (http://
www.rodsbooks.com/refind/), since it can find the loader in EFI/freebsd/
loader.efi and displays the FreeBSD logo - see https://bluestop.org/files/
rEFInd_FreeBSD.jpeg . For comparison, my ASUS UEFI firmware doesn't find
FreeBSD
at all in /EFI/freebsd, and when installed as /EFI/boot/BOOTx64.efi just
displays a "UEFI OS" entry.
Ultimately, UEFI doesn't care about disks and partitions: it only really knows
about ESPs -- FAT12/16/32 formatted partitions that contain the EFI directory
structure. For now, that means /EFI/BOOT/BOOT{x64,i386,aa64,arm}.efi, the
Microsoft boot loader in /EFI/Microsoft and GRUB/shim in /EFI/fedora, /EFI/
opensuse etc.
--
Rebecca Cran
signature.asc
Description: This is a digitally signed message part.
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
Hello Rebecca, Saturday, January 19, 2019, 6:06:52 PM, you wrote: > Ok, I've checked my desktop Asus Z170-A, but it is graphical and I could > not find or understand anything in this home-rown UI with crazy-fast mouse. > On ASUS systems you normally press F8 during POST to bring up the boot menu, > and F11 on Supermicro systems. Yes, I know. But what should I do next? There is no "Set UEFI Boot Var" item in it. You could select different physical drives (but not partitions of the drives) and network cards (if PXE is enabled), and, sometimes, "EFI Shell" which is not documented anywhere, and it doesn't work always. When I google "ASUS EFI Shell", for example, all results says about preparing USB stick with EFI shell and such, not about commands and variables of EFI shell. I don't say, that it is impossible, I only could not find good (or any) documentation. -- Best regards, Levmailto:l...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
On Sat, Jan 19, 2019 at 9:32 AM Rodney W. Grimes < freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: > > On Sat, Jan 19, 2019 at 9:00 AM Rodney W. Grimes < > > freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: > > > > > > > > > > On January 19, 2019 at 2:52:28 AM, Lev Serebryakov (l...@freebsd.org > > > (mailto:l...@freebsd.org)) wrote: > > > > > > > > > I have never seen such item in BIOS Setup. I've checked two MoBos > now > > > (one is > > > > > Supermicro X9something and other is brand-new Goldmont-based > Chinese > > > MiniPC > > > > > like Intel NUK): both have one knob in setup about boot type > > > > > (Legacy/UEFI/Auto) and if UEFI is selected, Supermicro MoBo (but > not > > > Chinese > > > > > one) could be booted to "UEFI Console" which is not documented > > > anywhere. > > > > > > > > > > Ok, I've checked my desktop Asus Z170-A, but it is graphical and I > > > could > > > > > not find or understand anything in this home-rown UI with > crazy-fast > > > mouse. > > > > > > > > > > > > > On ASUS systems you normally press F8 during POST to bring up the > boot > > > menu, and F11 on Supermicro systems. > > > > > > ASUS should learn to put that stuff on screen... like everyone else. > > > I've been hitting the delete and going to the bios/boot tap which > > > also has a boot selection screen on one of my machines because I > > > did not know F8 existed. > > > > > > > I've been generally reluctant to add old-style boot0 selection to UEFI > > stuff. The BIOS already does it, so we don't need to. I've not needed it > at > > all. > > The BIOS does NOT do what our boot0 does, I have seen no BIOS that > well allow me to select a partition on a drive, you can only select > the drive. > True, but you need more than knowing which partition to boot from with UEFI. Sadly, it's no longer that simple for multiple partition setups. UEFI knows how to boot the primary loader (our boot1.efi or loader.efi), but from there there's no standard way to tell how to select from multiple different notions. I've created a standard for FreeBSD (which is what each OS is supposed to do), but making it happen is tricky as you somehow have to know which of several options you want to use. There's several ways to do this in FreeBSD, but they aren't super easy (if you get to the loader prompt, you can set anything to boot there). > I think this is the feature that Lev is missing, and I am sure > others shall miss it to. > > IIRC whistle used a version of this so you could install a new system > to partion 2, keeping your current system in partion 1, and changing the > active back and forth. If we have lost that basic functionality with > the growth of GPT and UEFI that is a sad day. > If you set it up properly, that's trivial to do. We do it all the time at Netflix. Most of the changes I made to loader.efi was to make this possible, regular and easy. > However, we start the boot in lua. We already allow an interruption of > > loader.efi, so it would be super easy (assuming we got the lua bindings > > right) to implement something that would show you all the Boot envs > and > > let you select one to boot instead. We already have the ability to > > interupt the boot loader. It would also be trivial to implement a > 'efiboot > > ' command to give that to you in cli mode. Both would set BootNext to > > and exit. We already have a menu, we could just add it to that. This > > would solve the hassles people are having with their BIOS (either because > > it's incomplete or hides the functionality too well) and would obviate > the > > need to make boot1.efi do the selection (which has issues of its own due > to > > boot1's limited scope). > > Loader and such is far too late... as part of what the boot0 mbr gets you > around is when your loader in the new partition is what is stopping you > from getting booted because it got screwed up. > In UEFI land, this is handled by the UEFI shell or the BIOS. It's a fundamentally different environment where /boot/loader.efi is not too late. In UEFI your primary loader lives on the ESP and is responsible for getting the rest of the OS running. If you just want to boot FreeBSD, it's plenty sophisticated to boot any bootable FreeBSD partition by setting currdev to the right value and reloading the kernel. If you want to boot another OS, however, you'll need to slot into the standard UEFI stuff, which is setting up a boot variable and telling UEFI to use it instead of what you just booted (which is what we can't do today: we can't set BootNext and then exit the boot loader). All the functionality that used to be in mbr has moved into the BIOS. The bootstrap has gone from "read this one block from location 0" to "read this file from this FAT partition and pass it this extra goo". We are an imperfect fit into that now, I won't deny. We're closer to being not a terrible fit than we have been in the past, but we have a ways to go. But to get there, we have to stop thinking MBR-ly and start thinking
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
On 1/19/2019 10:32, Rodney W. Grimes wrote: >> .. > The BIOS does NOT do what our boot0 does, I have seen no BIOS that > well allow me to select a partition on a drive, you can only select > the drive. > > I think this is the feature that Lev is missing, and I am sure > others shall miss it to. > > IIRC whistle used a version of this so you could install a new system > to partion 2, keeping your current system in partion 1, and changing the > active back and forth. If we have lost that basic functionality with > the growth of GPT and UEFI that is a sad day. It is indeed, especially for embedded applications. I really, really like the fact that NanoBSD (on an MBR boot) can have two partitions and mark the "other one" as active; this then lets you update the code "in place" and as long as you are paying attention to what goes into the volatile overlays (specifically although not exclusively don't let /etc/fstab with a hard-coded filesystem reference get into there!) then you can "warm update" a running system and reboot into the new code. If something goes wrong re-marking the old partition active is not terribly hard, so there's a *reasonable* recovery path available. I've not found a reliable way to do that sort of thing with many of the "newer" small-board devices and I really like it on, for example, my apu2 firewall appliances that I and others are using all over the place in that being able to put together a code-fix update is of material value. -- Karl Denninger k...@denninger.net /The Market Ticker/ smime.p7s Description: S/MIME Cryptographic Signature
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
> On 19 Jan 2019, at 11:52, Lev Serebryakov wrote: > > Hello Warner, > > Saturday, January 19, 2019, 12:17:29 AM, you wrote: > >> Also most UEFI BIOSes I've used (which isn't a lot) allow one to choose >> which Boot variable to use to boot. Some will even create new Boot >> variables that they use when you choose a raw device to boot from. > I have never seen such item in BIOS Setup. I've checked two MoBos now (one is > Supermicro X9something and other is brand-new Goldmont-based Chinese MiniPC > like Intel NUK): both have one knob in setup about boot type > (Legacy/UEFI/Auto) and if UEFI is selected, Supermicro MoBo (but not Chinese > one) could be booted to "UEFI Console" which is not documented anywhere. > > Ok, I've checked my desktop Asus Z170-A, but it is graphical and I could > not find or understand anything in this home-rown UI with crazy-fast mouse. > > I have never seen documentation in MoBo manuals about such features, BTW. > > And, again, GPT/Legacy still left behind, and it could be very useful for > small systems, as sometimes 4 partitions of MBR is not enough (2 code > partitions + 1 config partition + 1 persistent data partition, and > SOMETIMES, there is place for swap, for example, but MBR is full already). > you can always create BSD label inside MBR slice. Also you can add chain_disk=devicename: into loader.conf and get same one key selection in boot menu (or Boot Enviroments for that matter). There is no need to struggle with 446 byte asm code when you have full power from your boot loader. rgds, toomas ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
> On Sat, Jan 19, 2019 at 9:00 AM Rodney W. Grimes < > freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: > > > > > > > On January 19, 2019 at 2:52:28 AM, Lev Serebryakov (l...@freebsd.org > > (mailto:l...@freebsd.org)) wrote: > > > > > > > I have never seen such item in BIOS Setup. I've checked two MoBos now > > (one is > > > > Supermicro X9something and other is brand-new Goldmont-based Chinese > > MiniPC > > > > like Intel NUK): both have one knob in setup about boot type > > > > (Legacy/UEFI/Auto) and if UEFI is selected, Supermicro MoBo (but not > > Chinese > > > > one) could be booted to "UEFI Console" which is not documented > > anywhere. > > > > > > > > Ok, I've checked my desktop Asus Z170-A, but it is graphical and I > > could > > > > not find or understand anything in this home-rown UI with crazy-fast > > mouse. > > > > > > > > > > On ASUS systems you normally press F8 during POST to bring up the boot > > menu, and F11 on Supermicro systems. > > > > ASUS should learn to put that stuff on screen... like everyone else. > > I've been hitting the delete and going to the bios/boot tap which > > also has a boot selection screen on one of my machines because I > > did not know F8 existed. > > > > I've been generally reluctant to add old-style boot0 selection to UEFI > stuff. The BIOS already does it, so we don't need to. I've not needed it at > all. The BIOS does NOT do what our boot0 does, I have seen no BIOS that well allow me to select a partition on a drive, you can only select the drive. I think this is the feature that Lev is missing, and I am sure others shall miss it to. IIRC whistle used a version of this so you could install a new system to partion 2, keeping your current system in partion 1, and changing the active back and forth. If we have lost that basic functionality with the growth of GPT and UEFI that is a sad day. > > However, we start the boot in lua. We already allow an interruption of > loader.efi, so it would be super easy (assuming we got the lua bindings > right) to implement something that would show you all the Boot envs and > let you select one to boot instead. We already have the ability to > interrupt the boot loader. It would also be trivial to implement a 'efiboot > ' command to give that to you in cli mode. Both would set BootNext to > and exit. We already have a menu, we could just add it to that. This > would solve the hassles people are having with their BIOS (either because > it's incomplete or hides the functionality too well) and would obviate the > need to make boot1.efi do the selection (which has issues of its own due to > boot1's limited scope). Loader and such is far too late... as part of what the boot0 mbr gets you around is when your loader in the new partition is what is stopping you from getting booted because it got screwed up. > The only drawback here is that we'd not be able to create new boot envs in > the loader, or you'd need to create a new one if you haven't yet run > efibootmgr(8), but if that's really an issue, someone will write code to > cope. > > Warner -- Rod Grimes rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
On Sat, Jan 19, 2019 at 9:00 AM Rodney W. Grimes < freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: > > > > On January 19, 2019 at 2:52:28 AM, Lev Serebryakov (l...@freebsd.org > (mailto:l...@freebsd.org)) wrote: > > > > > I have never seen such item in BIOS Setup. I've checked two MoBos now > (one is > > > Supermicro X9something and other is brand-new Goldmont-based Chinese > MiniPC > > > like Intel NUK): both have one knob in setup about boot type > > > (Legacy/UEFI/Auto) and if UEFI is selected, Supermicro MoBo (but not > Chinese > > > one) could be booted to "UEFI Console" which is not documented > anywhere. > > > > > > Ok, I've checked my desktop Asus Z170-A, but it is graphical and I > could > > > not find or understand anything in this home-rown UI with crazy-fast > mouse. > > > > > > > On ASUS systems you normally press F8 during POST to bring up the boot > menu, and F11 on Supermicro systems. > > ASUS should learn to put that stuff on screen... like everyone else. > I've been hitting the delete and going to the bios/boot tap which > also has a boot selection screen on one of my machines because I > did not know F8 existed. > I've been generally reluctant to add old-style boot0 selection to UEFI stuff. The BIOS already does it, so we don't need to. I've not needed it at all. However, we start the boot in lua. We already allow an interruption of loader.efi, so it would be super easy (assuming we got the lua bindings right) to implement something that would show you all the Boot envs and let you select one to boot instead. We already have the ability to interrupt the boot loader. It would also be trivial to implement a 'efiboot ' command to give that to you in cli mode. Both would set BootNext to and exit. We already have a menu, we could just add it to that. This would solve the hassles people are having with their BIOS (either because it's incomplete or hides the functionality too well) and would obviate the need to make boot1.efi do the selection (which has issues of its own due to boot1's limited scope). The only drawback here is that we'd not be able to create new boot envs in the loader, or you'd need to create a new one if you haven't yet run efibootmgr(8), but if that's really an issue, someone will write code to cope. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
> > On January 19, 2019 at 2:52:28 AM, Lev Serebryakov > (l...@freebsd.org(mailto:l...@freebsd.org)) wrote: > > > I have never seen such item in BIOS Setup. I've checked two MoBos now (one > > is > > Supermicro X9something and other is brand-new Goldmont-based Chinese MiniPC > > like Intel NUK): both have one knob in setup about boot type > > (Legacy/UEFI/Auto) and if UEFI is selected, Supermicro MoBo (but not Chinese > > one) could be booted to "UEFI Console" which is not documented anywhere. > > > > Ok, I've checked my desktop Asus Z170-A, but it is graphical and I could > > not find or understand anything in this home-rown UI with crazy-fast mouse. > > > > On ASUS systems you normally press F8 during POST to bring up the boot menu, > and F11 on Supermicro systems. ASUS should learn to put that stuff on screen... like everyone else. I've been hitting the delete and going to the bios/boot tap which also has a boot selection screen on one of my machines because I did not know F8 existed. Thank you! -- Rod Grimes rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
Hello Tomoaki, Saturday, January 19, 2019, 4:42:21 AM, you wrote: > I should note that 512-bytes boot0 doesn't have that feature. > What had it WAS larger boot0ext, which has already gone on stable/11 > and later. IIRC, sysinstall let me select which to install on MBR. It has, look at src/stand/i386/boot0/boot0.S It works :-) -- Best regards, Levmailto:l...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
On January 19, 2019 at 2:52:28 AM, Lev Serebryakov (l...@freebsd.org(mailto:l...@freebsd.org)) wrote: > I have never seen such item in BIOS Setup. I've checked two MoBos now (one is > Supermicro X9something and other is brand-new Goldmont-based Chinese MiniPC > like Intel NUK): both have one knob in setup about boot type > (Legacy/UEFI/Auto) and if UEFI is selected, Supermicro MoBo (but not Chinese > one) could be booted to "UEFI Console" which is not documented anywhere. > > Ok, I've checked my desktop Asus Z170-A, but it is graphical and I could > not find or understand anything in this home-rown UI with crazy-fast mouse. > On ASUS systems you normally press F8 during POST to bring up the boot menu, and F11 on Supermicro systems. — Rebecca ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
Hello Emmanuel, Saturday, January 19, 2019, 12:10:13 AM, you wrote: > With UEFI Boot* variable you could do : > - Update previous partition and set BootNext to it > - If it fail next boot will be on current partition due to BootOrder > - If it succeed, change the BootOrder to have the new partition first. It will not work with GPT/Legacy, but looks like it is solution for UEFI. Thank you. -- Best regards, Levmailto:l...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
Hello Warner, Saturday, January 19, 2019, 12:17:29 AM, you wrote: > Also most UEFI BIOSes I've used (which isn't a lot) allow one to choose > which Boot variable to use to boot. Some will even create new Boot > variables that they use when you choose a raw device to boot from. I have never seen such item in BIOS Setup. I've checked two MoBos now (one is Supermicro X9something and other is brand-new Goldmont-based Chinese MiniPC like Intel NUK): both have one knob in setup about boot type (Legacy/UEFI/Auto) and if UEFI is selected, Supermicro MoBo (but not Chinese one) could be booted to "UEFI Console" which is not documented anywhere. Ok, I've checked my desktop Asus Z170-A, but it is graphical and I could not find or understand anything in this home-rown UI with crazy-fast mouse. I have never seen documentation in MoBo manuals about such features, BTW. And, again, GPT/Legacy still left behind, and it could be very useful for small systems, as sometimes 4 partitions of MBR is not enough (2 code partitions + 1 config partition + 1 persistent data partition, and SOMETIMES, there is place for swap, for example, but MBR is full already). > But this whole thread tells me we need to rewrite the boot section of our > handbook. Oh, yes, please! -- Best regards, Levmailto:l...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Am Fri, 18 Jan 2019 14:17:29 -0700 Warner Losh schrieb: > On Fri, Jan 18, 2019 at 2:11 PM Emmanuel Vadot > wrote: > > > On Fri, 18 Jan 2019 22:50:31 +0300 > > Lev Serebryakov wrote: > > > > > On 18.01.2019 22:35, Rodney W. Grimes wrote: > > > > > > >>> errm.. you press a key and enter device and or loader path. if it is > > not working - the code is there to be fixed. > > > >> And loader looks to "bootme" attribute and try to boot from partition > > > >> which has one, even if it is loaded from other partition itself. > > > >> > > > >>> GPT does not have the concept of active partition. > > > >> It has "bootme" / "bootonce" attributes. And [zfs]gptboot doesn't > > have > > > >> any tools to set these attributes, AFAIK. Same for UEFI boot code. > > > > > > > > The gpart(8) command is used to set/unset these. > > > gpart need booted system. NanoBSD typically have two "system" > > > partitions, "old" (previous) and "new" (current). After upgrade they > > > switched (new code is written to "previos" partition and bootable > > > atteibute is set to it, "active" in case of MBR and "bootme" in case of > > > GPT). > > > > > > If this new partition has problems and could not be booted, it is hard > > > to boot from "old" (previous) one. MBR + boot0 could (interactively) > > > change active partition before system is booted, and this problem could > > > be solved with one keypress: you select old partition on boot. > > > > > > -- > > > // Lev Serebryakov > > > > > > > With UEFI Boot* variable you could do : > > > > - Update previous partition and set BootNext to it > > - If it fail next boot will be on current partition due to BootOrder > > - If it succeed, change the BootOrder to have the new partition first. > > > > Also most UEFI BIOSes I've used (which isn't a lot) allow one to choose > which Boot variable to use to boot. Some will even create new Boot > variables that they use when you choose a raw device to boot from. > > There's other people that have efi programs that will pop up a menu for you > to select a particular Boot to use. They then set BootNext and exit. > I've not used any of these personally. > > But this whole thread tells me we need to rewrite the boot section of our > handbook. Oh, yes, please, please! Thanks in advance! oh > > Warner > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" - -- O. Hartmann Ich widerspreche der Nutzung oder Übermittlung meiner Daten für Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). -BEGIN PGP SIGNATURE- iHUEARYIAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCXELOUgAKCRA4N1ZZPba5 R7PWAP9zDKuReIghEeO3UNUOPLldsjH0Zr8Ez0DVtaRt0F2WrwD/cWXjOOu5SLD2 NxHq0pKZ5oH0K7NC/4lA45j0Ir9C3wo= =Y3j1 -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: UEFI, loader.efi and /boot.config
On Thursday, 17 January 2019 20:02:46 MST David Wolfskill wrote: > Does the above only apply to UEFI booting, or also to booting from > BIOS/MBR? It's only for UEFI booting. -- Rebecca Cran signature.asc Description: This is a digitally signed message part.
Re: UEFI, loader.efi and /boot.config
On Friday, 18 January 2019 00:48:02 MST Kurt Jaeger wrote: > > With a recent change I made for UEFI, we now install loader.efi onto the > > ESP and don???t run boot1. That means that /boot.config is no longer > > read, and so console settings need to be put in /boot/loader.conf > Which change is that ? The change is https://svnweb.freebsd.org/base?view=revision=342283 . -- Rebecca Cran signature.asc Description: This is a digitally signed message part.
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
On Fri, 18 Jan 2019 22:44:28 +0300 Lev Serebryakov wrote: > On 18.01.2019 22:27, Warner Losh wrote: > > > > errm.. you press a key and enter device and or loader path. if it > > is not working - the code is there to be fixed. > > 〓And loader looks to "bootme" attribute and try to boot from partition > > which has one, even if it is loaded from other partition itself. > > Correct. > And system crashes, because "bootme" partition has broken installation. > > With MBR + boot0/boot0sio it is solved with one keypress. > > > > GPT does not have the concept of active partition. > > 〓It has "bootme" / "bootonce" attributes. And [zfs]gptboot doesn't have > > any tools to set these attributes, AFAIK. Same for UEFI boot code. > > > > gpart can set these. > You need live, booted system (at least single-user) to use gpart. > > > UEFI completely ignores them, though, because getting to that data is > > hard in the UEFI environment. But in UEFI, you're supposed to use > > Boot and BootOrder/BootNext as managed by efibootmgr. > Again, you need booted system to use efibootmgr. > > boot0/boot0sio works before system and could switch boot partition in > case of MBR. It is why I write, that GPT/Legacy and GPT/UEFI miss > important feature which is present for MBR boot for ages. Which is sad & > funny at same time, as GPT/UEFI has much more code than 512 bytes of boot0. > > -- > // Lev Serebryakov > Hi. I should note that 512-bytes boot0 doesn't have that feature. What had it WAS larger boot0ext, which has already gone on stable/11 and later. IIRC, sysinstall let me select which to install on MBR. It could be larger than 512 bytes as no partition could be mapped on 1st cylinder because USUAL partition editors aligns partition by cylinder on ancient CHS days. But IIUC, it was trivial, NOT assured by any spec. So preparing 512-bytes (single sector) boot0 IS mandatory for MBR, while boot0ext is not. One good news is that boot1.efi having boot-time partition selection by Naomichi Nonaka exists on bugzilla.[1] The latest ones includes my quick and ugly hack to get back deleted but needed functions, though. "boot1.c patch rev4 for stable/11 after MFC of r332751" would be applicable to stable/11 (not tested recently), and "boot1.c patch rev4 for stable/12 and head after r332751" would be applicable to stable/12 and head. *I've uploaded long-forgotton ones just before this mail. They should be cleaned-up to use currently-available functions instead of re-adding deleted functions but I have not enough time to do, and Naomichi, the original auther of the patche, already switched to use grub and would not maintain it further. And a bad news is that [1] would never be committed, and non-UEFI GPT-based installation doesn't have any alternatives. [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207940 -- Tomoaki AOKI ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
On Fri, Jan 18, 2019 at 2:11 PM Emmanuel Vadot wrote: > On Fri, 18 Jan 2019 22:50:31 +0300 > Lev Serebryakov wrote: > > > On 18.01.2019 22:35, Rodney W. Grimes wrote: > > > > >>> errm.. you press a key and enter device and or loader path. if it is > not working - the code is there to be fixed. > > >> And loader looks to "bootme" attribute and try to boot from partition > > >> which has one, even if it is loaded from other partition itself. > > >> > > >>> GPT does not have the concept of active partition. > > >> It has "bootme" / "bootonce" attributes. And [zfs]gptboot doesn't > have > > >> any tools to set these attributes, AFAIK. Same for UEFI boot code. > > > > > > The gpart(8) command is used to set/unset these. > > gpart need booted system. NanoBSD typically have two "system" > > partitions, "old" (previous) and "new" (current). After upgrade they > > switched (new code is written to "previos" partition and bootable > > atteibute is set to it, "active" in case of MBR and "bootme" in case of > > GPT). > > > > If this new partition has problems and could not be booted, it is hard > > to boot from "old" (previous) one. MBR + boot0 could (interactively) > > change active partition before system is booted, and this problem could > > be solved with one keypress: you select old partition on boot. > > > > -- > > // Lev Serebryakov > > > > With UEFI Boot* variable you could do : > > - Update previous partition and set BootNext to it > - If it fail next boot will be on current partition due to BootOrder > - If it succeed, change the BootOrder to have the new partition first. > Also most UEFI BIOSes I've used (which isn't a lot) allow one to choose which Boot variable to use to boot. Some will even create new Boot variables that they use when you choose a raw device to boot from. There's other people that have efi programs that will pop up a menu for you to select a particular Boot to use. They then set BootNext and exit. I've not used any of these personally. But this whole thread tells me we need to rewrite the boot section of our handbook. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
On Fri, 18 Jan 2019 22:50:31 +0300 Lev Serebryakov wrote: > On 18.01.2019 22:35, Rodney W. Grimes wrote: > > >>> errm.. you press a key and enter device and or loader path. if it is not > >>> working - the code is there to be fixed. > >> And loader looks to "bootme" attribute and try to boot from partition > >> which has one, even if it is loaded from other partition itself. > >> > >>> GPT does not have the concept of active partition. > >> It has "bootme" / "bootonce" attributes. And [zfs]gptboot doesn't have > >> any tools to set these attributes, AFAIK. Same for UEFI boot code. > > > > The gpart(8) command is used to set/unset these. > gpart need booted system. NanoBSD typically have two "system" > partitions, "old" (previous) and "new" (current). After upgrade they > switched (new code is written to "previos" partition and bootable > atteibute is set to it, "active" in case of MBR and "bootme" in case of > GPT). > > If this new partition has problems and could not be booted, it is hard > to boot from "old" (previous) one. MBR + boot0 could (interactively) > change active partition before system is booted, and this problem could > be solved with one keypress: you select old partition on boot. > > -- > // Lev Serebryakov > With UEFI Boot* variable you could do : - Update previous partition and set BootNext to it - If it fail next boot will be on current partition due to BootOrder - If it succeed, change the BootOrder to have the new partition first. -- Emmanuel Vadot ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
> > On 18 Jan 2019, at 21:33, Rodney W. Grimes
> > wrote:
> >
> >>
> >>
> >>> On 18 Jan 2019, at 19:57, Lev Serebryakov wrote:
> >>>
> >>> On 18.01.2019 20:13, Warner Losh wrote:
> >>>
> > Also, there are same problems with GPT/BIOS setup (which uses GPT but
> > legacy boot) :-(
> >
>
> What same problems? I don't think we've touched how gptboot has handed
> off
> to /boot/loader in a long, long time. It there's an issue here, it's a
> different issue.
> >>> Ok, strictly speaking it is different issue with same "high-level"
> >>> description: pmbr/gptboot has less features than simplest oldest boot0.
> >>>
> >>> pmbr/gptbood doesn't have any way to select partition to boot from, as
> >>> "boot0" has. No, setting "nextboot" from live system is not a solution.
> >>> I speak about NanoBSD situation when there is tow partitions, both
> >>> bootable, one marked as "active" ("bootme" on GPT parlance) but it is
> >>> completely broken and user need to boot from other one form very
> >>> beginning. This task is trivially solved by "boot0" in pure-MBR case.
> >>> What about GPT/Legacy and GPT/UEFI?
> >>>
> >>> --
> >>> // Lev Serebryakov
> >>>
> >>
> >> errm.. you press a key and enter device and or loader path. if it is not
> >> working - the code is there to be fixed.
> >> GPT does not have the concept of active partition.
> >
> > It certainly does, it is called the attribute bootme,
> > and the above correctly states that.
> >
>
> Shall you give the reference to specification?:)
You can bury yourself in that paradigm, but the fact is even the wiki documents
gpt attribute bit 2 as "legacy bootable, equivelant to active flag".
>
> I am very well aware about the ?vendor? attributes, and I guess You can make
> a difference about vendor extensions and specification?
>
> And regarding to GPT attributes, I personally would avoid writing partition
> table from the boot loader?
I never advocated writing to anything from the loader.
--
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
On 18.01.2019 22:35, Rodney W. Grimes wrote: >>> errm.. you press a key and enter device and or loader path. if it is not >>> working - the code is there to be fixed. >> And loader looks to "bootme" attribute and try to boot from partition >> which has one, even if it is loaded from other partition itself. >> >>> GPT does not have the concept of active partition. >> It has "bootme" / "bootonce" attributes. And [zfs]gptboot doesn't have >> any tools to set these attributes, AFAIK. Same for UEFI boot code. > > The gpart(8) command is used to set/unset these. gpart need booted system. NanoBSD typically have two "system" partitions, "old" (previous) and "new" (current). After upgrade they switched (new code is written to "previos" partition and bootable atteibute is set to it, "active" in case of MBR and "bootme" in case of GPT). If this new partition has problems and could not be booted, it is hard to boot from "old" (previous) one. MBR + boot0 could (interactively) change active partition before system is booted, and this problem could be solved with one keypress: you select old partition on boot. -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
On 18.01.2019 22:27, Warner Losh wrote: > > errm.. you press a key and enter device and or loader path. if it > is not working - the code is there to be fixed. > And loader looks to "bootme" attribute and try to boot from partition > which has one, even if it is loaded from other partition itself. > Correct. And system crashes, because "bootme" partition has broken installation. With MBR + boot0/boot0sio it is solved with one keypress. > > GPT does not have the concept of active partition. > It has "bootme" / "bootonce" attributes. And [zfs]gptboot doesn't have > any tools to set these attributes, AFAIK. Same for UEFI boot code. > > gpart can set these. You need live, booted system (at least single-user) to use gpart. > UEFI completely ignores them, though, because getting to that data is > hard in the UEFI environment. But in UEFI, you're supposed to use > Boot and BootOrder/BootNext as managed by efibootmgr. Again, you need booted system to use efibootmgr. boot0/boot0sio works before system and could switch boot partition in case of MBR. It is why I write, that GPT/Legacy and GPT/UEFI miss important feature which is present for MBR boot for ages. Which is sad & funny at same time, as GPT/UEFI has much more code than 512 bytes of boot0. -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
> On 18 Jan 2019, at 21:33, Rodney W. Grimes
> wrote:
>
>>
>>
>>> On 18 Jan 2019, at 19:57, Lev Serebryakov wrote:
>>>
>>> On 18.01.2019 20:13, Warner Losh wrote:
>>>
> Also, there are same problems with GPT/BIOS setup (which uses GPT but
> legacy boot) :-(
>
What same problems? I don't think we've touched how gptboot has handed off
to /boot/loader in a long, long time. It there's an issue here, it's a
different issue.
>>> Ok, strictly speaking it is different issue with same "high-level"
>>> description: pmbr/gptboot has less features than simplest oldest boot0.
>>>
>>> pmbr/gptbood doesn't have any way to select partition to boot from, as
>>> "boot0" has. No, setting "nextboot" from live system is not a solution.
>>> I speak about NanoBSD situation when there is tow partitions, both
>>> bootable, one marked as "active" ("bootme" on GPT parlance) but it is
>>> completely broken and user need to boot from other one form very
>>> beginning. This task is trivially solved by "boot0" in pure-MBR case.
>>> What about GPT/Legacy and GPT/UEFI?
>>>
>>> --
>>> // Lev Serebryakov
>>>
>>
>> errm.. you press a key and enter device and or loader path. if it is not
>> working - the code is there to be fixed.
>> GPT does not have the concept of active partition.
>
> It certainly does, it is called the attribute bootme,
> and the above correctly states that.
>
Shall you give the reference to specification?:)
I am very well aware about the “vendor” attributes, and I guess You can make a
difference about vendor extensions and specification…
And regarding to GPT attributes, I personally would avoid writing partition
table from the boot loader…
rgds,
toomas
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
> On 18.01.2019 21:14, Toomas Soome wrote: > > > errm.. you press a key and enter device and or loader path. if it is not > > working - the code is there to be fixed. > And loader looks to "bootme" attribute and try to boot from partition > which has one, even if it is loaded from other partition itself. > > > GPT does not have the concept of active partition. > It has "bootme" / "bootonce" attributes. And [zfs]gptboot doesn't have > any tools to set these attributes, AFAIK. Same for UEFI boot code. The gpart(8) command is used to set/unset these. -- Rod Grimes rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
>
>
> > On 18 Jan 2019, at 19:57, Lev Serebryakov wrote:
> >
> > On 18.01.2019 20:13, Warner Losh wrote:
> >
> >>> Also, there are same problems with GPT/BIOS setup (which uses GPT but
> >>> legacy boot) :-(
> >>>
> >>
> >> What same problems? I don't think we've touched how gptboot has handed off
> >> to /boot/loader in a long, long time. It there's an issue here, it's a
> >> different issue.
> > Ok, strictly speaking it is different issue with same "high-level"
> > description: pmbr/gptboot has less features than simplest oldest boot0.
> >
> > pmbr/gptbood doesn't have any way to select partition to boot from, as
> > "boot0" has. No, setting "nextboot" from live system is not a solution.
> > I speak about NanoBSD situation when there is tow partitions, both
> > bootable, one marked as "active" ("bootme" on GPT parlance) but it is
> > completely broken and user need to boot from other one form very
> > beginning. This task is trivially solved by "boot0" in pure-MBR case.
> > What about GPT/Legacy and GPT/UEFI?
> >
> > --
> > // Lev Serebryakov
> >
>
> errm.. you press a key and enter device and or loader path. if it is not
> working - the code is there to be fixed.
> GPT does not have the concept of active partition.
It certainly does, it is called the attribute bootme,
and the above correctly states that.
man gptboot
>
> My suggestion would be to walk all those boot programs and document them,
> then see what features are possible to bring to sync.
The gptboot use of bootme and bootonce are well documented.
--
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
On Fri, Jan 18, 2019 at 11:27 AM Lev Serebryakov wrote: > On 18.01.2019 21:14, Toomas Soome wrote: > > > errm.. you press a key and enter device and or loader path. if it is not > working - the code is there to be fixed. > And loader looks to "bootme" attribute and try to boot from partition > which has one, even if it is loaded from other partition itself. > Correct. > > GPT does not have the concept of active partition. > It has "bootme" / "bootonce" attributes. And [zfs]gptboot doesn't have > any tools to set these attributes, AFAIK. Same for UEFI boot code. > gpart can set these. UEFI completely ignores them, though, because getting to that data is hard in the UEFI environment. But in UEFI, you're supposed to use Boot and BootOrder/BootNext as managed by efibootmgr. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
On 18.01.2019 21:14, Toomas Soome wrote: > errm.. you press a key and enter device and or loader path. if it is not > working - the code is there to be fixed. And loader looks to "bootme" attribute and try to boot from partition which has one, even if it is loaded from other partition itself. > GPT does not have the concept of active partition. It has "bootme" / "bootonce" attributes. And [zfs]gptboot doesn't have any tools to set these attributes, AFAIK. Same for UEFI boot code. -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
> On 18 Jan 2019, at 19:57, Lev Serebryakov wrote:
>
> On 18.01.2019 20:13, Warner Losh wrote:
>
>>> Also, there are same problems with GPT/BIOS setup (which uses GPT but
>>> legacy boot) :-(
>>>
>>
>> What same problems? I don't think we've touched how gptboot has handed off
>> to /boot/loader in a long, long time. It there's an issue here, it's a
>> different issue.
> Ok, strictly speaking it is different issue with same "high-level"
> description: pmbr/gptboot has less features than simplest oldest boot0.
>
> pmbr/gptbood doesn't have any way to select partition to boot from, as
> "boot0" has. No, setting "nextboot" from live system is not a solution.
> I speak about NanoBSD situation when there is tow partitions, both
> bootable, one marked as "active" ("bootme" on GPT parlance) but it is
> completely broken and user need to boot from other one form very
> beginning. This task is trivially solved by "boot0" in pure-MBR case.
> What about GPT/Legacy and GPT/UEFI?
>
> --
> // Lev Serebryakov
>
errm.. you press a key and enter device and or loader path. if it is not
working - the code is there to be fixed. GPT does not have the concept of
active partition.
My suggestion would be to walk all those boot programs and document them, then
see what features are possible to bring to sync.
rgds,
toomas
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: UEFI, loader.efi and /boot.config
On 18.01.2019 20:13, Warner Losh wrote: > If your BIOS allows it, you can set the standard ConOut variables the UEFI > standard defines with the efivar program. In addition, you can add args to > the 'binary blob' part of the BOOT OPTIONS variables (Boot), though > efibootmgr doesn't currently support it (it likely should). All my UEFI-enabled systems have only one UEFI knob: "Boot: [LEGACY|UEFI]", it's all :-( It is not-so-new SuperMicro MoBos (X9, X10 generations), some Chinese MiniPC, Intel D2500CC MoBo and such. -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
On 18.01.2019 20:13, Warner Losh wrote:
>> Also, there are same problems with GPT/BIOS setup (which uses GPT but
>> legacy boot) :-(
>>
>
> What same problems? I don't think we've touched how gptboot has handed off
> to /boot/loader in a long, long time. It there's an issue here, it's a
> different issue.
Ok, strictly speaking it is different issue with same "high-level"
description: pmbr/gptboot has less features than simplest oldest boot0.
pmbr/gptbood doesn't have any way to select partition to boot from, as
"boot0" has. No, setting "nextboot" from live system is not a solution.
I speak about NanoBSD situation when there is tow partitions, both
bootable, one marked as "active" ("bootme" on GPT parlance) but it is
completely broken and user need to boot from other one form very
beginning. This task is trivially solved by "boot0" in pure-MBR case.
What about GPT/Legacy and GPT/UEFI?
--
// Lev Serebryakov
signature.asc
Description: OpenPGP digital signature
Re: UEFI, loader.efi and /boot.config
On Fri, Jan 18, 2019 at 8:55 AM Lev Serebryakov wrote: > On 18.01.2019 17:10, Kyle Evans wrote: > > > There's some UEFI var that's supposed to serve the same kind of > > purpose as /boot.config -- early boot parameters. I think we had > > discussed implementing this at some point, but this hasn't been done > > yet as far as I've seen. Would this be usable on your appliances? > How could I set UEFI variable? Via BIOS/UEFI Setup? I don't see this at > my systems. > If your BIOS allows it, you can set the standard ConOut variables the UEFI standard defines with the efivar program. In addition, you can add args to the 'binary blob' part of the BOOT OPTIONS variables (Boot), though efibootmgr doesn't currently support it (it likely should). > Also, there are same problems with GPT/BIOS setup (which uses GPT but > legacy boot) :-( > What same problems? I don't think we've touched how gptboot has handed off to /boot/loader in a long, long time. It there's an issue here, it's a different issue. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: UEFI, loader.efi and /boot.config
On Fri, Jan 18, 2019 at 8:27 AM Rodney W. Grimes < freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: > > On Fri, Jan 18, 2019, 12:49 AM Kurt Jaeger > > > > Hi! > > > > > > > With a recent change I made for UEFI, we now install loader.efi onto > the > > > ESP and don???t run boot1. That means that /boot.config is no longer > read, > > > and so console settings need to be put in /boot/loader.conf > > > > > > Which change is that ? > > > > > > > Moving from boot1.efi to loader.efi. loader.efi never looked at it. > > loader.efi honors the uefi env vars to set the console which replaces the > > old way. > > > > So it sounds like what we need is some documentation that covers: > > a) If your using mbr/bios boot and /boot.config you need to move > your settings from /boot.config to /boot/loader.conf > You don't need to do that. There's good technical reasons you might want to keep what you have because of order of evaluation. The legacy BIOS handoff need not change at all. > b) If your using uefi boot and /boot.config you need to migrate > your settings from /boot.config to uefi env vars foo bar and zep > > Or did I get loss in the twisty maze of changes? > If you migrate from using boot1.efi (which is on the way out: 13 will be its last release and it won't be used by default anymore) to loader.efi (which is used by default as of recently) you need to do something if you set your console via /boot.config (or /boot/config). Both boot1.efi and loader.efi automatically honor whatever the console is set in UEFI to. loader.efi has always allowed you to change it when loader.conf is read in. loader.efi has been further enhanced to guess the proper FreeBSD device from the UEFI variables for the console when not overriden by loader.conf. It's all a cluster of a mess, to be honest, and what the handoff formats are between the different stages is, at best, poorly defined. Oh, and to add "fun" to the mix, you can get the same /boot.conf behavior from loader.efi (and I think boot1.efi) if you pass load options into the Boot variable (though I don't think that efibootmgr does that now: it can display them, but I don't think it encodes them). This is done because of the current handoff between boot1.efi and loader.efi. Chances are good we should (a) document this and (b) enhance efibootmgr to grok setting options here because that would be the natural successor to /boot.config for people that have super-special needs that the defaults don't cover. Nailing down all the issues like this is why I didn't retire boot1.efi in 12. Warner > Warner > > > > > I was wondering if people will expect /boot.config to still be read and > > > so code should be added to loader to continue to parse it, or if > > > loader.conf can be considered the correct place and boot.config > forgotten > > > about? > > > > > > I have quite a few systems using /boot.config, but can cope if I know > > > about this. > > > > > > -- > > > p...@opsec.eu+49 171 3101372One year to > go ! > > -- > Rod Grimes > rgri...@freebsd.org > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: UEFI, loader.efi and /boot.config
On 18.01.2019 17:10, Kyle Evans wrote: > There's some UEFI var that's supposed to serve the same kind of > purpose as /boot.config -- early boot parameters. I think we had > discussed implementing this at some point, but this hasn't been done > yet as far as I've seen. Would this be usable on your appliances? How could I set UEFI variable? Via BIOS/UEFI Setup? I don't see this at my systems. Also, there are same problems with GPT/BIOS setup (which uses GPT but legacy boot) :-( -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Re: UEFI, loader.efi and /boot.config
> On Fri, Jan 18, 2019, 12:49 AM Kurt Jaeger > > Hi! > > > > > With a recent change I made for UEFI, we now install loader.efi onto the > > ESP and don???t run boot1. That means that /boot.config is no longer read, > > and so console settings need to be put in /boot/loader.conf > > > > Which change is that ? > > > > Moving from boot1.efi to loader.efi. loader.efi never looked at it. > loader.efi honors the uefi env vars to set the console which replaces the > old way. > So it sounds like what we need is some documentation that covers: a) If your using mbr/bios boot and /boot.config you need to move your settings from /boot.config to /boot/loader.conf or b) If your using uefi boot and /boot.config you need to migrate your settings from /boot.config to uefi env vars foo bar and zep Or did I get loss in the twisty maze of changes? > Warner > > > I was wondering if people will expect /boot.config to still be read and > > so code should be added to loader to continue to parse it, or if > > loader.conf can be considered the correct place and boot.config forgotten > > about? > > > > I have quite a few systems using /boot.config, but can cope if I know > > about this. > > > > -- > > p...@opsec.eu+49 171 3101372One year to go ! -- Rod Grimes rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: UEFI, loader.efi and /boot.config
On Fri, Jan 18, 2019, 12:49 AM Kurt Jaeger Hi! > > > With a recent change I made for UEFI, we now install loader.efi onto the > ESP and don???t run boot1. That means that /boot.config is no longer read, > and so console settings need to be put in /boot/loader.conf > > Which change is that ? > Moving from boot1.efi to loader.efi. loader.efi never looked at it. loader.efi honors the uefi env vars to set the console which replaces the old way. Warner > I was wondering if people will expect /boot.config to still be read and > so code should be added to loader to continue to parse it, or if > loader.conf can be considered the correct place and boot.config forgotten > about? > > I have quite a few systems using /boot.config, but can cope if I know > about this. > > -- > p...@opsec.eu+49 171 3101372One year to go ! > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: UEFI, loader.efi and /boot.config
On 18.01.2019 17:03, Olivier Cochard-Labbé wrote: > > I was wondering if people will expect /boot.config to still be > read and so code should be added to loader to continue to parse it, > or if loader.conf can be considered the correct place and > boot.config forgotten about? > Please, not, please support /boot.config. loader.conf could be too late > in case of serial consoles. > > I wonder, why EFI/UEFI and GPt booting (which should be more advanced) > is more limited than classic MBR/boot0 + boot1 + loader scheme :-( > > Serial console support is worse. Selection of boot partition is not > supported (as opposide to very-simple-516-bytes boot0!), and so on :-( > > > > Hi, > As an heavy nanobsd user on headless (serial/IPMI SoL) appliances, being > able to early select the boot partition by MBR/boot0 and configuring > early message redirection (with boot.config) is very useful. > Not being able to do the same with GPT/EFI is the feature preventing me > to upgrade my nanobsd image scheme. My case exactly. -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Re: UEFI, loader.efi and /boot.config
The loader.efi (EFI application) can receive command line arguments, set up in UEFI boot manager. rgds, toomas > On 18 Jan 2019, at 16:14, Kurt Jaeger wrote: > > Hello, > >> I was wondering if people will expect /boot.config to still be read and so >> code should be added to loader to continue to parse it, or if loader.conf >> can be considered the correct place and boot.config forgotten about? > > If the early boot messages are not displayed as Olivier mentioned, > that would be fatal. On some systems no other output besides serial > is useful. > > -- > p...@opsec.eu+49 171 3101372One year to go ! > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: UEFI, loader.efi and /boot.config
Hello, > I was wondering if people will expect /boot.config to still be read and so > code should be added to loader to continue to parse it, or if loader.conf can > be considered the correct place and boot.config forgotten about? If the early boot messages are not displayed as Olivier mentioned, that would be fatal. On some systems no other output besides serial is useful. -- p...@opsec.eu+49 171 3101372One year to go ! ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: UEFI, loader.efi and /boot.config
On Fri, Jan 18, 2019 at 8:04 AM Olivier Cochard-Labbé wrote: > > On Fri, Jan 18, 2019 at 2:10 PM Lev Serebryakov wrote: > > > On 18.01.2019 5:31, Rebecca Cran wrote: > > > > > > > I was wondering if people will expect /boot.config to still be read and > > so code should be added to loader to continue to parse it, or if > > loader.conf can be considered the correct place and boot.config forgotten > > about? > > Please, not, please support /boot.config. loader.conf could be too late > > in case of serial consoles. > > > > I wonder, why EFI/UEFI and GPt booting (which should be more advanced) > > is more limited than classic MBR/boot0 + boot1 + loader scheme :-( > > > > Serial console support is worse. Selection of boot partition is not > > supported (as opposide to very-simple-516-bytes boot0!), and so on :-( > > > > > > > Hi, > As an heavy nanobsd user on headless (serial/IPMI SoL) appliances, being > able to early select the boot partition by MBR/boot0 and configuring early > message redirection (with boot.config) is very useful. > Not being able to do the same with GPT/EFI is the feature preventing me to > upgrade my nanobsd image scheme. > So if there is a way of displaying EFI boot loader messages over > serial/IPMI SoL and selecting boot partiton, I've no objection to remove > boot.config support. > There's some UEFI var that's supposed to serve the same kind of purpose as /boot.config -- early boot parameters. I think we had discussed implementing this at some point, but this hasn't been done yet as far as I've seen. Would this be usable on your appliances? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: UEFI, loader.efi and /boot.config
On Fri, Jan 18, 2019 at 2:10 PM Lev Serebryakov wrote: > On 18.01.2019 5:31, Rebecca Cran wrote: > > > > I was wondering if people will expect /boot.config to still be read and > so code should be added to loader to continue to parse it, or if > loader.conf can be considered the correct place and boot.config forgotten > about? > Please, not, please support /boot.config. loader.conf could be too late > in case of serial consoles. > > I wonder, why EFI/UEFI and GPt booting (which should be more advanced) > is more limited than classic MBR/boot0 + boot1 + loader scheme :-( > > Serial console support is worse. Selection of boot partition is not > supported (as opposide to very-simple-516-bytes boot0!), and so on :-( > > > Hi, As an heavy nanobsd user on headless (serial/IPMI SoL) appliances, being able to early select the boot partition by MBR/boot0 and configuring early message redirection (with boot.config) is very useful. Not being able to do the same with GPT/EFI is the feature preventing me to upgrade my nanobsd image scheme. So if there is a way of displaying EFI boot loader messages over serial/IPMI SoL and selecting boot partiton, I've no objection to remove boot.config support. Regards, Olivier ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: UEFI, loader.efi and /boot.config
On 18.01.2019 5:31, Rebecca Cran wrote: > I was wondering if people will expect /boot.config to still be read and so > code should be added to loader to continue to parse it, or if loader.conf can > be considered the correct place and boot.config forgotten about? Please, not, please support /boot.config. loader.conf could be too late in case of serial consoles. I wonder, why EFI/UEFI and GPt booting (which should be more advanced) is more limited than classic MBR/boot0 + boot1 + loader scheme :-( Serial console support is worse. Selection of boot partition is not supported (as opposide to very-simple-516-bytes boot0!), and so on :-( -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Re: UEFI, loader.efi and /boot.config
Hi! > With a recent change I made for UEFI, we now install loader.efi onto the ESP > and don???t run boot1. That means that /boot.config is no longer read, and so > console settings need to be put in /boot/loader.conf Which change is that ? > I was wondering if people will expect /boot.config to still be read and so > code should be added to loader to continue to parse it, or if loader.conf can > be considered the correct place and boot.config forgotten about? I have quite a few systems using /boot.config, but can cope if I know about this. -- p...@opsec.eu+49 171 3101372One year to go ! ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: UEFI, loader.efi and /boot.config
On Thu, Jan 17, 2019, 7:33 PM Rebecca Cran > With a recent change I made for UEFI, we now install loader.efi onto the > ESP and don’t run boot1. That means that /boot.config is no longer read, > and so console settings need to be put in /boot/loader.conf. > I was wondering if people will expect /boot.config to still be read and so > code should be added to loader to continue to parse it, or if loader.conf > can be considered the correct place and boot.config forgotten about? > The problem is that by the time we know what / is. It's too late. If there is an error before that. It's kinda too late. Since it is too late, you should just set the console with loader.conf, since it is the standard place. I think it can be forgotten for these and other reasons... loader.conf is a superset of boot.conf anyway. Warnet — > Rebecca Cran > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: UEFI, loader.efi and /boot.config
On Thu, Jan 17, 2019 at 07:31:38PM -0700, Rebecca Cran wrote: > > With a recent change I made for UEFI, we now install loader.efi onto the ESP > and don’t run boot1. That means that /boot.config is no longer read, and so > console settings need to be put in /boot/loader.conf. > I was wondering if people will expect /boot.config to still be read and so > code should be added to loader to continue to parse it, or if loader.conf can > be considered the correct place and boot.config forgotten about? > Does the above only apply to UEFI booting, or also to booting from BIOS/MBR? If the latter, I'd be OK with the change as long as it's adequately publicized ahead of time (e.g., a src/UPDATING entry & -- ideally -- a "heads-up" in current@). If the former, I'm less opinionated: none of my personal machines boot UEFI. I'd tend to assume that changing to UEFI will involve some (other) changes to how I do things anyway. (My build machine uses /boot.config to default to "verbose" booting, dual-console.) Peace, david -- David H. Wolfskill da...@catwhisker.org Trump is more of an "existential" than "potential" threat to US security. See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
UEFI, loader.efi and /boot.config
With a recent change I made for UEFI, we now install loader.efi onto the ESP and don’t run boot1. That means that /boot.config is no longer read, and so console settings need to be put in /boot/loader.conf. I was wondering if people will expect /boot.config to still be read and so code should be added to loader to continue to parse it, or if loader.conf can be considered the correct place and boot.config forgotten about? — Rebecca Cran ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
