On Thu, Nov 21, 2019 at 4:48 AM Eugene Grosbein <eu...@grosbein.net> wrote: > > 21.11.2019 17:22, Bjoern A. Zeeb wrote: > > > On 21 Nov 2019, at 9:51, Eugene Grosbein wrote: > > > >> Hi! > >> > >> How do I get boot messages generated by loader itself written to some log > >> after successfull boot? > >> This is generic BIOS-based 11.3-STABLE/amd64 system with syscons console > >> driver. > >> > >> /var/run/dmesg.boot starts with kernel messages without previous lines > >> from the loader. > >> Specifically, I need messages about loading kernel modules with full paths. > > > > loader cannot write to the kernel message buffer as there is no kernel yet. > > There might be possible ways to preserve that but I doubt loader is fit > > for that task. > > Some hardware does not clear memory while warm booting, so KDB trace from > previous panic sometimes survive reboot > and ends up in /var/run/dmesg.boot for successful boot. I wonder why loader > messages cannot be there, too. > In fact, kernel message buffer can be found even in absence of kernel :-) > > I've already searched through the sources in stand/ and see there is no code > to support this yet. > > > A boot -v (boot_verbose=“YES”) might spit the information out from the > > kernel as well. Not sure if that helps you. However on modern server > > machines a boot -v often overflows the message buffer.. so you might have > > to tune that as well. > > > > Extracted from an older console log of a random lab machine of someone else: > > .. > > WARNING: WITNESS option enabled, expect reduced performance.^M^@ > > WARNING: DIAGNOSTIC option enabled, expect reduced performance.^M^@ > > Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff80e66000.^M^@ > > Preloaded elf obj module "/boot/kernel/if_igb.ko" at 0xffffffff80e66968.^M^@ > > Preloaded elf obj module "/boot/kernel/nfscl.ko" at 0xffffffff80e66fd0.^M^@ > > Preloaded elf obj module "/boot/kernel/nfslock.ko" at > > 0xffffffff80e67638.^M^@ > > Preloaded elf obj module "/boot/kernel/nfssvc.ko" at 0xffffffff80e67ba0.^M^@ > > Preloaded elf obj module "/boot/kernel/krpc.ko" at 0xffffffff80e68088.^M^@ > > Preloaded elf obj module "/boot/kernel/nfscommon.ko" at > > 0xffffffff80e686b0.^M^@ > > Preloaded elf obj module "/boot/kernel/ahci.ko" at 0xffffffff80e68d20.^M^@ > > Preloaded elf obj module "/boot/kernel/cam.ko" at 0xffffffff80e69308.^M^@ > > Preloaded elf obj module "/boot/kernel/mfi.ko" at 0xffffffff80e699f0.^M^@ > > Preloaded elf obj module "/boot/kernel/geom_part_gpt.ko" at > > 0xffffffff80e6a058.^M^@ > > Preloaded elf obj module "/boot/kernel/sysvsem.ko" at > > 0xffffffff80e6a648.^M^@ > > Preloaded elf obj module "/boot/kernel/sysvshm.ko" at > > 0xffffffff80e6acb0.^M^@ > > Calibrating TSC clock ... TSC clock: 3400185886 Hz^M^@ > > CPU: Intel(R) Xeon(R) CPU X5272 @ 3.40GHz (3400.19-MHz K8-class > > CPU)^M^@ > > Yes, but this only shows results of loader's work and kldstat -v shows paths > too. > I need to know why changing modules_path in the nextboot.conf does not work > and why does loader uses stock zfs.ko insted of my patched version > /boot/nextboot/zfs.ko > if I use nextboot.conf with > module_path="/boot/nextboot;/boot/kernel;/boot/modules" > >
I pointed this out on IRC, but for list's sake: for something like this, it's good to verify module_path that loader used by inspecting kenv. This is my guess at the output: $ kenv module_path /boot/kernel;/boot/nextboot;/boot/kernel;/boot/modules With lualoader, it would be slightly different as we go through the cosmetic exercise of removing the loaded kernel path from the middle of module_path if it's there. Both 4th and lua will prepend the kernel path to module_path once the kernel's loaded, which should always happen after nextboot processing. For anyone else doing the same, the best option here would likely be fully qualifying the module names for every module you want out of a separate path: zfs_name="/boot/nextboot/zfs.ko" This should/will work with both 4thloader and lualoader. It's not ideal for general configuration, but if you're doing a one-off load of a module in loader it works. _______________________________________________ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
