Makefile show all flags

2017-12-09 Thread blubee blubeeme 
When porting software FreeBSD has a lot of internal makefiles that gets
pulled in that setup the build environment: /usr/ports/Mk/*

Is there a way to print out the env during the make process so that I can
see what knobs, switches and flags were set before the build is run?
___
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: r326734: serial console fails: boot stuck at: Consoles: internal video/keyboard

2017-12-09 Thread O. Hartmann 
Am Sat, 9 Dec 2017 14:30:38 -0700
Warner Losh  schrieb:

> On Sat, Dec 9, 2017 at 1:47 PM, O. Hartmann  wrote:
> 
> > Am Sat, 9 Dec 2017 13:00:12 -0700
> > Warner Losh  schrieb:
> >  
> > > On Sat, Dec 9, 2017 at 12:13 PM, Michael Tuexen   
> > wrote:  
> > >  
> > > > > On 9. Dec 2017, at 19:41, O. Hartmann   
> > wrote:  
> > > > >
> > > > > Running a PCengines APU2C4 with FreeBSD Current, r326734, fails to  
> > boot,  
> > > > it gets stuck at  
> > > > > the very first messages on the serial console prompting
> > > > >
> > > > > Consoles: internal video/keyboard
> > > > >
> > > > > and then nothing more.  
> > > > I don't think it is a general problem with r326734. I'm running on the
> > > > same hardware
> > > > that revision (with some modifications to the TCP I'm testing):  
> > > > > uname -a  
> > > > FreeBSD nf3.testbed 12.0-CURRENT FreeBSD 12.0-CURRENT #31 r326734M: Sat
> > > > Dec  9 20:03:59 CET 2017 tuexen@nf3.testbed:/usr/home/
> > > > tuexen/head/sys/amd64/compile/TCP  amd64
> > > >  
> > >
> > > Hi Michael,
> > >
> > > What's your boot setup? BIOS vs UEFI? UFS vs ZFS? GELI? GPT vs MBR?  
> > Plants  
> > > vs Zombies? And did you update your boot blocks or not?
> > >
> > > Warner  
> >
> > All right, I got your point here, my bad, my apaologies.
> >
> > I boot from a NanoBSD-prepared image residing on a SD card. The partiton
> > scheme is GPT,
> > non UEFI (the SeaBIOS, latest version available for the APU2C2 available)
> > doesn't support
> > UEFI. NanoBSD scripts (legacy.sh) has been modified to fit our requests.
> >
> > The modifications target at most the creation of a GPT partition scheme
> > layout,
> > installing boot/pmbr as bootcode and boot/gptboot on a freebsd-boot
> > partition as well as
> > boot/boot1.efifat onto a dedicated efi-type partition. The UEFI partition
> > is usually
> > created before(!) the freebsd-boot partition, but in this specific
> > version, there is NO
> > EFI partition, only the gptboot containing partition. The binaries of the
> > above mentioned
> > bootcode/efi code images are taken from the newly build world. I do not
> > use boot0sio, the
> > portion where it is installed is excluded by some "if GPT; then" clause.
> >
> > The last known-good version I reported in working is the image I backuped
> > last time. I
> > lost the USB 2.0 flash device today containing the last version, that was
> > not far from
> > r326218, the version that corrupted FreeBSD, I guess it was r326184, but I
> > really do not
> > know and I havn't a backup of that image.
> >
> > The buildworld process is maintained by a bunch of WITHOUT_ statements in
> > a file driving
> > NanoBSD. This just for the record just in case FreeBSD build system changed
> > something significantly.
> >  
> 
> Should, but if you could share what those all are, I can tell you if any
> might cause an issue that would help us root cause.
> 
> 
> > Building a world takes 90 minutes or more, so bi-secting the problem would
> > be a pain in
> > the arse (that said, I imply that world and kernel need to be in sync).
> >
> > I would appreciate hints or tipps where to look after or how to increase
> > verbosity
> > especially at the first boot stage.
> >  
> 
> OK. So you are booting with gptboot off an SD card on the PC Engines system
> via legacy methods for a UFS root partition. GELI is not involved, correct?

I do not use GELI. GEOM_GELI is in ther kernel compiled in. No modules are 
allowed to be
loaded.

The disk image created and mounted via md0 (mdconfig -a -t vndo -f 
filename.img) looks
like:

=> 40  5175704  md0  GPT  (2.5G)
   40 10242  boot0  (512K)
 1064  20594643  dsks1a  (1.0G)
  2060528  20636434  dsks2a  (1.0G)
  4124171  10485765  dsks3  (512M)
  5172747 2997   - free -  (1.5M)

This is the image type without UEFI partition, legacy boot only via gptboot.

> 
> Sadly, there's no easy way to increase the verbosity of the early boot
> since the boot blocks have to live in such a constrained environment
> there's a strong bias against including debug code.
> 
> But what we know is encouraging. We know that gptboot properly loaded, and
> that it found /boot/loader, loaded it, and then we had the issue.  This
> helps us constrain things somewhat in testing. For the moment, we'll assume
> that gptboot is good, and concentrate on when /boot/loader went south.
> Before we do that, can I get any loader.conf and /boot.config /boot/config
> files you have?

boot.config/loader.conf are non existent.

[loader.conf.local]
boot_serial="YES"
comconsole_speed="115200"
console="comconsole"

autoboot_delay="5"

verbose_loading="YES"
loader_logo="none"
beastie_disable="NO"

kern.geom.label.gptid.enable=0
hw.physmem=1073741824
# Da mehr als 1 igb NIC an Bord! Siehe man igb(4)
kern.ipc.nmbclusters=757350
hw.intrbalance=1
hw.em.max_interrupt_rate=16000
net.fibs=6

Re: r326734: serial console fails: boot stuck at: Consoles: internal video/keyboard

2017-12-09 Thread O. Hartmann 
Am Sat, 9 Dec 2017 13:00:12 -0700
Warner Losh  schrieb:

> On Sat, Dec 9, 2017 at 12:13 PM, Michael Tuexen  wrote:
> 
> > > On 9. Dec 2017, at 19:41, O. Hartmann  wrote:
> > >
> > > Running a PCengines APU2C4 with FreeBSD Current, r326734, fails to boot,  
> > it gets stuck at  
> > > the very first messages on the serial console prompting
> > >
> > > Consoles: internal video/keyboard
> > >
> > > and then nothing more.  
> > I don't think it is a general problem with r326734. I'm running on the
> > same hardware
> > that revision (with some modifications to the TCP I'm testing):  
> > > uname -a  
> > FreeBSD nf3.testbed 12.0-CURRENT FreeBSD 12.0-CURRENT #31 r326734M: Sat
> > Dec  9 20:03:59 CET 2017 tuexen@nf3.testbed:/usr/home/
> > tuexen/head/sys/amd64/compile/TCP  amd64
> >  
> 
> Hi Michael,
> 
> What's your boot setup? BIOS vs UEFI? UFS vs ZFS? GELI? GPT vs MBR? Plants
> vs Zombies? And did you update your boot blocks or not?
> 
> Warner

All right, I got your point here, my bad, my apaologies.

I boot from a NanoBSD-prepared image residing on a SD card. The partiton scheme 
is GPT,
non UEFI (the SeaBIOS, latest version available for the APU2C2 available) 
doesn't support
UEFI. NanoBSD scripts (legacy.sh) has been modified to fit our requests.

The modifications target at most the creation of a GPT partition scheme layout,
installing boot/pmbr as bootcode and boot/gptboot on a freebsd-boot partition 
as well as
boot/boot1.efifat onto a dedicated efi-type partition. The UEFI partition is 
usually
created before(!) the freebsd-boot partition, but in this specific version, 
there is NO
EFI partition, only the gptboot containing partition. The binaries of the above 
mentioned
bootcode/efi code images are taken from the newly build world. I do not use 
boot0sio, the
portion where it is installed is excluded by some "if GPT; then" clause.

The last known-good version I reported in working is the image I backuped last 
time. I
lost the USB 2.0 flash device today containing the last version, that was not 
far from
r326218, the version that corrupted FreeBSD, I guess it was r326184, but I 
really do not
know and I havn't a backup of that image.

The buildworld process is maintained by a bunch of WITHOUT_ statements in a 
file driving
NanoBSD. This just for the record just in case FreeBSD build system changed
something significantly.

Building a world takes 90 minutes or more, so bi-secting the problem would be a 
pain in
the arse (that said, I imply that world and kernel need to be in sync).

I would appreciate hints or tipps where to look after or how to increase 
verbosity
especially at the first boot stage.

The PCengines APU with the most recent SeaBIOS isn't capable of booting FreeBSD 
from USB
3.0 devices. Even from USB 2.0 flashdrives working images fail at the boot 
loader with
"failed with error 19".

> 
> 
> 
> > Best regards
> > Michael  
> > >
> > > FreeBSD CURRENT FreeBSD 12.0-CURRENT #52 r324234: Tue Oct  3 11:00:53  
> > CEST 2017 amd64  
> > > works fine.
> > >
> > > What the heck has changed?
> > >
> > > Kind regards,
> > >
> > > oh
> > >
> > > --
> > > O. Hartmann
> > >
> > > Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
> > > Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4  
> > BDSG).
> >
> > ___
> > 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"



-- 
O. Hartmann

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


pgpDlfhDGu0bc.pgp
Description: OpenPGP digital signature

Re: r326734: serial console fails: boot stuck at: Consoles: internal video/keyboard

2017-12-09 Thread Warner Losh 
On Sat, Dec 9, 2017 at 6:35 PM, O. Hartmann  wrote:

> Am Sat, 9 Dec 2017 14:30:38 -0700
> Warner Losh  schrieb:
>
> > On Sat, Dec 9, 2017 at 1:47 PM, O. Hartmann 
> wrote:
> >
> > > Am Sat, 9 Dec 2017 13:00:12 -0700
> > > Warner Losh  schrieb:
> > >
> > > > On Sat, Dec 9, 2017 at 12:13 PM, Michael Tuexen 
> > > wrote:
> > > >
> > > > > > On 9. Dec 2017, at 19:41, O. Hartmann 
> > > wrote:
> > > > > >
> > > > > > Running a PCengines APU2C4 with FreeBSD Current, r326734, fails
> to
> > > boot,
> > > > > it gets stuck at
> > > > > > the very first messages on the serial console prompting
> > > > > >
> > > > > > Consoles: internal video/keyboard
> > > > > >
> > > > > > and then nothing more.
> > > > > I don't think it is a general problem with r326734. I'm running on
> the
> > > > > same hardware
> > > > > that revision (with some modifications to the TCP I'm testing):
> > > > > > uname -a
> > > > > FreeBSD nf3.testbed 12.0-CURRENT FreeBSD 12.0-CURRENT #31
> r326734M: Sat
> > > > > Dec  9 20:03:59 CET 2017 tuexen@nf3.testbed:/usr/home/
> > > > > tuexen/head/sys/amd64/compile/TCP  amd64
> > > > >
> > > >
> > > > Hi Michael,
> > > >
> > > > What's your boot setup? BIOS vs UEFI? UFS vs ZFS? GELI? GPT vs MBR?
> > > Plants
> > > > vs Zombies? And did you update your boot blocks or not?
> > > >
> > > > Warner
> > >
> > > All right, I got your point here, my bad, my apaologies.
> > >
> > > I boot from a NanoBSD-prepared image residing on a SD card. The
> partiton
> > > scheme is GPT,
> > > non UEFI (the SeaBIOS, latest version available for the APU2C2
> available)
> > > doesn't support
> > > UEFI. NanoBSD scripts (legacy.sh) has been modified to fit our
> requests.
> > >
> > > The modifications target at most the creation of a GPT partition scheme
> > > layout,
> > > installing boot/pmbr as bootcode and boot/gptboot on a freebsd-boot
> > > partition as well as
> > > boot/boot1.efifat onto a dedicated efi-type partition. The UEFI
> partition
> > > is usually
> > > created before(!) the freebsd-boot partition, but in this specific
> > > version, there is NO
> > > EFI partition, only the gptboot containing partition. The binaries of
> the
> > > above mentioned
> > > bootcode/efi code images are taken from the newly build world. I do not
> > > use boot0sio, the
> > > portion where it is installed is excluded by some "if GPT; then"
> clause.
> > >
> > > The last known-good version I reported in working is the image I
> backuped
> > > last time. I
> > > lost the USB 2.0 flash device today containing the last version, that
> was
> > > not far from
> > > r326218, the version that corrupted FreeBSD, I guess it was r326184,
> but I
> > > really do not
> > > know and I havn't a backup of that image.
> > >
> > > The buildworld process is maintained by a bunch of WITHOUT_ statements
> in
> > > a file driving
> > > NanoBSD. This just for the record just in case FreeBSD build system
> changed
> > > something significantly.
> > >
> >
> > Should, but if you could share what those all are, I can tell you if any
> > might cause an issue that would help us root cause.
> >
> >
> > > Building a world takes 90 minutes or more, so bi-secting the problem
> would
> > > be a pain in
> > > the arse (that said, I imply that world and kernel need to be in sync).
> > >
> > > I would appreciate hints or tipps where to look after or how to
> increase
> > > verbosity
> > > especially at the first boot stage.
> > >
> >
> > OK. So you are booting with gptboot off an SD card on the PC Engines
> system
> > via legacy methods for a UFS root partition. GELI is not involved,
> correct?
>
> I do not use GELI. GEOM_GELI is in ther kernel compiled in. No modules are
> allowed to be
> loaded.
>
> The disk image created and mounted via md0 (mdconfig -a -t vndo -f
> filename.img) looks
> like:
>
> => 40  5175704  md0  GPT  (2.5G)
>40 10242  boot0  (512K)
>  1064  20594643  dsks1a  (1.0G)
>   2060528  20636434  dsks2a  (1.0G)
>   4124171  10485765  dsks3  (512M)
>   5172747 2997   - free -  (1.5M)
>
> This is the image type without UEFI partition, legacy boot only via
> gptboot.
>
> >
> > Sadly, there's no easy way to increase the verbosity of the early boot
> > since the boot blocks have to live in such a constrained environment
> > there's a strong bias against including debug code.
> >
> > But what we know is encouraging. We know that gptboot properly loaded,
> and
> > that it found /boot/loader, loaded it, and then we had the issue.  This
> > helps us constrain things somewhat in testing. For the moment, we'll
> assume
> > that gptboot is good, and concentrate on when /boot/loader went south.
> > Before we do that, can I get any loader.conf and /boot.config
> /boot/config
> > files you have?
>
> boot.config/loader.conf are non existent.
>
> [loader.conf.local]
> boot_serial="YES"
>

Re: GPTZFSBOOT in Current r326622 has problems

2017-12-09 Thread Thomas Laus 
Toomas Soome [tso...@me.com] wrote:
> 
> 
> With BIOS boot you can try to press key (space or anything else except enter) 
> - if boot1 is good, you will get boot: prompt.
>
BTX fails a long time before boot1 is read.  I don't even get a prompt
for my Geli password.

Tom

-- 
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF
___
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: GPTZFSBOOT in Current r326622 has problems

2017-12-09 Thread Thomas Laus 
Warner Losh [i...@bsdimp.com] wrote:
> OK. I don't recall seeing a screen shot of the entire boot. Can you send
> that too (privately if you like) so I know exactly what's failing? Is it
> gptzfsboot loading /boot/loader? Is it early in /boot/laoder or 
>
It is failing with a hex dump with a BTX halt even before I get
prompted for my Geli password.  I suspect that it fails while loading
gptzfsboot and even before /boot/loader is read.  I'll make a screen
shot but all it shows is a hex dump of all of the CPU registers with a
message at the bottom of the screen indicating BTX Halt.

Tom

-- 
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF
___
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: r326734: serial console fails: boot stuck at: Consoles: internal video/keyboard

2017-12-09 Thread Michael Tuexen 
> On 9. Dec 2017, at 21:00, Warner Losh  wrote:
> 
> 
> 
> On Sat, Dec 9, 2017 at 12:13 PM, Michael Tuexen  wrote:
> > On 9. Dec 2017, at 19:41, O. Hartmann  wrote:
> >
> > Running a PCengines APU2C4 with FreeBSD Current, r326734, fails to boot, it 
> > gets stuck at
> > the very first messages on the serial console prompting
> >
> > Consoles: internal video/keyboard
> >
> > and then nothing more.
> I don't think it is a general problem with r326734. I'm running on the same 
> hardware
> that revision (with some modifications to the TCP I'm testing):
> > uname -a
> FreeBSD nf3.testbed 12.0-CURRENT FreeBSD 12.0-CURRENT #31 r326734M: Sat Dec  
> 9 20:03:59 CET 2017 
> tuexen@nf3.testbed:/usr/home/tuexen/head/sys/amd64/compile/TCP  amd64
> 
> Hi Michael,
> 
> What's your boot setup? BIOS vs UEFI? UFS vs ZFS? GELI? GPT vs MBR? Plants vs 
> Zombies? And did you update your boot blocks or not?
I just do a "sudo make install" building the kernel the old way.

> gpart show
=>   40  250069600  ada0  GPT  (119G)
 40   1024 1  freebsd-boot  (512K)
   1064  241171456 2  freebsd-ufs  (115G)
  2411725208388608 3  freebsd-swap  (4.0G)
  249561128 508512- free -  (248M)

> gpart list
Geom name: ada0
modified: false
state: OK
fwheads: 16
fwsectors: 63
last: 250069639
first: 40
entries: 152
scheme: GPT
Providers:
1. Name: ada0p1
   Mediasize: 524288 (512K)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 20480
   Mode: r0w0e0
   efimedia: HD(1,GPT,2951bfd0-e406-11e5-a569-000db941ce18,0x28,0x400)
   rawuuid: 2951bfd0-e406-11e5-a569-000db941ce18
   rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f
   label: (null)
   length: 524288
   offset: 20480
   type: freebsd-boot
   index: 1
   end: 1063
   start: 40
2. Name: ada0p2
   Mediasize: 123479785472 (115G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 544768
   Mode: r1w1e1
   efimedia: HD(2,GPT,295310f8-e406-11e5-a569-000db941ce18,0x428,0xe5ffc00)
   rawuuid: 295310f8-e406-11e5-a569-000db941ce18
   rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b
   label: (null)
   length: 123479785472
   offset: 544768
   type: freebsd-ufs
   index: 2
   end: 241172519
   start: 1064
3. Name: ada0p3
   Mediasize: 4294967296 (4.0G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 3221245952
   Mode: r1w1e0
   efimedia: HD(3,GPT,2958486b-e406-11e5-a569-000db941ce18,0xe600028,0x80)
   rawuuid: 2958486b-e406-11e5-a569-000db941ce18
   rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b
   label: (null)
   length: 4294967296
   offset: 123480330240
   type: freebsd-swap
   index: 3
   end: 249561127
   start: 241172520
Consumers:
1. Name: ada0
   Mediasize: 128035676160 (119G)
   Sectorsize: 512
   Mode: r2w2e3

> 

I'm not using the internal SD card... Everything resides on the SSD.

Best regards
Michael
> 
> Warner
> 
>  
> Best regards
> Michael
> >
> > FreeBSD CURRENT FreeBSD 12.0-CURRENT #52 r324234: Tue Oct  3 11:00:53 CEST 
> > 2017 amd64
> > works fine.
> >
> > What the heck has changed?
> >
> > Kind regards,
> >
> > oh
> >
> > --
> > O. Hartmann
> >
> > Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
> > Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
> 
> ___
> 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: r326734: serial console fails: boot stuck at: Consoles: internal video/keyboard

2017-12-09 Thread Warner Losh 
On Sat, Dec 9, 2017 at 1:47 PM, O. Hartmann  wrote:

> Am Sat, 9 Dec 2017 13:00:12 -0700
> Warner Losh  schrieb:
>
> > On Sat, Dec 9, 2017 at 12:13 PM, Michael Tuexen 
> wrote:
> >
> > > > On 9. Dec 2017, at 19:41, O. Hartmann 
> wrote:
> > > >
> > > > Running a PCengines APU2C4 with FreeBSD Current, r326734, fails to
> boot,
> > > it gets stuck at
> > > > the very first messages on the serial console prompting
> > > >
> > > > Consoles: internal video/keyboard
> > > >
> > > > and then nothing more.
> > > I don't think it is a general problem with r326734. I'm running on the
> > > same hardware
> > > that revision (with some modifications to the TCP I'm testing):
> > > > uname -a
> > > FreeBSD nf3.testbed 12.0-CURRENT FreeBSD 12.0-CURRENT #31 r326734M: Sat
> > > Dec  9 20:03:59 CET 2017 tuexen@nf3.testbed:/usr/home/
> > > tuexen/head/sys/amd64/compile/TCP  amd64
> > >
> >
> > Hi Michael,
> >
> > What's your boot setup? BIOS vs UEFI? UFS vs ZFS? GELI? GPT vs MBR?
> Plants
> > vs Zombies? And did you update your boot blocks or not?
> >
> > Warner
>
> All right, I got your point here, my bad, my apaologies.
>
> I boot from a NanoBSD-prepared image residing on a SD card. The partiton
> scheme is GPT,
> non UEFI (the SeaBIOS, latest version available for the APU2C2 available)
> doesn't support
> UEFI. NanoBSD scripts (legacy.sh) has been modified to fit our requests.
>
> The modifications target at most the creation of a GPT partition scheme
> layout,
> installing boot/pmbr as bootcode and boot/gptboot on a freebsd-boot
> partition as well as
> boot/boot1.efifat onto a dedicated efi-type partition. The UEFI partition
> is usually
> created before(!) the freebsd-boot partition, but in this specific
> version, there is NO
> EFI partition, only the gptboot containing partition. The binaries of the
> above mentioned
> bootcode/efi code images are taken from the newly build world. I do not
> use boot0sio, the
> portion where it is installed is excluded by some "if GPT; then" clause.
>
> The last known-good version I reported in working is the image I backuped
> last time. I
> lost the USB 2.0 flash device today containing the last version, that was
> not far from
> r326218, the version that corrupted FreeBSD, I guess it was r326184, but I
> really do not
> know and I havn't a backup of that image.
>
> The buildworld process is maintained by a bunch of WITHOUT_ statements in
> a file driving
> NanoBSD. This just for the record just in case FreeBSD build system changed
> something significantly.
>

Should, but if you could share what those all are, I can tell you if any
might cause an issue that would help us root cause.


> Building a world takes 90 minutes or more, so bi-secting the problem would
> be a pain in
> the arse (that said, I imply that world and kernel need to be in sync).
>
> I would appreciate hints or tipps where to look after or how to increase
> verbosity
> especially at the first boot stage.
>

OK. So you are booting with gptboot off an SD card on the PC Engines system
via legacy methods for a UFS root partition. GELI is not involved, correct?

Sadly, there's no easy way to increase the verbosity of the early boot
since the boot blocks have to live in such a constrained environment
there's a strong bias against including debug code.

But what we know is encouraging. We know that gptboot properly loaded, and
that it found /boot/loader, loaded it, and then we had the issue.  This
helps us constrain things somewhat in testing. For the moment, we'll assume
that gptboot is good, and concentrate on when /boot/loader went south.
Before we do that, can I get any loader.conf and /boot.config /boot/config
files you have?

src/stand is easily buildable standalone these days, so my thought is
trying to build it at r326550 and putting that onto into your image.
src/stand stakes 1 minute to build on my box, so 5 on yours max :). You can
even build it standalone in a separate tree if that would help keep
whatever world you're using to do the builds purer. If we can't get
satisfaction doing that, then we'll drop back to plan B: if you give me all
the WITH/WITHOUT you are using, I could send you a tarball with about two
dozen /boot/loaders to try which should make bisecting not a total pain in
the arse. I'd likely toss in gptboot as well, since it's small. Let me know
:)

Since this is very early in /boot/loader's purview, I don't think
kernel/world matter at all (apart from the fact that loader is built as
part of world).

The PCengines APU with the most recent SeaBIOS isn't capable of booting
> FreeBSD from USB
> 3.0 devices. Even from USB 2.0 flashdrives working images fail at the boot
> loader with
> "failed with error 19".


OK. I assume this is a different issue. :)

Warner


> >
> >
> >
> > > Best regards
> > > Michael
> > > >
> > > > FreeBSD CURRENT FreeBSD 12.0-CURRENT #52 r324234: Tue Oct  3 11:00:53
> > > CEST 2017

Re: r326734: serial console fails: boot stuck at: Consoles: internal video/keyboard

2017-12-09 Thread Warner Losh 
On Sat, Dec 9, 2017 at 12:58 PM, Warner Losh  wrote:

>
>
> On Sat, Dec 9, 2017 at 12:04 PM, Ed Schouten  wrote:
>
>> 2017-12-09 19:41 GMT+01:00 O. Hartmann :
>> > r326734 fails to boot,
>> > r324234 works fine.
>> >
>> > What the heck has changed?
>>
>> Could you please try to bisect SVN revisions to figure out which exact
>> commit causes the problem?
>>
>
> I'd start with r326550.
>
> And are your sure it didn't boot / got stuck there, versus the output went
> someplace crazy because I broke reading in some obscure boot file
> accidentally :) Also, UEFI or BIOS boot? Any of ZFS, GELI or GPT vs MBR in
> play?
>

And did you update your boot blocks / files in UEFI partition or not?

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: r326734: serial console fails: boot stuck at: Consoles: internal video/keyboard

2017-12-09 Thread Warner Losh 
On Sat, Dec 9, 2017 at 12:13 PM, Michael Tuexen  wrote:

> > On 9. Dec 2017, at 19:41, O. Hartmann  wrote:
> >
> > Running a PCengines APU2C4 with FreeBSD Current, r326734, fails to boot,
> it gets stuck at
> > the very first messages on the serial console prompting
> >
> > Consoles: internal video/keyboard
> >
> > and then nothing more.
> I don't think it is a general problem with r326734. I'm running on the
> same hardware
> that revision (with some modifications to the TCP I'm testing):
> > uname -a
> FreeBSD nf3.testbed 12.0-CURRENT FreeBSD 12.0-CURRENT #31 r326734M: Sat
> Dec  9 20:03:59 CET 2017 tuexen@nf3.testbed:/usr/home/
> tuexen/head/sys/amd64/compile/TCP  amd64
>

Hi Michael,

What's your boot setup? BIOS vs UEFI? UFS vs ZFS? GELI? GPT vs MBR? Plants
vs Zombies? And did you update your boot blocks or not?

Warner



> Best regards
> Michael
> >
> > FreeBSD CURRENT FreeBSD 12.0-CURRENT #52 r324234: Tue Oct  3 11:00:53
> CEST 2017 amd64
> > works fine.
> >
> > What the heck has changed?
> >
> > Kind regards,
> >
> > oh
> >
> > --
> > O. Hartmann
> >
> > Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
> > Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4
> BDSG).
>
> ___
> 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: r326734: serial console fails: boot stuck at: Consoles: internal video/keyboard

2017-12-09 Thread Warner Losh 
On Sat, Dec 9, 2017 at 12:04 PM, Ed Schouten  wrote:

> 2017-12-09 19:41 GMT+01:00 O. Hartmann :
> > r326734 fails to boot,
> > r324234 works fine.
> >
> > What the heck has changed?
>
> Could you please try to bisect SVN revisions to figure out which exact
> commit causes the problem?
>

I'd start with r326550.

And are your sure it didn't boot / got stuck there, versus the output went
someplace crazy because I broke reading in some obscure boot file
accidentally :) Also, UEFI or BIOS boot? Any of ZFS, GELI or GPT vs MBR in
play?

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: GPTZFSBOOT in Current r326622 has problems

2017-12-09 Thread Toomas Soome 


> On 9 Dec 2017, at 19:56, Warner Losh  wrote:
> 
> On Sat, Dec 9, 2017 at 7:12 AM, Thomas Laus  wrote:
> 
>> On 12/08/17 22:06, Warner Losh wrote:
>>> 
>>> Clean build?
>>> 
>> It was a clean build.  I performed a rm -rf /usr/obj/* before starting
>> the buildworld after cvs updating to r326720.
>> 
>> A couple of notes on my hardware:
>> 
>> I am not using UEFI and my CPU is an early Intel i5 Skylake that has the
>> Silicon Debug flag turned on as a default.  Most operating systems
>> including FreeBSD turn off this flag during the boot process because of
>> security concerns.  Since BTX is very early in the boot process, the
>> computer is powered up with SDBG turned on.
> 
> 
> OK. I don't recall seeing a screen shot of the entire boot. Can you send
> that too (privately if you like) so I know exactly what's failing? Is it
> gptzfsboot loading /boot/loader? Is it early in /boot/laoder or 
> 

With BIOS boot you can try to press key (space or anything else except enter) - 
if boot1 is good, you will get boot: prompt.

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: r326734: serial console fails: boot stuck at: Consoles: internal video/keyboard

2017-12-09 Thread Michael Tuexen 
> On 9. Dec 2017, at 19:41, O. Hartmann  wrote:
> 
> Running a PCengines APU2C4 with FreeBSD Current, r326734, fails to boot, it 
> gets stuck at
> the very first messages on the serial console prompting
> 
> Consoles: internal video/keyboard
> 
> and then nothing more.
I don't think it is a general problem with r326734. I'm running on the same 
hardware
that revision (with some modifications to the TCP I'm testing):
> uname -a
FreeBSD nf3.testbed 12.0-CURRENT FreeBSD 12.0-CURRENT #31 r326734M: Sat Dec  9 
20:03:59 CET 2017 
tuexen@nf3.testbed:/usr/home/tuexen/head/sys/amd64/compile/TCP  amd64

Best regards
Michael
> 
> FreeBSD CURRENT FreeBSD 12.0-CURRENT #52 r324234: Tue Oct  3 11:00:53 CEST 
> 2017 amd64
> works fine.
> 
> What the heck has changed?
> 
> Kind regards,
> 
> oh
> 
> -- 
> O. Hartmann
> 
> Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
> Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).

___
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: r326734: serial console fails: boot stuck at: Consoles: internal video/keyboard

2017-12-09 Thread Ed Schouten 
2017-12-09 19:41 GMT+01:00 O. Hartmann :
> r326734 fails to boot,
> r324234 works fine.
>
> What the heck has changed?

Could you please try to bisect SVN revisions to figure out which exact
commit causes the problem?

-- 
Ed Schouten 
Nuxi, 's-Hertogenbosch, the Netherlands
___
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"

r326734: serial console fails: boot stuck at: Consoles: internal video/keyboard

2017-12-09 Thread O. Hartmann 
Running a PCengines APU2C4 with FreeBSD Current, r326734, fails to boot, it 
gets stuck at
the very first messages on the serial console prompting

Consoles: internal video/keyboard

and then nothing more.

FreeBSD CURRENT FreeBSD 12.0-CURRENT #52 r324234: Tue Oct  3 11:00:53 CEST 2017 
amd64
works fine.

What the heck has changed?

Kind regards,

oh

-- 
O. Hartmann

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


pgpMI8q26QR8w.pgp
Description: OpenPGP digital signature

Re: GPTZFSBOOT in Current r326622 has problems

2017-12-09 Thread Warner Losh 
On Sat, Dec 9, 2017 at 7:12 AM, Thomas Laus  wrote:

> On 12/08/17 22:06, Warner Losh wrote:
> >
> > Clean build?
> >
> It was a clean build.  I performed a rm -rf /usr/obj/* before starting
> the buildworld after cvs updating to r326720.
>
> A couple of notes on my hardware:
>
> I am not using UEFI and my CPU is an early Intel i5 Skylake that has the
> Silicon Debug flag turned on as a default.  Most operating systems
> including FreeBSD turn off this flag during the boot process because of
> security concerns.  Since BTX is very early in the boot process, the
> computer is powered up with SDBG turned on.


OK. I don't recall seeing a screen shot of the entire boot. Can you send
that too (privately if you like) so I know exactly what's failing? Is it
gptzfsboot loading /boot/loader? Is it early in /boot/laoder or 

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: reducing build times; selecting specific clang targets

2017-12-09 Thread Pedro Giffuni 

Just my $0.02:



On 12/09/17 02:50, Ed Schouten wrote:
> Hi Michael,
> 
> 2017-12-09 4:57 GMT+01:00 Michael Butler :

>> As clang builds for multiple targets unconditionally, it takes *days* to
>> build on one of my devices (700MHz Pentium-3).
>>
>> Is there a way to restrict the build targets to i386 only? If not, can we
>> implement one?
> 
> Regardless of the discussion of how and whether this may be

> implemented, do take into consideration that the target specific bits
> in Clang only account for a minority of the build time. It is not as
> if Clang is literally built multiple times, once for every
> architecture. The build will likely still take several days, even if
> this got fixed.
> 
> Have you considered doing builds on some other system and copying the

> results over? According to Wikipedia, they stopped producing Pentium
> III CPUs 14 years ago. Using these systems to do actual builds sounds
> like a waste of electricity.
> 


Far less than the electricity consumed by an entire planet's worth of
BSD systems building for targets they'll never use.

The target system is in a remote data-center to which I have limited
access and is the only remaining one of its type in my network. The old
installer used to be able to select a set of source archives from which
to update but I don't see that functionality in any of the current
tools. What did I miss?


freebsd-update(8)

pkg upgrade

that would mean running a release, but it makes life so much easier.

Cheers,

Pedro.

___
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: GPTZFSBOOT in Current r326622 has problems

2017-12-09 Thread Thomas Laus 
On 12/08/17 22:06, Warner Losh wrote:
> Clean build?
>
Here is the contents of my loader.conf:

loader_logo="beastie" #Desired logo:orbbw, orb, fbsdbw, beastiebw, beastie, none
aesni_load="YES"
geom_eli_load="YES"
kern.geom.label.disk_ident.enable="0"
kern.geom.label.gptid.enable="0"
zfs_load="YES"

Tom

-- 
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF
___
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: GPTZFSBOOT in Current r326622 has problems

2017-12-09 Thread Thomas Laus 
On 12/08/17 22:06, Warner Losh wrote:
> 
> Clean build?
>
It was a clean build.  I performed a rm -rf /usr/obj/* before starting
the buildworld after cvs updating to r326720.

A couple of notes on my hardware:

I am not using UEFI and my CPU is an early Intel i5 Skylake that has the
Silicon Debug flag turned on as a default.  Most operating systems
including FreeBSD turn off this flag during the boot process because of
security concerns.  Since BTX is very early in the boot process, the
computer is powered up with SDBG turned on.

Tom


-- 
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF
___
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: reducing build times; selecting specific clang targets

2017-12-09 Thread Michael Butler 

On 12/09/17 02:50, Ed Schouten wrote:

Hi Michael,

2017-12-09 4:57 GMT+01:00 Michael Butler :

As clang builds for multiple targets unconditionally, it takes *days* to
build on one of my devices (700MHz Pentium-3).

Is there a way to restrict the build targets to i386 only? If not, can we
implement one?


Regardless of the discussion of how and whether this may be
implemented, do take into consideration that the target specific bits
in Clang only account for a minority of the build time. It is not as
if Clang is literally built multiple times, once for every
architecture. The build will likely still take several days, even if
this got fixed.

Have you considered doing builds on some other system and copying the
results over? According to Wikipedia, they stopped producing Pentium
III CPUs 14 years ago. Using these systems to do actual builds sounds
like a waste of electricity.



Far less than the electricity consumed by an entire planet's worth of 
BSD systems building for targets they'll never use.


The target system is in a remote data-center to which I have limited 
access and is the only remaining one of its type in my network. The old 
installer used to be able to select a set of source archives from which 
to update but I don't see that functionality in any of the current 
tools. What did I miss?


imb

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