Re: [OSR-devel] initrd cleanup

[Gordan B. <go...@bo...>]

>>>>>>>> I'm figuring that just adding rm -rf /lib/modules would help. I have
>>>>>>>> just added this to clean_initrd function. I'll have a look at what
>>>>>>>> else can be pruned after the GFS root is mounted.
>>>>>>>
>>>>>>> Hmm, this doesn't appear to have worked. I think it happens too late.
>>>>>>> I'd need to delete these before the new chroot is fired up. Any
>>>>>>> suggestion on where would be a good time to put this?
>>>>>>
>>>>>> The chroot environment is builded in
>>>>>> etc/rhel{4,5}/boot-lib.sh:create_chroot() There might be a more
>>>>>> intelligent way to create the chroot environment ;-)
>>>>>
>>>>> I think there may be a path issue here. What is the absolute path of
>>>>> /lib/modules in the initrd? I told it to mv /lib/modules /lib/modules2,
>>>>> and this doesn't appear to have happened in either the initrd nor in the
>>>>> real GFS root. :-/
>>>>
>>>> during the initrd init process, a new chroot environment is build to hold
>>>> the cluster services itsself. This has to be done to solve the
>>>> chicken-egg problem with rootfs depending on userspace cluster services.
>>>>
>>>> The new chroot environment ist created in the function create_chroot.
>>>> The default path for the chroot environment is /var/comoonics/chroot.
>>>
>>> Does that mean the /lib/modules, even during the initrd boot sequence,
>>> live under /var/comoonics/chroot/lib/modules?
>>
>> Yes.
>
> Well, adding:
> mv /var/comoonics/chroot/lib/modules /var/comoonics/chroot/lib/modules2
> didn't rename the folder. I give up.

I just had a different idea - if we are making the initrd of the current 
system (as we will be in most cases), how about just bundling the modules 
currently loaded (from lsmod)? That way we could inly include the drivers 
that are required from the /lib/modules tree, rather than everything. If 
something isn't loaded once the system is fully booted up, then the 
chances are that it isn't needed to get the system that far.

Gordan