20.09.2014 14:07, Erich Titl пишет: > 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. Right. Modules aren't userland. So modules are splitted from userland initrd.
> > 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. Right. For one platform. Another platform with same arch (for ex., ARMv7) can be booted from SD card/USB - and will have modules (because USB drives aren't necessary). So it'll be good to have universal initrd, and initmods for different platforms (if they are needed). > >> 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. Right, and they are also separated from userland. Now you can just place kernel with initmod and moddb.lrp/modules.tgz into your distro - and voila, you have old stable userland with bleeding-edge kernel. > 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. cpio is useful for x86; for embedded with on-board flash - we even may use squashfs with tmpfs on top (for saving valuable RAM). I think this will be done in 5.2. Also, almost all boot loaders suport multiple ramdisks. So I don't think that it's actual trouble. > 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/
