Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 9 Dec 2017 19:10:03 -0700
From:      Warner Losh <imp@bsdimp.com>
To:        "O. Hartmann" <o.hartmann@walstatt.org>
Cc:        Michael Tuexen <tuexen@freebsd.org>, "O. Hartmann" <ohartmann@walstatt.org>, FreeBSD CURRENT <freebsd-current@freebsd.org>
Subject:   Re: r326734: serial console fails: boot stuck at: Consoles: internal video/keyboard
Message-ID:  <CANCZdfrTXaseRS_5gq2YxJmb6tvjw3OVPEgtyCko0gb-jZ8-Yg@mail.gmail.com>
In-Reply-To: <20171210023503.6d8e02b3@thor.intern.walstatt.dynvpn.de>
References:  <20171209194129.53977a63@thor.intern.walstatt.dynvpn.de> <728FB521-24EE-4628-9816-EB3DF0ACA14E@freebsd.org> <CANCZdfrfy5biQnOV16RwQ3m=hfKzbvznGZ=p=3-GbhP27AZ0Ug@mail.gmail.com> <20171209214746.1debb72e@thor.intern.walstatt.dynvpn.de> <CANCZdfpM-Y_dU8T-F7DRrLnd9JzkHLisALKnGwGKonwozB%2B8Pg@mail.gmail.com> <20171210023503.6d8e02b3@thor.intern.walstatt.dynvpn.de>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Dec 9, 2017 at 6:35 PM, O. Hartmann <o.hartmann@walstatt.org> wrote=
:

> Am Sat, 9 Dec 2017 14:30:38 -0700
> Warner Losh <imp@bsdimp.com> schrieb:
>
> > On Sat, Dec 9, 2017 at 1:47 PM, O. Hartmann <o.hartmann@walstatt.org>
> wrote:
> >
> > > Am Sat, 9 Dec 2017 13:00:12 -0700
> > > Warner Losh <imp@bsdimp.com> schrieb:
> > >
> > > > On Sat, Dec 9, 2017 at 12:13 PM, Michael Tuexen <tuexen@freebsd.org=
>
> > > wrote:
> > > >
> > > > > > On 9. Dec 2017, at 19:41, O. Hartmann <ohartmann@walstatt.org>
> > > 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 o=
n
> 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 sche=
me
> > > 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 n=
ot
> > > 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_ statement=
s
> 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 an=
y
> > 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 ar=
e
> allowed to be
> loaded.
>
> The disk image created and mounted via md0 (mdconfig -a -t vndo -f
> filename.img) looks
> like:
>
> =3D>     40  5175704  md0  GPT  (2.5G)
>        40     1024    2  boot0  (512K)
>      1064  2059464    3  dsks1a  (1.0G)
>   2060528  2063643    4  dsks2a  (1.0G)
>   4124171  1048576    5  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=3D"YES"
> comconsole_speed=3D"115200"
> console=3D"comconsole"
>
> autoboot_delay=3D"5"
>
> verbose_loading=3D"YES"
> loader_logo=3D"none"
> beastie_disable=3D"NO"
>
> kern.geom.label.gptid.enable=3D0
> hw.physmem=3D1073741824
> # Da mehr als 1 igb NIC an Bord! Siehe man igb(4)
> kern.ipc.nmbclusters=3D757350
> hw.intrbalance=3D1
> hw.em.max_interrupt_rate=3D16000
> net.fibs=3D6
> net.add_addr_allfibs=3D0


Thanks! This is about what I'd expect, but in these weird things it's
always good to be explicit...

> 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 t=
wo
> > 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
> > :)
>
> Well, that is a kind offer, thanks. Tomorrow morning, I'll try r326550.
> For now, I spent
> too much  time trying to rid of this.
>

I'm with you on this. I'm just trying to figure out what, exactly, I need
to try to setup since this isn't quite my env.

So you don't load GELI since you have it in your kernel. Does this mean
that gptboot loading from a GELI partition?

Warner



> Kind regards,
>
> Oliver
>
> >
> > 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 amd64
> > > > > > works fine.
> > > > > >
> > > > > > What the heck has changed?
> > > > > >
> > > > > > Kind regards,
> > > > > >
> > > > > > oh
> > > > > >
> > > > > > --
> > > > > > O. Hartmann
> > > > > >
> > > > > > Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Date=
n f=C3=BCr
> > > > > > Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=
=C2=A7 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-unsubscribe@
> > > freebsd.org"
> > > > >
> > > > _______________________________________________
> > > > freebsd-current@freebsd.org mailing list
> > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@
> > > freebsd.org"
> > >
> > >
> > >
> > > --
> > > O. Hartmann
> > >
> > > Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=
=BCr
> > > Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 2=
8 Abs. 4
> BDSG).
> > >
>
>
>
> --
> O. Hartmann
>
> Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=BCr
> Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Ab=
s. 4 BDSG).
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrTXaseRS_5gq2YxJmb6tvjw3OVPEgtyCko0gb-jZ8-Yg>