Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 10 Dec 2017 02:35:03 +0100
From:      "O. Hartmann" <o.hartmann@walstatt.org>
To:        Warner Losh <imp@bsdimp.com>
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:  <20171210023503.6d8e02b3@thor.intern.walstatt.dynvpn.de>
In-Reply-To: <CANCZdfpM-Y_dU8T-F7DRrLnd9JzkHLisALKnGwGKonwozB%2B8Pg@mail.gmail.com>
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>

next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/_7FdIqd=XeBdf5_wWJbqJ0u
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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> wro=
te:
>=20
> > Am Sat, 9 Dec 2017 13:00:12 -0700
> > Warner Losh <imp@bsdimp.com> schrieb:
> > =20
> > > On Sat, Dec 9, 2017 at 12:13 PM, Michael Tuexen <tuexen@freebsd.org> =
=20
> > wrote: =20
> > > =20
> > > > > On 9. Dec 2017, at 19:41, O. Hartmann <ohartmann@walstatt.org> =20
> > wrote: =20
> > > > >
> > > > > Running a PCengines APU2C4 with FreeBSD Current, r326734, fails t=
o =20
> > boot, =20
> > > > it gets stuck at =20
> > > > > the very first messages on the serial console prompting
> > > > >
> > > > > Consoles: internal video/keyboard
> > > > >
> > > > > and then nothing more. =20
> > > > 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): =20
> > > > > uname -a =20
> > > > 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
> > > > =20
> > >
> > > Hi Michael,
> > >
> > > What's your boot setup? BIOS vs UEFI? UFS vs ZFS? GELI? GPT vs MBR? =
=20
> > Plants =20
> > > vs Zombies? And did you update your boot blocks or not?
> > >
> > > Warner =20
> >
> > 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 availabl=
e)
> > 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 partiti=
on
> > 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 t=
he
> > 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 backup=
ed
> > last time. I
> > lost the USB 2.0 flash device today containing the last version, that w=
as
> > not far from
> > r326218, the version that corrupted FreeBSD, I guess it was r326184, bu=
t 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 cha=
nged
> > something significantly.
> > =20
>=20
> 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.
>=20
>=20
> > Building a world takes 90 minutes or more, so bi-secting the problem wo=
uld
> > 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.
> > =20
>=20
> OK. So you are booting with gptboot off an SD card on the PC Engines syst=
em
> via legacy methods for a UFS root partition. GELI is not involved, correc=
t?

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:

=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.

>=20
> 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.
>=20
> 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 assu=
me
> 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

>=20
> 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 c=
an
> 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 a=
ll
> 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 kn=
ow
> :)

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.

Kind regards,

Oliver

>=20
> 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).
>=20
> 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 b=
oot
> > loader with
> > "failed with error 19". =20
>=20
>=20
> OK. I assume this is a different issue. :)
>=20
> Warner
>=20
>=20
> > >
> > >
> > > =20
> > > > Best regards
> > > > Michael =20
> > > > >
> > > > > FreeBSD CURRENT FreeBSD 12.0-CURRENT #52 r324234: Tue Oct  3 11:0=
0:53 =20
> > > > CEST 2017 amd64 =20
> > > > > works fine.
> > > > >
> > > > > What the heck has changed?
> > > > >
> > > > > Kind regards,
> > > > >
> > > > > oh
> > > > >
> > > > > --
> > > > > 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 Abs. 4 =20
> > > > BDSG).
> > > >
> > > > _______________________________________________
> > > > freebsd-current@freebsd.org mailing list
> > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@ =20
> > freebsd.org" =20
> > > > =20
> > > _______________________________________________
> > > freebsd-current@freebsd.org mailing list
> > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@ =20
> > 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 28 =
Abs. 4 BDSG).
> > =20



--=20
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 Abs.=
 4 BDSG).

--Sig_/_7FdIqd=XeBdf5_wWJbqJ0u
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWiyPRwAKCRDS528fyFhY
lIveAf9Lnv1D/mqhs6LiaHu1azCv4fF21LVcc2bhwEz4Qcul1/pJOtnR1U+85S1k
Q+p0THIeagWCOUndlGTxNkukiRMFAgCY2nfHuI1NXhs/vG0Uoj12x1lxtdxzSKc/
hnwZUQXyFVVBI0k/riMZweqntC0hyw04vYgUJ4u8FCl9eUAUBzXn
=UNvD
-----END PGP SIGNATURE-----

--Sig_/_7FdIqd=XeBdf5_wWJbqJ0u--



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