r326622 and r326820 broken?

2017-12-18 Thread KIRIYAMA Kazuhiko 
Hi,

I've fetched [1] and [2] and burned to USB and then boot by
the USB, but both does not boot and stop at boot loader at
the beginning:

BTX loader 1.00  BTX version is 1.02
Consoles: internal video/keyboad

Basically,does r326622 and r326820 broken ?

[1] FreeBSD-12.0-CURRENT-amd64-20171206-r326622-memstick.img
[2] FreeBSD-12.0-CURRENT-amd64-20171213-r326820-memstick.img

---
KIRIYAMA Kazuhiko
___
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 booting survey

2017-12-18 Thread Rodney W. Grimes 
> On Mon, Dec 18, 2017 at 3:12 PM, Mark Millard  wrote:
> 
> > Warner Losh imp at bsdimp.com wrote on
> > Mon Dec 18 20:29:45 UTC 2017 :
> >
> > > The specific thing we will stop doing is that in the absence of
> > > instructions to the contrary, we will no longer search for root on a
> > device
> > > other than the one the loader.efi came from.
> >
> > Warner Losh imp at bsdimp.com wrote on
> > Sun Dec 17 19:52:07 UTC 2017 :
> >
> > > In the coming months, we're looking at dropping boot1.efi and instead
> > > installing /boot/loader.efi onto the ESP (most likely as
> > > \efi\freebsd\loader.efi).
> >
> >
> > Combining the two statements would appear to have consequences
> > not obvious from the separate statements in isolation. Rewording
> > the first to substitute where loader.efi comes from based on
> > the second (if I interpret right):
> >
> > MISQUOTE
> > The specific thing we will stop doing is that in the absence of
> > instructions to the contrary, we will no longer search for root
> > on other than the device for the ESP used (which will hold
> > loader.efi).
> > END MISQUOTE
> >
> 
> The specific thing we will stop doing is that in the absence of
> instructions to the contrary, we will no longer search for root on other
> than the device for the ESP used (which will hold now loader.efi as
> boot1.efi will shortly be eliminated).

Yes please, that is the correct behavior, our searching can lead to
problems, and as you have pointed out, often more problems than it
ever really fixed.

> 
> Or the following pseudo-code with all the weird special cases removed for
> clarity
> 
> load loader.efi from ESP
> if Boot uefi variable holds a second path, use that for root/kernel
> otherwise if an override variable holds a kernel/root path, use that
> otherwise scan for a usable ZFS pool, use that if it exists
> otherwise use the same partition loader.efi was booted from for root/kernel
> if it's usable
> otherwise use the first UFS partition on the ESP that's usable.

use the ACTIVE ufs partition, not the first, I can have more than 1 slice,
only 1 of them can be set active.  Do not use any ufs partitions if they
are not in active slices, it is possible to have 0 partitions set active.

> 
> A partition is usable if /boot/loader.rc exists on that path.

A partition is usable if it is in an active slice, and ^above

Is there any fallback to skip loader and go direct to
/boot/kernel/kernel, back to /kernel any more?

> What is being deleted is one final step: "otherwise use the first UFS
> partition on any drive in a random order that's usable." which used to be
> at the end of the boot1.efi psuedo code. It's my belief that no such
> installations actually use this due to the random factor today (plug in a
> new USB drive and it might take over). If my belief is wrong, it's my
> belief that efibootmgr will solve it, and failing that, the fallback
> mechanism (for platforms that use u-boot + EFI where UEFI variables don't
> work) will allow the two or three people that are doing this today.
> 
> 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"

-- 
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 booting survey

2017-12-18 Thread Mark Millard 
Warner Losh imp at bsdimp.com wrote on 
Mon Dec 18 20:29:45 UTC 2017 :

> The specific thing we will stop doing is that in the absence of
> instructions to the contrary, we will no longer search for root on a device
> other than the one the loader.efi came from.

Warner Losh imp at bsdimp.com wrote on
Sun Dec 17 19:52:07 UTC 2017 :

> In the coming months, we're looking at dropping boot1.efi and instead
> installing /boot/loader.efi onto the ESP (most likely as
> \efi\freebsd\loader.efi).


Combining the two statements would appear to have consequences
not obvious from the separate statements in isolation. Rewording
the first to substitute where loader.efi comes from based on
the second (if I interpret right):

MISQUOTE
The specific thing we will stop doing is that in the absence of
instructions to the contrary, we will no longer search for root
on other than the device for the ESP used (which will hold
loader.efi).
END MISQUOTE

===
Mark Millard
markmi at dsl-only.net

___
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 booting survey

2017-12-18 Thread Warner Losh 
On Mon, Dec 18, 2017 at 3:12 PM, Mark Millard  wrote:

> Warner Losh imp at bsdimp.com wrote on
> Mon Dec 18 20:29:45 UTC 2017 :
>
> > The specific thing we will stop doing is that in the absence of
> > instructions to the contrary, we will no longer search for root on a
> device
> > other than the one the loader.efi came from.
>
> Warner Losh imp at bsdimp.com wrote on
> Sun Dec 17 19:52:07 UTC 2017 :
>
> > In the coming months, we're looking at dropping boot1.efi and instead
> > installing /boot/loader.efi onto the ESP (most likely as
> > \efi\freebsd\loader.efi).
>
>
> Combining the two statements would appear to have consequences
> not obvious from the separate statements in isolation. Rewording
> the first to substitute where loader.efi comes from based on
> the second (if I interpret right):
>
> MISQUOTE
> The specific thing we will stop doing is that in the absence of
> instructions to the contrary, we will no longer search for root
> on other than the device for the ESP used (which will hold
> loader.efi).
> END MISQUOTE
>

The specific thing we will stop doing is that in the absence of
instructions to the contrary, we will no longer search for root on other
than the device for the ESP used (which will hold now loader.efi as
boot1.efi will shortly be eliminated).

Or the following pseudo-code with all the weird special cases removed for
clarity

load loader.efi from ESP
if Boot uefi variable holds a second path, use that for root/kernel
otherwise if an override variable holds a kernel/root path, use that
otherwise scan for a usable ZFS pool, use that if it exists
otherwise use the same partition loader.efi was booted from for root/kernel
if it's usable
otherwise use the first UFS partition on the ESP that's usable.

A partition is usable if /boot/loader.rc exists on that path.

What is being deleted is one final step: "otherwise use the first UFS
partition on any drive in a random order that's usable." which used to be
at the end of the boot1.efi psuedo code. It's my belief that no such
installations actually use this due to the random factor today (plug in a
new USB drive and it might take over). If my belief is wrong, it's my
belief that efibootmgr will solve it, and failing that, the fallback
mechanism (for platforms that use u-boot + EFI where UEFI variables don't
work) will allow the two or three people that are doing this today.

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 booting survey

2017-12-18 Thread Warner Losh 
On Mon, Dec 18, 2017 at 1:21 PM, Maxim Sobolev  wrote:

> Not really specific to UEFI, but when ZFS is in use the /boot might be
> partially or fully located on the drive that does not correspond to your
> boot drive. We've bumped into this issue on AWS recently when our kernel
> ended up on second drive after upgrade in a pool that were spanning two EBS
> volumes. Now, it does not work with AWS (as boot code only has access to
> the boot EBS volume apparently), but according to Alan such scenario is
> totally supported on a physical hardware. So I am worried that by not
> allowing loader to scan all drives in the system you'd make this scenario
> fundamentally impossible.
>

Let's get one thing clear: nothing in what I've said would make this
impossible. The first thing we do is to boot off something specific, no
matter what that specific thing might be. If you want to boot a kernel off
a floppy after loading /boot/loader.efi from cdrom, I don't care and won't
prevent that since you can easily specify that with UEFI paths. For UFS the
above scenario wouldn't automatically work, but could easily be made to
work.

ZFS is a bit special, since it spans multiple drives. I'm not touching the
code that hunts for the zpools at all. If we can find them, and they have
the right info, we'll still boot. I'm surprised the upgrade didn't work,
especially with the code that's gone in to hunt for disks to present as
devices in the loader itself.

The specific thing we will stop doing is that in the absence of
instructions to the contrary, we will no longer search for root on a device
other than the one the loader.efi came from. No other boot loader we have
does that. No other loader outside of the tree does that to my knowledge.
boot1.efi is the only one that did, and it was a bad call to do so.

Warner


> On Mon, Dec 18, 2017 at 5:50 AM, Jakob Alvermark 
> wrote:
>
>> On 12/17/17 20:52, Warner Losh wrote:
>>
>>> Greetings
>>>
>>> If you are booting off UEFI and have a bit of an unusual setup, I'd like
>>> you to drop me a line.
>>>
>>> The setup that I'm looking for is any case where you load boot1.efi off
>>> one
>>> drive (cd, ssd, hdd, nvme, etc), but don't have a FreeBSD system on that
>>> drive, but on a different drive on the system.
>>>
>>> An example of this may be loading boot1.efi off what FreeBSD would call
>>> /dev/ada0p1, but having root come from /dev/ada1p1.
>>>
>>> It's my belief that due to the fragility of this setup, few, if any,
>>> people
>>> have this setup. If you do, please take a minute to reply to this
>>> message.
>>> In the coming months, we're looking at dropping boot1.efi and instead
>>> installing /boot/loader.efi onto the ESP (most likely as
>>> \efi\freebsd\loader.efi). As part of the move to fully support the UEFI
>>> Boot Manager, we're dropping the 'search every device in the system' part
>>> of the current boot1 algorithm. It will be possible to configure the
>>> system
>>> to continue booting (either via the new efibootmgr which will allow any
>>> imaginable combination, or possibly via a fallback mechanism needed for
>>> the
>>> embedded EFIs that have poor UEFI Variable support at the moment), but as
>>> part of an upgrade to a future FreeBSD 12, some intervention will be
>>> necessary.
>>>
>>> Please let me know if you have an unusual setup like this.
>>>
>>> Warner
>>>
>> Hi Warner,
>>
>> I have what I guess is an unusual setup, not like what you describe
>> above, but unusual because I tripple-boot my laptop using only the UEFI
>> boot manager to select the OS to boot.
>> I have FreeBSD-current, OpenBSD-current and Windows 10 on different
>> partitions on one SSD. By default it boots FreeBSD.
>>
>> This was accomplished with bcdedit.exe in Windows, but now I realize this
>> could be done with the new efibootmgr.
>> I wanted to try it out, but it panics on my laptop. Sometimes just
>> 'kldload efirt' just panics, sometimes it loads but panics as soon as I run
>> efibootmgr or efivar.
>> How can I help debugging this?
>>
>> Jakob
>>
>> ___
>> 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 booting survey

2017-12-18 Thread Maxim Sobolev 
Not really specific to UEFI, but when ZFS is in use the /boot might be
partially or fully located on the drive that does not correspond to your
boot drive. We've bumped into this issue on AWS recently when our kernel
ended up on second drive after upgrade in a pool that were spanning two EBS
volumes. Now, it does not work with AWS (as boot code only has access to
the boot EBS volume apparently), but according to Alan such scenario is
totally supported on a physical hardware. So I am worried that by not
allowing loader to scan all drives in the system you'd make this scenario
fundamentally impossible.

-Max

On Mon, Dec 18, 2017 at 5:50 AM, Jakob Alvermark 
wrote:

> On 12/17/17 20:52, Warner Losh wrote:
>
>> Greetings
>>
>> If you are booting off UEFI and have a bit of an unusual setup, I'd like
>> you to drop me a line.
>>
>> The setup that I'm looking for is any case where you load boot1.efi off
>> one
>> drive (cd, ssd, hdd, nvme, etc), but don't have a FreeBSD system on that
>> drive, but on a different drive on the system.
>>
>> An example of this may be loading boot1.efi off what FreeBSD would call
>> /dev/ada0p1, but having root come from /dev/ada1p1.
>>
>> It's my belief that due to the fragility of this setup, few, if any,
>> people
>> have this setup. If you do, please take a minute to reply to this message.
>> In the coming months, we're looking at dropping boot1.efi and instead
>> installing /boot/loader.efi onto the ESP (most likely as
>> \efi\freebsd\loader.efi). As part of the move to fully support the UEFI
>> Boot Manager, we're dropping the 'search every device in the system' part
>> of the current boot1 algorithm. It will be possible to configure the
>> system
>> to continue booting (either via the new efibootmgr which will allow any
>> imaginable combination, or possibly via a fallback mechanism needed for
>> the
>> embedded EFIs that have poor UEFI Variable support at the moment), but as
>> part of an upgrade to a future FreeBSD 12, some intervention will be
>> necessary.
>>
>> Please let me know if you have an unusual setup like this.
>>
>> Warner
>>
> Hi Warner,
>
> I have what I guess is an unusual setup, not like what you describe above,
> but unusual because I tripple-boot my laptop using only the UEFI boot
> manager to select the OS to boot.
> I have FreeBSD-current, OpenBSD-current and Windows 10 on different
> partitions on one SSD. By default it boots FreeBSD.
>
> This was accomplished with bcdedit.exe in Windows, but now I realize this
> could be done with the new efibootmgr.
> I wanted to try it out, but it panics on my laptop. Sometimes just
> 'kldload efirt' just panics, sometimes it loads but panics as soon as I run
> efibootmgr or efivar.
> How can I help debugging this?
>
> Jakob
>
> ___
> 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: r326820 stuck on bootloader

2017-12-18 Thread Warner Losh 
On Mon, Dec 18, 2017 at 9:52 AM, O. Hartmann  wrote:

> Am Mon, 18 Dec 2017 09:48:01 -0700
> Warner Losh  schrieb:
>
> > On Mon, Dec 18, 2017 at 9:16 AM, O. Hartmann 
> wrote:
> >
> > > Am Mon, 18 Dec 2017 05:35:33 -0800 (PST)
> > > "Rodney W. Grimes"  schrieb:
> > >
> > > >
> > > > > Hey all!
> > > > >
> > > > > I have just downloaded
> > > > > FreeBSD-12.0-CURRENT-amd64-20171213-r326820-memstick.img.xz and
> > > > > decompressed it, trying to boot it on QEMU and I get "Consoles:
> > > > > internal video/keyboard" and then it's stuck.
> > > > >
> > > > > I actually have no idea how to debug, any help would be
> appreciated.
> > > >
> > > > This snapshot may have broken boot code in it, I had problems
> > > > installing it to a zfs system and had to post install replace
> > > > my zfs boot blocks from those of 20171206.
> > > >
> > > >
> > > > > Thanks in advance,
> > > > > - --
> > > > > antranigv
> > > >
> > >
> > > The shit hit the fan at > r326593 (this is what Warner wrote me back, I
> > > had no problems
> > > with r326583, but r326584 and beyond had compilation issues). I tried
> > > r326593 and it
> > > worked for me (had issues on a serial console for the PCengine APU2C4).
> > >
> > > From usr/src/UPDATING, tag designated by "20171215":
> > >
> > > 20171215:
> > > r326887 fixes the issue described in the 20171214 UPDATING
> entry.
> > > r326888 flips the switch back to building GELI support always.
> > >
> > > [...]
> > >
> > > I tried the first time r326888 on the APU 2C4 and it worked again -
> this
> > > doesn't imply
> > > that the GPT GELI and ZFSBOOT loader are all right again, but Warner
> Losh
> > > stated it is
> > > fixed.
> > >
> >
> > Yes. I've confirmed that zfsboot works with or without the GELI code
> > compiled in. I've not confirmed that ZFS + GELI partitions work. I
> haven't
> > updated my test scripts in tools/boot/genroot.sh to create them yet. If
> > someone who knows this stuff really well wants to do that for one image
> > (gpt + zfs + geli) I can (a) test and (b) generalize.
> >
> > Warner
>
> Oh, my bad. So it is still to use with caution?
>

I have good reason to believe it will work. I fixed the underlying issues
that were broken in '593, so I think it will work again. I just haven't
confirmed it and hoped that someone else could get to it before I could :)


> At that point I can not understand why the build of bootable images is
> still in progress.
> People which desperate in need of a bootable image may download the wrong
> one from the
> FreeBSD site - and find out the harsh way it is broken. If the build of
> those images is
> automated - can this be stopped?


 That shouldn't be necessary. The normal images should be fine.

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: r326820 stuck on bootloader

2017-12-18 Thread O. Hartmann 
Am Mon, 18 Dec 2017 09:48:01 -0700
Warner Losh  schrieb:

> On Mon, Dec 18, 2017 at 9:16 AM, O. Hartmann  wrote:
> 
> > Am Mon, 18 Dec 2017 05:35:33 -0800 (PST)
> > "Rodney W. Grimes"  schrieb:
> >  
> > >  
> > > > Hey all!
> > > >
> > > > I have just downloaded
> > > > FreeBSD-12.0-CURRENT-amd64-20171213-r326820-memstick.img.xz and
> > > > decompressed it, trying to boot it on QEMU and I get "Consoles:
> > > > internal video/keyboard" and then it's stuck.
> > > >
> > > > I actually have no idea how to debug, any help would be appreciated.  
> > >
> > > This snapshot may have broken boot code in it, I had problems
> > > installing it to a zfs system and had to post install replace
> > > my zfs boot blocks from those of 20171206.
> > >
> > >  
> > > > Thanks in advance,
> > > > - --
> > > > antranigv  
> > >  
> >
> > The shit hit the fan at > r326593 (this is what Warner wrote me back, I
> > had no problems
> > with r326583, but r326584 and beyond had compilation issues). I tried
> > r326593 and it
> > worked for me (had issues on a serial console for the PCengine APU2C4).
> >
> > From usr/src/UPDATING, tag designated by "20171215":
> >
> > 20171215:
> > r326887 fixes the issue described in the 20171214 UPDATING entry.
> > r326888 flips the switch back to building GELI support always.
> >
> > [...]
> >
> > I tried the first time r326888 on the APU 2C4 and it worked again - this
> > doesn't imply
> > that the GPT GELI and ZFSBOOT loader are all right again, but Warner Losh
> > stated it is
> > fixed.
> >  
> 
> Yes. I've confirmed that zfsboot works with or without the GELI code
> compiled in. I've not confirmed that ZFS + GELI partitions work. I haven't
> updated my test scripts in tools/boot/genroot.sh to create them yet. If
> someone who knows this stuff really well wants to do that for one image
> (gpt + zfs + geli) I can (a) test and (b) generalize.
> 
> Warner

Oh, my bad. So it is still to use with caution?

At that point I can not understand why the build of bootable images is still in 
progress.
People which desperate in need of a bootable image may download the wrong one 
from the
FreeBSD site - and find out the harsh way it is broken. If the build of those 
images is
automated - can this be stopped?

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpidP9wfk0VC.pgp
Description: OpenPGP digital signature

Re: r326820 stuck on bootloader

2017-12-18 Thread Warner Losh 
On Mon, Dec 18, 2017 at 9:16 AM, O. Hartmann  wrote:

> Am Mon, 18 Dec 2017 05:35:33 -0800 (PST)
> "Rodney W. Grimes"  schrieb:
>
> >
> > > Hey all!
> > >
> > > I have just downloaded
> > > FreeBSD-12.0-CURRENT-amd64-20171213-r326820-memstick.img.xz and
> > > decompressed it, trying to boot it on QEMU and I get "Consoles:
> > > internal video/keyboard" and then it's stuck.
> > >
> > > I actually have no idea how to debug, any help would be appreciated.
> >
> > This snapshot may have broken boot code in it, I had problems
> > installing it to a zfs system and had to post install replace
> > my zfs boot blocks from those of 20171206.
> >
> >
> > > Thanks in advance,
> > > - --
> > > antranigv
> >
>
> The shit hit the fan at > r326593 (this is what Warner wrote me back, I
> had no problems
> with r326583, but r326584 and beyond had compilation issues). I tried
> r326593 and it
> worked for me (had issues on a serial console for the PCengine APU2C4).
>
> From usr/src/UPDATING, tag designated by "20171215":
>
> 20171215:
> r326887 fixes the issue described in the 20171214 UPDATING entry.
> r326888 flips the switch back to building GELI support always.
>
> [...]
>
> I tried the first time r326888 on the APU 2C4 and it worked again - this
> doesn't imply
> that the GPT GELI and ZFSBOOT loader are all right again, but Warner Losh
> stated it is
> fixed.
>

Yes. I've confirmed that zfsboot works with or without the GELI code
compiled in. I've not confirmed that ZFS + GELI partitions work. I haven't
updated my test scripts in tools/boot/genroot.sh to create them yet. If
someone who knows this stuff really well wants to do that for one image
(gpt + zfs + geli) I can (a) test and (b) generalize.

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: r326820 stuck on bootloader

2017-12-18 Thread Chris H 

On Mon, 18 Dec 2017 05:35:33 -0800 (PST) "Rodney W. Grimes" 
 said


> Hey all!
> 
> I have just downloaded

> FreeBSD-12.0-CURRENT-amd64-20171213-r326820-memstick.img.xz and
> decompressed it, trying to boot it on QEMU and I get "Consoles:
> internal video/keyboard" and then it's stuck.
> 
> I actually have no idea how to debug, any help would be appreciated.


This snapshot may have broken boot code in it, I had problems
installing it to a zfs system and had to post install replace
my zfs boot blocks from those of 20171206.

Like I said; I can confirm r326056 (2017-11-21) doesn't contain the boot
regression. Warner advised me to try an earlier version when I indicated
I had the problem you also described in this message.
Yesterday, Warner indicated he believes he has corrected this regression,
as well as add some other goodies. So it should be safe to svn up to the
latest revision, after your initial install, and build from there.

--Chris



> Thanks in advance,
> - -- 
> antranigv


--
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"



___
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: r326820 stuck on bootloader

2017-12-18 Thread O. Hartmann 
Am Mon, 18 Dec 2017 05:35:33 -0800 (PST)
"Rodney W. Grimes"  schrieb:

>  
> > Hey all!
> > 
> > I have just downloaded
> > FreeBSD-12.0-CURRENT-amd64-20171213-r326820-memstick.img.xz and
> > decompressed it, trying to boot it on QEMU and I get "Consoles:
> > internal video/keyboard" and then it's stuck.
> > 
> > I actually have no idea how to debug, any help would be appreciated.  
> 
> This snapshot may have broken boot code in it, I had problems
> installing it to a zfs system and had to post install replace
> my zfs boot blocks from those of 20171206.
> 
> 
> > Thanks in advance,
> > - -- 
> > antranigv  
> 

The shit hit the fan at > r326593 (this is what Warner wrote me back, I had no 
problems
with r326583, but r326584 and beyond had compilation issues). I tried r326593 
and it
worked for me (had issues on a serial console for the PCengine APU2C4).

From usr/src/UPDATING, tag designated by "20171215":

20171215:
r326887 fixes the issue described in the 20171214 UPDATING entry.
r326888 flips the switch back to building GELI support always.

[...]

I tried the first time r326888 on the APU 2C4 and it worked again - this 
doesn't imply
that the GPT GELI and ZFSBOOT loader are all right again, but Warner Losh 
stated it is
fixed.

I'm with FreeBSD 12.0-CURRENT #16 r326911: Sat Dec 16 20:49:38 CET 2017 amd64 
and it is
working well so far.

Kind regards,
Oliver



-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpkcLveWTro7.pgp
Description: OpenPGP digital signature

Re: r326820 stuck on bootloader

2017-12-18 Thread Rodney W. Grimes 
> Ok,
> 
> I will install the snapshot before. but is it fixed now? since after the
> installation I will do buildworld, hope it will not brick.

The boot code is in a lot of flux right now, so be carefull and pay
attention to commit mail.You should keep the memstick image
around for repair incase you have issues.


> Thanks a lot!
> 
> --
> antranigv
> https://antranigv.am/|PGP Key ID : 0xDAB81456
> /* do one thing and do it well */
> 
> On Dec 18, 2017 5:35 PM, "Rodney W. Grimes" <
> freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:
> 
> >
> > > Hey all!
> > >
> > > I have just downloaded
> > > FreeBSD-12.0-CURRENT-amd64-20171213-r326820-memstick.img.xz and
> > > decompressed it, trying to boot it on QEMU and I get "Consoles:
> > > internal video/keyboard" and then it's stuck.
> > >
> > > I actually have no idea how to debug, any help would be appreciated.
> >
> > This snapshot may have broken boot code in it, I had problems
> > installing it to a zfs system and had to post install replace
> > my zfs boot blocks from those of 20171206.
> >
> >
> > > Thanks in advance,
> > > - --
> > > antranigv
> >
> > --
> > Rod Grimes
> > rgri...@freebsd.org
> >

-- 
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: r326820 stuck on bootloader

2017-12-18 Thread Antranig Vartanian 
Ok,

I will install the snapshot before. but is it fixed now? since after the
installation I will do buildworld, hope it will not brick.

Thanks a lot!

--
antranigv
https://antranigv.am/|PGP Key ID : 0xDAB81456
/* do one thing and do it well */

On Dec 18, 2017 5:35 PM, "Rodney W. Grimes" <
freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:

>
> > Hey all!
> >
> > I have just downloaded
> > FreeBSD-12.0-CURRENT-amd64-20171213-r326820-memstick.img.xz and
> > decompressed it, trying to boot it on QEMU and I get "Consoles:
> > internal video/keyboard" and then it's stuck.
> >
> > I actually have no idea how to debug, any help would be appreciated.
>
> This snapshot may have broken boot code in it, I had problems
> installing it to a zfs system and had to post install replace
> my zfs boot blocks from those of 20171206.
>
>
> > Thanks in advance,
> > - --
> > antranigv
>
> --
> 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: r326820 stuck on bootloader

2017-12-18 Thread Rodney W. Grimes 
 
> Hey all!
> 
> I have just downloaded
> FreeBSD-12.0-CURRENT-amd64-20171213-r326820-memstick.img.xz and
> decompressed it, trying to boot it on QEMU and I get "Consoles:
> internal video/keyboard" and then it's stuck.
> 
> I actually have no idea how to debug, any help would be appreciated.

This snapshot may have broken boot code in it, I had problems
installing it to a zfs system and had to post install replace
my zfs boot blocks from those of 20171206.


> Thanks in advance,
> - -- 
> antranigv

-- 
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: r326820 stuck on bootloader

2017-12-18 Thread Chris H 

On Mon, 18 Dec 2017 13:45:11 +0400 "antranigv"  said


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey all!

I have just downloaded
FreeBSD-12.0-CURRENT-amd64-20171213-r326820-memstick.img.xz and
decompressed it, trying to boot it on QEMU and I get "Consoles:
internal video/keyboard" and then it's stuck.

I actually have no idea how to debug, any help would be appreciated.

There was a problem in this area introduced somewhere in the beginning
of December. Warner just landed the correction(s) yesterday (I don't have
the revision handy). But it doesn't look like an install image with those
chances has been cut yet. Your best option as it stands, it to download:
https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20171121-r326056-memstick.img.xz
Which was cut before the regression. After installation. You can svn up to
the latest revision, and build from there. Thereby getting the fixes Warner
just added.

HTH

--Chris



Thanks in advance,

- -- 
antranigv

https://antranigv.am/|PGP Key ID : 0xDAB81456
/* do one thing and do it well */
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEfrjE/88u0Kph7jFZYGhrFNq4FFYFAlo3jiIACgkQYGhrFNq4
FFbuWw//du5kjUIR442fkCaCg8honaeZFJ666iwQE1grsSQS74kYzwQ1iSXBnGLV
kPt6Nslz3YIRmIqDMuKr31a6zK33bLi7hfKbodIcPNIn/EBUY/D/Pq4FXgqZxu99
MGDAsbLafA3YhyeVuilxrHyDZjaUMDGfJCcBBB57/SxY9mEFT3g/zw1vdVDwpe52
/0bi3u3r/H4l88KGtECSI08WlqnpDyPeGuHImb/xrkQmGbl6PiHwvrijOP639JDf
OpDEvLENRIwIBGYxsJPBk3EBPYEgpJKPm1yTU1swU/KJlCpau9O9WrG6OqO8qflO
HOCzyhKvXJdXkphlVBLfYk6e8NKwHwc+7ZaMEDJDvqGJ9qFWXanALBkBRyREW61K
ZY/8uLhoKNjPmAAMBgwbPihf35zWEXZhKLsaMza5f5NNniLCRrn+I4QhvhWlp10u
20tKX0bAJ+0sjQZInfqXftEwD5Mhw+H1sM1vk8igFFWyrMPCG9t0piV/AseixgDu
SZ9IGl5EZSpq/q6Jhcjfxlplwi31SwkVWIRjDqBmzcVcYQO6khszCdi3S1b9Y5El
T6gIswPuPWboJFGjPJxQN9V3APNUXT6c2p0aXq8S4NcvSRRmhyEc9mgc/LZrAX4a
hwQSVmtJL15qhvBc6TgWEBAaLL9+eX2G9G2Wr1ZEBg5tx/1eY/I=
=TQCj
-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"



___
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 booting survey

2017-12-18 Thread Jakob Alvermark 

On 12/17/17 20:52, Warner Losh wrote:

Greetings

If you are booting off UEFI and have a bit of an unusual setup, I'd like
you to drop me a line.

The setup that I'm looking for is any case where you load boot1.efi off one
drive (cd, ssd, hdd, nvme, etc), but don't have a FreeBSD system on that
drive, but on a different drive on the system.

An example of this may be loading boot1.efi off what FreeBSD would call
/dev/ada0p1, but having root come from /dev/ada1p1.

It's my belief that due to the fragility of this setup, few, if any, people
have this setup. If you do, please take a minute to reply to this message.
In the coming months, we're looking at dropping boot1.efi and instead
installing /boot/loader.efi onto the ESP (most likely as
\efi\freebsd\loader.efi). As part of the move to fully support the UEFI
Boot Manager, we're dropping the 'search every device in the system' part
of the current boot1 algorithm. It will be possible to configure the system
to continue booting (either via the new efibootmgr which will allow any
imaginable combination, or possibly via a fallback mechanism needed for the
embedded EFIs that have poor UEFI Variable support at the moment), but as
part of an upgrade to a future FreeBSD 12, some intervention will be
necessary.

Please let me know if you have an unusual setup like this.

Warner

Hi Warner,

I have what I guess is an unusual setup, not like what you describe 
above, but unusual because I tripple-boot my laptop using only the UEFI 
boot manager to select the OS to boot.
I have FreeBSD-current, OpenBSD-current and Windows 10 on different 
partitions on one SSD. By default it boots FreeBSD.


This was accomplished with bcdedit.exe in Windows, but now I realize 
this could be done with the new efibootmgr.
I wanted to try it out, but it panics on my laptop. Sometimes just 
'kldload efirt' just panics, sometimes it loads but panics as soon as I 
run efibootmgr or efivar.

How can I help debugging this?

Jakob
___
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"

base packages and subdirs with no regular files

2017-12-18 Thread Boris Samorodov 
Hi All!

I use base package for more then a year now. It works mostly fine.
However today I noticed that (some?) blank subdirectories are not
removed while updating:
---
% LANG=C ls -l /usr/lib/clang
drwxr-xr-x  4 root  wheel  4 Dec 22  2016 3.9.1
drwxr-xr-x  4 root  wheel  4 Mar  3  2017 4.0.0
drwxr-xr-x  4 root  wheel  4 Aug 28 14:50 5.0.0
drwxr-xr-x  4 root  wheel  4 Dec  8 13:09 5.0.1
---

All previous (to 5.0.1) clang version dirs contain only directories,
no regular files:
---
% LANG=C ls -l /usr/lib/clang/5.0.0
total 25
drwxr-xr-x  3 root  wheel  3 Dec  8 13:09 include
drwxr-xr-x  3 root  wheel  3 Aug 28 14:50 lib

% LANG=C ls -l /usr/lib/clang/5.0.0/include
total 1
drwxr-xr-x  2 root  wheel  2 Dec  8 13:09 sanitizer

% LANG=C ls -l /usr/lib/clang/5.0.0/include/sanitizer
total 0
---

I use my personal base package builder and just "pkg upgrade"
for, well, upgrades.

-- 
WBR, bsam
___
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"

r326820 stuck on bootloader

2017-12-18 Thread antranigv 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey all!

I have just downloaded
FreeBSD-12.0-CURRENT-amd64-20171213-r326820-memstick.img.xz and
decompressed it, trying to boot it on QEMU and I get "Consoles:
internal video/keyboard" and then it's stuck.

I actually have no idea how to debug, any help would be appreciated.

Thanks in advance,

- -- 
antranigv
https://antranigv.am/|PGP Key ID : 0xDAB81456
/* do one thing and do it well */
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEfrjE/88u0Kph7jFZYGhrFNq4FFYFAlo3jiIACgkQYGhrFNq4
FFbuWw//du5kjUIR442fkCaCg8honaeZFJ666iwQE1grsSQS74kYzwQ1iSXBnGLV
kPt6Nslz3YIRmIqDMuKr31a6zK33bLi7hfKbodIcPNIn/EBUY/D/Pq4FXgqZxu99
MGDAsbLafA3YhyeVuilxrHyDZjaUMDGfJCcBBB57/SxY9mEFT3g/zw1vdVDwpe52
/0bi3u3r/H4l88KGtECSI08WlqnpDyPeGuHImb/xrkQmGbl6PiHwvrijOP639JDf
OpDEvLENRIwIBGYxsJPBk3EBPYEgpJKPm1yTU1swU/KJlCpau9O9WrG6OqO8qflO
HOCzyhKvXJdXkphlVBLfYk6e8NKwHwc+7ZaMEDJDvqGJ9qFWXanALBkBRyREW61K
ZY/8uLhoKNjPmAAMBgwbPihf35zWEXZhKLsaMza5f5NNniLCRrn+I4QhvhWlp10u
20tKX0bAJ+0sjQZInfqXftEwD5Mhw+H1sM1vk8igFFWyrMPCG9t0piV/AseixgDu
SZ9IGl5EZSpq/q6Jhcjfxlplwi31SwkVWIRjDqBmzcVcYQO6khszCdi3S1b9Y5El
T6gIswPuPWboJFGjPJxQN9V3APNUXT6c2p0aXq8S4NcvSRRmhyEc9mgc/LZrAX4a
hwQSVmtJL15qhvBc6TgWEBAaLL9+eX2G9G2Wr1ZEBg5tx/1eY/I=
=TQCj
-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: what's changed with newsyslog?

2017-12-18 Thread Baptiste Daroussin 
On Sun, Dec 17, 2017 at 04:41:29PM -0500, Michael Butler wrote:
> On 12/17/17 16:38, Ben Woods wrote:
> > On Mon, 18 Dec 2017 at 3:47 am, Michael Butler
> > > wrote:
> > 
> > In the past week or so I've been getting warnings like this ..
> > 
> > bzip2: Can't open input file /var/log/snmpd.log.0: No such file or
> > directory.
> > newsyslog: `/usr/bin/bzip2 -f /var/log/snmpd.log.0
> > /var/log/fwlw_clean_log.0' terminated with a non-zero status (1)
> 
>  [ .. snip .. ]
> 
> > 
> > 
> > Hints?
> > 
> >         imb
> > 
> > Could this be related to bapt’s recent change 11 days ago to allow
> > newsyslog to use different style of compression commands?
> > https://svnweb.freebsd.org/base?view=revision=326617
> 
> Yes - I reverted to r326616 and the issue no longer appears,
> 
>   imb
> 

Should be fixed in r326930, sorry about that

Best regards,
Bapt


signature.asc
Description: PGP signature