Discussion:
bsd.rd fails to boot up on libreboot x200: how to find out why?
s***@openmailbox.org
2016-04-07 16:48:44 UTC
Permalink
I have a Thinkpad X200 laptop with libreboot 20150518 (latest stable
release).

Libreboot is basically coreboot + grub2 without bios services and with
no text console.

GRUB is able to load openbsd kernels from all filesystems it knows
including FFS.

If I load 5.9/amd64/bsd or bsd.mp kernels they boot up fine to the
console, giving this warning in early boot up:
warning: no entropy supplied by boot loader
It is not unexpected, since GRUB does not support providing entropy to
the bsd kernel yet.

But if I try to load /bsd (is it a kernel at all? seems to be gzip
archive with some elf) or /5.9/amd64/bsd.rd kernels, they do not boot
up. After several seconds the machine reboots without any messages on
the screen at all and grub menu reappears.

I have also tested i386 kernels (rd and mp). They do not make machine
reboot but do not show anything either. Perhaps they were built without
framebuffer support. Possibly they work under hood, but I need to make
them use usb serial console to check it.

Since I see nothing on the screen and the laptop has no hardware com
port, I have decided to try with USB-serial adapter. The adapter works
with OpenBSD after full boot if I issue cd /dev ; sh MAKEDEV ttyU0, but
I do not know how to specify it to the kernel to use for debug. GRUB
allows to specify only com0 - com3 as serial console in the command
line. If I specify kopenbsd -h com0 option nothing is sent to the port
even with working kernels.

Is it possible at all to use USB serial port as console?

Do you have any idea, what is difference between bsd.rd and bsd kernels
that the first one does not start at all on same machine?

Do I have any feasible options to get serial console to this laptop?

I think that if I unpack bsd.rd and edit /etc/ttys it might help, but I
did not find any information about bsd.rd structure, such as supposed
offset of embedded image, its format and so on.

elfrdsetroot(8) is mentioned in man rd, but http://man.openbsd.org does
not have a manpage for it.
Stuart Henderson
2016-04-08 08:45:40 UTC
Permalink
Post by s***@openmailbox.org
I have a Thinkpad X200 laptop with libreboot 20150518 (latest stable
release).
Libreboot is basically coreboot + grub2 without bios services and with
no text console.
and without CPU microcode updates that may fix important, maybe security-
related, bugs.
Post by s***@openmailbox.org
But if I try to load /bsd (is it a kernel at all? seems to be gzip
archive with some elf) or /5.9/amd64/bsd.rd kernels, they do not boot
up. After several seconds the machine reboots without any messages on
the screen at all and grub menu reappears.
It's just a gzipped kernel, the normal boot loader supports these directly.
You could try gunzipping it and see if you get further but the lack of
text console probably won't help you.
Post by s***@openmailbox.org
Is it possible at all to use USB serial port as console?
No.
Post by s***@openmailbox.org
Do I have any feasible options to get serial console to this laptop?
Unlikely.
Post by s***@openmailbox.org
I think that if I unpack bsd.rd and edit /etc/ttys it might help, but I
did not find any information about bsd.rd structure, such as supposed
offset of embedded image, its format and so on.
elfrdsetroot(8) is mentioned in man rd, but http://man.openbsd.org does
not have a manpage for it.
It doesn't mention it with a manpage section number, just as "the
elfrdsetroot tool" - it can be built like this:

cd /usr/src/distrib/common && \
cc -o rdsetroot elf32.c elf64.c elfrdsetroot.c

rdsetroot -x /path/to/bsd.rd /tmp/ramdisk.image
vnconfig vnd0 /tmp/ramdisk.image
mount /dev/vnd0a /mnt
...
umount /mnt
vnconfig -u vnd0
rdsetroot /path/to/bsd.rd /tmp/ramdisk.image

/etc/ttys only helps when multi-user, it doesn't affect kernel
console or single-user mode. But in the "..." stage you can create
/mnt/auto_install.conf to run the installer (or auto_upgrade.conf for
the updater), see autoinstall(8), which may get you somewhere.

Loading...