Hi, and thanks for the change - I have a few concerns though, as found below.
On 04/26/15 23:37, matthew green wrote: > Module Name: src > Committed By: mrg > Date: Sun Apr 26 21:37:22 UTC 2015 > > Modified Files: > src/distrib/sets: mkvars.mk > src/distrib/sets/lists/base: mi > src/etc/mtree: NetBSD.dist.base > src/share/mk: bsd.README bsd.own.mk > src/sys/dev/microcode/radeon: Makefile > > Log Message: > two changes to radeon drm firmware: > - only install it by default on x86, set new MKRADEONFIRMWARE variable > - install in /libdata, so that separate /usr systems work This will probably still fail on a system with the root filesystem encrypted, as setup with cgdroot.kmod: /etc/rc from the ramdisk first sets the "init.root" sysctl to the actual /, and only then init chroots there and executes. Even then the "hw.firmware.path" sysctl is relative to the ramdisk, so unless its value is updated no firmware will be found on the system. This could be done by cgdroot.kmod though, and I can write a patch for this if it sounds good. But again, the firmware will not be found initially... > (this still doesn't solve PR#49811, which possibly could be handled by > having them being a kernel module loaded by /boot.) I think the problem is similar there. When booting with -a I guess boot(8) will try to load modules from the same partition as the kernel itself, which may not be the correct one (since -a is used). Even worse is when booting Xen, as I don't think boot(8) is able to load modules at all in this case; they are supported once the root filesystem is mounted though. >From all of this I feel that the real fix will involve the ability to load any firmware past init; config_mountroot(9) is not waiting long enough for instance (same issue with iwm(4), which uses it). To make things easier, I am writing this while running Xen with root filesystem encryption :) Cheers, -- khorben
