Re: Multiport serial card Exsys EX-44388, where are the devices ?
On Fri, Jan 18, 2019 at 2:53 PM Kurt Jaeger wrote: > Hi! > > Trying to get a 8-port serial PCIe card into operation (Exsys EX-44388). > After reboot, dmesg shows: > > uart2: <16550 or compatible> port 0x3e8-0x3ef irq 10 on acpi0 > > and /dev/ has cuau2* devices. It's unclear, which of the 8 ports > is cuau2 (I'll test that later, I promise 8-), but where are the > other ports ? > > I've tried to add > > hint.uart.3.at="isa" > hint.uart.3.port="0x3e0" > hint.uart.3.irq="10" > hint.uart.4.at="isa" > hint.uart.4.port="0x3d8" > hint.uart.4.irq="10" > > to /boot/devices.hint and rebooted, but there are no additional ports > found... > > I've read > > https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/serial.html > > and the manpage sio(4). It says to build a kernel with > > options COM_MULTIPORT > device sio > > which I tried (r343121) and it fails: > > /usr/src/sys/dev/sio/sio.c:361:6: error: no member named 't_init_in' in > 'struct tty' > tp->t_init_in.c_ispeed = tp->t_init_in.c_ospeed = > ~~ ^ > > So, is sio(4) out of fashion ? What is suggested to get my other 7 serial > ports ? > uart is the new thing. sio info should be ignored. Chances are good that this device doesn't have the proper entries in the puc driver. Do you have any pci devices that show up as unclaimed? 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"
Multiport serial card Exsys EX-44388, where are the devices ?
Hi! Trying to get a 8-port serial PCIe card into operation (Exsys EX-44388). After reboot, dmesg shows: uart2: <16550 or compatible> port 0x3e8-0x3ef irq 10 on acpi0 and /dev/ has cuau2* devices. It's unclear, which of the 8 ports is cuau2 (I'll test that later, I promise 8-), but where are the other ports ? I've tried to add hint.uart.3.at="isa" hint.uart.3.port="0x3e0" hint.uart.3.irq="10" hint.uart.4.at="isa" hint.uart.4.port="0x3d8" hint.uart.4.irq="10" to /boot/devices.hint and rebooted, but there are no additional ports found... I've read https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/serial.html and the manpage sio(4). It says to build a kernel with options COM_MULTIPORT device sio which I tried (r343121) and it fails: /usr/src/sys/dev/sio/sio.c:361:6: error: no member named 't_init_in' in 'struct tty' tp->t_init_in.c_ispeed = tp->t_init_in.c_ospeed = ~~ ^ So, is sio(4) out of fashion ? What is suggested to get my other 7 serial ports ? -- 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: 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
