Hi Andrew at 19.09.2014 20:39, Andrew wrote: > 19.09.2014 15:04, Erich Titl пишет: >> Hi >> >> at 19.09.2014 10:35, kp kirchdoerfer wrote: >>> Am Donnerstag, 18. September 2014, 18:59:40 schrieb Timothy Wegner: >>>> David wrote: >>>> >>>> >> ... >> >>> Most probably it's the ehci-pci module (ehci-pci.ko.gz) which is missing. It >>> is needed with the newer kernel in 5.1. >>> You may add it grom the modules tarball to initmod.lrp. >>> >>> See >>> http://bering-uclibc.zetam.org/wiki/Bering-uClibc_5.x_-_User_Guide_-_Advanced_Topics_-_Modifying_initrd.lrp >>> >>> how to modify initmod.lrp (It's written for initrd, but it's also valid for >>> initmod). >> For what it's worth, I never understood the rationale behind splitting >> initrd, except for a few cycles on the server building it. It makes life >> miserable for anyone using a boot loader which does not support multiple >> initrd files. It probably needs more space for initrd storage and makes >> debugging more difficult. I vote to go back to single initrd files. >> >> cheers >> >> Erich > It's for 1) completely separating userland from kernel - that will allow > us to maintaindifferent kernel branches in single release and
I don't understand this statement, modules are not userland. 2) for > embedded platforms where there is a single userland for arch, and > multiple kernels (even with different versions - if there is a > proprietary patch w/o ports to other versions, and even w/o boot-time > modules for some platforms - if there is a fixed configuration of > boot-time modules, they may be linked into kernel as static). If we had that there would be no need for initmod. > Also it helps to easily update userspace w/o kernel or kernel w/o > userspace (they are almost independent now). As they should be.... but I iterate here, modules are not userland ( I have been made aware of this on this proper list ;-) > If loader doesn't support multiple initrd, 2 pieces can be easily > concatenated into one w/o repacking. I understand the idea of separating the kernel from userland, but modules are alway kernel dependent. Even building multiple different self contained initrd for single kernels are no problem as we have a initrd build procedure which may very well build multiple different architecture initrd files. As you say, as they are cpio archives they can easily be put together, so why not just do it. The missing module(s) in this case thread is probably not due to separation, just porting to different boot loaders may be an issue here. cheers Erich > > ------------------------------------------------------------------------------ > Slashdot TV. Video for Nerds. Stuff that Matters. > http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk > ------------------------------------------------------------------------ > leaf-user mailing list: leaf-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/leaf-user > Support Request -- http://leaf-project.org/ > ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk ------------------------------------------------------------------------ leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
