David C. Rankin wrote:
On 04/07/2017 05:34 PM, L A Walsh wrote:
The key, as you correctly point out, is much of the early boot relies on files in /usr[64], so the kernel needs to know where everything is at the time of the kernel load.
Not exactly... The kernel doesn't use /usr/lib64. It's modules are in /lib/modules. It's not the kernel that has a problem booting, it's the system-bring-up that follows -- thinks like "mount" which had its libs moved to /usr/lib64. I was so impressed with that the first time I booted and nothing would mount because the lib needed to mount things was not mounted yet. So **brilliant** ;^/! That's why in the old sysVinit, they had a 'boot.d' to bring up all the system HW, then it turned over to run-level 3 or 5 (rc3.d or rc5.d) to bring up the system-services (running in user-land). The system-services and the bringing up extra HW in boot.d are NOT really part of the kernel. The "boot.d" tasks did things like mounting hard disks and making sure network modules were loaded and config'ed. **Maybe**, some of the stuff in boot.d might require loading another kernel module -- but that comes from /lib/modules. I do the equivalent of a wicked-config of the linux kernel, so my needed HW drivers get built into a kernel. Opensuse could dynamically rebuild the kernel the same way they rebuild an initrd using a cherry-picking program like wicked. Then users could boot just using a kernel instead of an initrd. Unix OEM's used to provide such scripts back in 90's to customers who wanted less downtime and faster booting. They customers ran the scripts which built the kernel for their HW, and that was it (ramdisks weren't an option back then). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org