Re: [OSR-devel] Bug?

[Marc G. <gr...@at...>]

On Sunday 12 April 2009 13:08:51 Gordan Bobic wrote:
> Marc Grimme wrote:
> > On Saturday 04 April 2009 12:59:00 Gordan Bobic wrote:
> >> This comes up when building the initrd with the latest preview version:
> >>
> >> Extracting
> >> rpms.../opt/atix/comoonics-bootimage/boot-scripts/etc/chroot-lib.sh:
> >> line 292: $filename: ambiguous redirect
> >
> > Looks like there is something weird come up in the filelist. Means one
> > file is misinterpreted. Hmm.
> > What does file-list.lst (or something like this) look like in the initrd?
>
> file-list.txt is attached. I'm guessing it's the line that says "@map"
> that's causing a problem. No idea where that came from, though...
No the @map is perfectly normal. This direction tells the mkinitrd to copy all 
from next token to next token and ignore the path prefixed. Means:
cp -a /opt/atix/comoonics-bootimage/boot-scripts/* /
relative to the initrd.
So this is very important.
>
> >> Doesn't seem to be terminal, but it might be breaking something.
> >>
> >> Also this:
> >> Copying kernelmodules
> >> (2.6.24.7).../opt/atix/comoonics-bootimage/boot-scripts/etc/clusterfs-li
> >>b.s h: line 1181: fuse_get_drivers: command not found
> >>
> >> I suspect this is caused by GlusterFS coming up as a fuse FS (which it
> >> is), but there's an assumption being made about the function name based
> >> on the FS. I'm not sure what the best solution for that might be. Any
> >> ideas?
> >
> > Yes that's due to the "new" modules list. But it should be
> > glusterfs_get_drivers shouldn't it. In my version I already added this
> > function. It just returns fuse.
>
> Yes, that could be related to the fact that any fuse based FS will show
> up as type fuse.
>
> Here's a line that mount reports:
>
> glusterfs on /home type fuse
> (rw,user_id=0,group_id=0,default_permissions,allow_other,max_read=1048576)
>
> I can see that clusterfs-lib.sh calls ${rootfs}_get_drivers, but which
> file should I add this function to? etc/rhel5/glusterfs-lib.sh?
No you can just add a function called glusterfs_get_driver 
to /etc/glusterfs-lib.sh. You'll find my version attached.
But still rootfs should be glusterfs as specified in the cluster.conf as 
rootfs. It shouldn't query the mounted filesystems but use the one specified 
in cluster.conf.
So still the question is where did rootfs=fuse come from. 
Do you only see it when /etc/init.d/bootsr is called or also during boot?
>
> >> I also had an idea for reducing the module count using my old lsmod
> >> method. There is a reference count column, and modules with ref-count of
> >> 0 obviously aren't needed by the logic used. I'll write a patch that
> >> takes this into account when pruning the modules.
> >
> > Ok. That's right.
> > But still there are modules being loaded later that do not necessarily
> > need to get into the initrd ;-) .
>
> Interestingly enough, fuse.ko wasn't being bundled into the initrd by
> default with the latest update. It seems to be an edge case that got
> missed. I can add it explicitly by adding kernel-module-fuse, but this
> seems like a bit of an inconsistency on the module auto-detection. Any
> ideas on how to reconcile that?
What does "get_min_modules" tell you if you call it on comandline:
[root@axqad108-1 ~]# 
source /opt/atix/comoonics-bootimage/boot-scripts/etc/std-lib.sh 
[root@axqad108-1 ~]# sourceLibs /opt/atix/comoonics-bootimage/boot-scripts 
[root@axqad108-1 ~]# 
sourceRootfsLibs /opt/atix/comoonics-bootimage/boot-scripts
[root@axqad108-1 ~]# get_min_modules 

dlm
lock[_-]dlm
gfs
gfs2
configfs
lock[_-]nolock
sunrpc
nfs
lockd
fscache
nfs[_-]acl


>
> Gordan



-- 
Gruss / Regards,

Marc Grimme
http://www.atix.de/               http://www.open-sharedroot.org/