Re: [OSR-devel] initrd dieting coreutils vs. busybox

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

Marc Grimme wrote:

>>> Hm. I like that awk, grep, etc are going with busybox on the one
>> hand.
>>> That would make things easier. I'll think about that.
>> OK. I'm more than happy to help with the testing/implementation of
>> this. As far as I can tell, all that would be required is creating the 
>> symlinks - doable with something like:
>>
>> ./busybox --help |\
>> grep 'Currently defined functions:' -A30 \
>> | grep '^\s.*,' \
>> | tr , '\n' \
>> | xargs -n1 -i{} ln -s busybox {}
>>
>> (that's off the top of my head, don't quote me on it, and -A30 may be
>> too low)
>>
>> and pruning out the packages that are made redundant by it. If taking
>> it to the extreme and dropping bash as well, then all the shell scripts 
>> would need to be checked to reference /bin/sh instead if /bin/bash,
>> and they'd need testing to make sure that they aren't broken by some bash
>> vs. sh obscurity.
> Right. But that's much work.
> There are many bash deps inside the code. I'm currently cleaning it
> up a little bit. But I don't see to get rid of bash in near time.

Are there really that many bash specific extensions in use in there that 
aren't supported by vanilla bourne sh?

> As we are also going to support dracut as initrd for future clusters -
> on distros where it will be available (FC12, RHEL6, SLES???) - all this
> done there. They are using dash (posix shell). Currently we did not port
> the cluster filesystem parts but NFS to dracut.

Interesting. I didn't realize there was such a major change introduced 
recently into the way initrd works.

> So bottomline is we'll stay with bash in bootscripts as it's too much
> work to move so far. Especially when I expect dracut to overpower our
> initrd.

Indeed, I see where you're going with this. It does sound like cometh 
FC13/RHEL6 it may be time for a major change. And that puts a limit on 
the life expectancy of the current setup. :-/

>>> BTW: I'm currently developing an initrd without the need of python
>> and
>>> friends. That will really spare a lot of space ;-) .
>> Now that IS interesting. What is python stuff actually used for? In
>> all my modding and patching of OSR I've never actually bumped into any 
>> python code.
 >
> com-queryclusterconf is python. And this queries the clusterconfiguration
> in a general way. This is required right now.
> 
> AND most importantly for GFS clusters we need fenceagents in the initrd
> and most are based on python.

I've heard rumours to this extent, but all the ones I ever needed to use 
were always written in perl.

> Although we could add those later on via bootsr.

Ouch. That's not ideal. Mind you, python vs. perl isn't that big a 
difference in terms of disk footprint.

> But when we are getting rid of the com-queryclusterconf python dep we
> could build initrds without python/perl for NFS,OCFS2, glusterfs and localfs.

That is an interesting point. But doesn't OCFS2 need fencing agents? I 
would expect it to, considering it is functionally nearly identical to 
GFS. Speaking of which, I've been looking into getting Veritas Cluster 
to work, and when I manage to get my hands on a trial licence I'll look 
into adding support for it into OSR. ;)

Gordan