> > > > On 18 Jan 2019, at 19:57, Lev Serebryakov <lev_at_FreeBSD.org> 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 rgrimes_at_freebsd.orgReceived on Fri Jan 18 2019 - 18:33:47 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:20 UTC