open-sharedroot-devel

Re: [OSR-devel] initrd cleanup

[Mark H. <hla...@at...>]

> > 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 ;-)

Mark

Re: [OSR-devel] iSCSI Root

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

On Fri, 12 Oct 2007, Marc Grimme wrote:

>>> So I'll explain it without.
>>> It's basically quite easy:
>>> 1. For every node: spare one partition for the chroot (let's say it
>>> is /dev/sda4) and let it be at least 500M.
>>> 2. For every node: mkfs.ext3 /dev/sda4
>>> 3. Add to the com_info section for every node the following:
>>> <chrootenv mountpoint="/var/comoonics/chroot" fstype="ext3"
>>> device="/dev/sda4" chrootdir="/var/comoonics/chroot"/>
>>> 4. Make a new initrd
>>> 5. reboot every node
>>> That's it no everything should be running on your local disk instead of
>>> tmpfs.
>>
>> OK - how does this work, then? Does it copy the initrd to the disk at
>> boot time? Or does the mkinitrd build the init root straight on that
>> partition? Or does something else happen? What does
>> /etc/sysconfig/comoonics-chroot do, then? I thought it had some part to
>> play in this.
>
> So first the initrd is loaded into RAM. This we cannot change. Then the
> localdisk is setup (linuxrc.generic.sh lines 279-288).

Aha! All becomes clear. So /etc/sysconfig/comoonics-chroot is not 
something I need to worry about.

Gordan

Re: [OSR-devel] iSCSI Root

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

On Friday 12 October 2007 10:35:33 Gordan Bobic wrote:
> On Fri, 12 Oct 2007, Marc Grimme wrote:
> >
> > So first the initrd is loaded into RAM. This we cannot change. Then the
> > localdisk is setup (linuxrc.generic.sh lines 279-288).
>
> Aha! All becomes clear. So /etc/sysconfig/comoonics-chroot is not
> something I need to worry about.
Only if you are using RHEL4 with comoonics-bootimage-1.2 and localfilesystem 
for chroot and not willing to change the old config. And nevertheless what to 
upgrade to bootimage-1.3.

It is only for compatibility reasons with 1.2.

Marc.

-- 
Gruss / Regards,

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

Re: [OSR-devel] iSCSI Root

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

On Fri, 12 Oct 2007, Gordan Bobic wrote:

> On Fri, 12 Oct 2007, Marc Grimme wrote:
>
>>>> So I'll explain it without.
>>>> It's basically quite easy:
>>>> 1. For every node: spare one partition for the chroot (let's say it
>>>> is /dev/sda4) and let it be at least 500M.
>>>> 2. For every node: mkfs.ext3 /dev/sda4
>>>> 3. Add to the com_info section for every node the following:
>>>> <chrootenv mountpoint="/var/comoonics/chroot" fstype="ext3"
>>>> device="/dev/sda4" chrootdir="/var/comoonics/chroot"/>
>>>> 4. Make a new initrd
>>>> 5. reboot every node
>>>> That's it no everything should be running on your local disk instead of
>>>> tmpfs.
>>>
>>> OK - how does this work, then? Does it copy the initrd to the disk at
>>> boot time? Or does the mkinitrd build the init root straight on that
>>> partition? Or does something else happen? What does
>>> /etc/sysconfig/comoonics-chroot do, then? I thought it had some part to
>>> play in this.
>>
>> So first the initrd is loaded into RAM. This we cannot change. Then the
>> localdisk is setup (linuxrc.generic.sh lines 279-288).

Just thinking about this - would it not be better to explicitly re-create 
this file system (thus blowing away whatever was there beforehand) ever 
time the init root is put there?

My reasoning is that something could pollute this fs in the meantime, or 
it could be not unmounted cleanly or similar. There is no need for 
journalling on this, as it is created from the ramdisk every time. So 
instead run mkfs.ext2 on it every time before it gets used. Any thoughts 
on this? Granted, this could be a tad dangerous, as accidentally changing 
the configuration would mean a wrong file system gets blown away - which 
is possibly a bit _too_ dangerous.

Gordan

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. :-/

Gordan

Re: [OSR-devel] initrd cleanup

[Mark H. <hla...@at...>]

On Friday 12 October 2007 10:37:22 Gordan Bobic wrote:
> >>> 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.

Mark

[OSR-devel] Copying the iSCSI root FS

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

I finally have everything working as I want it. Apart from one thing - I 
was expecting to have /boot on iSCSI/GFS as well, which is now not going 
to happen.

So I want to end up using /dev/sdb whole for the root GFS. My plan is to 
make another SAN partition, mount it via iSCSI, tar the contents across, 
change cluster.conf and build a second initrd to boot it (for testing - 
before I blow away the original GFS root).

Is there anything special that I should pay attention to during this 
exercise? Will tar (or cp -ax as per the original local->SAN copy in 
the docs) pick up everything that is required (e.g. cdsl stuff)? What will 
I have to re-do manually afterwards to make the new image bootable?

Thanks.

Gordan

P.S.
Will post the iSCSI enabling mods in a bit.

Re: [OSR-devel] initrd cleanup

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

On Fri, 12 Oct 2007, Mark Hlawatschek wrote:

> On Friday 12 October 2007 10:37:22 Gordan Bobic wrote:
>>>>> 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?

Thus, in the initrd_cleanup, I would need to rm -rf 
/var/comoonics/chroot/lib/modules ?

Gordan

Re: [OSR-devel] initrd cleanup

[Mark H. <hla...@at...>]

On Friday 12 October 2007 11:14:01 Gordan Bobic wrote:
> On Fri, 12 Oct 2007, Mark Hlawatschek wrote:
> > On Friday 12 October 2007 10:37:22 Gordan Bobic wrote:
> >>>>> 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. 
>
> Thus, in the initrd_cleanup, I would need to rm -rf
> /var/comoonics/chroot/lib/modules ?
In my opinion it would be better to modify the create_chroot function. Here, 
the files are copied from the initrd. We wouldn't need to copy 
the /lib/modules. 

Mark

Re: [OSR-devel] initrd cleanup

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

On Fri, 12 Oct 2007, Mark Hlawatschek wrote:

>> Thus, in the initrd_cleanup, I would need to rm -rf
>> /var/comoonics/chroot/lib/modules ?
> In my opinion it would be better to modify the create_chroot function. Here,
> the files are copied from the initrd. We wouldn't need to copy
> the /lib/modules.

But wouldn't that only be useful for the disk based init root? I see this 
as an issue only for the ramdisk init root. Or does the init ramdisk make 
a new ramdisk root if there is no disk for init root?

Basically, if the init root is being moved to a local disk, then the fact 
that the dedicated partition needs to be 70MB bigger isn't such a huge 
deal. An extra 70MB of RAM being uses is a considerably more 
serious issue.

Gordan

Re: [OSR-devel] initrd cleanup

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

On Fri, 12 Oct 2007, Mark Hlawatschek wrote:

>>>>>>> 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.

Gordan

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

Re: [OSR-devel] initrd cleanup

[Mark H. <hla...@at...>]

On Friday 12 October 2007 11:53:08 Gordan Bobic wrote:
> On Fri, 12 Oct 2007, Mark Hlawatschek wrote:
> >> Thus, in the initrd_cleanup, I would need to rm -rf
> >> /var/comoonics/chroot/lib/modules ?
> >
> > In my opinion it would be better to modify the create_chroot function.
> > Here, the files are copied from the initrd. We wouldn't need to copy
> > the /lib/modules.
>
> But wouldn't that only be useful for the disk based init root? I see this
> as an issue only for the ramdisk init root. Or does the init ramdisk make
> a new ramdisk root if there is no disk for init root?
Yes is creates a new ramdisk root when there is no local disk assigned.
>
> Basically, if the init root is being moved to a local disk, then the fact
> that the dedicated partition needs to be 70MB bigger isn't such a huge
> deal. An extra 70MB of RAM being uses is a considerably more
> serious issue.
I agree with you.

Mark

Re: [OSR-devel] initrd cleanup

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

On Fri, 12 Oct 2007, Mark Hlawatschek wrote:

> On Friday 12 October 2007 11:53:08 Gordan Bobic wrote:
>> On Fri, 12 Oct 2007, Mark Hlawatschek wrote:
>>>> Thus, in the initrd_cleanup, I would need to rm -rf
>>>> /var/comoonics/chroot/lib/modules ?
>>>
>>> In my opinion it would be better to modify the create_chroot function.
>>> Here, the files are copied from the initrd. We wouldn't need to copy
>>> the /lib/modules.
>>
>> But wouldn't that only be useful for the disk based init root? I see this
>> as an issue only for the ramdisk init root. Or does the init ramdisk make
>> a new ramdisk root if there is no disk for init root?
>
> Yes is creates a new ramdisk root when there is no local disk assigned.

Ah, OK. I misunderstood how it works. I thought the initrd is what sticks 
around. I didn't realise that there was a secondary init rd that gets 
created to carry the SSI start-up and tear-down.

Gordan

[OSR-devel] iSCSI Mods - Changed Files Attached

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

I have attached a tar ball of files that I changed (or added) in the 
standard setup to get iSCSI to work.

Please let me know if I omitted anything.

There is probably some pruning that could be done to this (I went for 
including full RPMs + configs), which was arguably sub-optimal - there is 
likely to be some docs/man pages included (not that anyone is likely to 
notice next to 70MB of drivers :^).

I also hard-removed (C)LVM stuff - something that you probably won't want 
to merge into the main tree.

Thanks for all the help over the last few days, and for accepting my 
patches. I really appreciate it. This is by far the most postive OSS 
experience I have had to date. :-)

Gordan

Re: [OSR-devel] iSCSI Mods - Changed Files Attached

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

On Friday 12 October 2007 12:29:27 Gordan Bobic wrote:
> I have attached a tar ball of files that I changed (or added) in the
> standard setup to get iSCSI to work.
>
> Please let me know if I omitted anything.
>
> There is probably some pruning that could be done to this (I went for
> including full RPMs + configs), which was arguably sub-optimal - there is
> likely to be some docs/man pages included (not that anyone is likely to
> notice next to 70MB of drivers :^).
>
> I also hard-removed (C)LVM stuff - something that you probably won't want
> to merge into the main tree.
>
> Thanks for all the help over the last few days, and for accepting my
> patches. I really appreciate it. This is by far the most postive OSS
> experience I have had to date. :-)
>
> Gordan

Attached you'll find the latest rpm with iscsi included.
Last thing you should have to have is either rootsource=iscsi as bootparam or 
in com_info <rootsource name="iscsi"/>.
Also add to the /etc/comoonics/bootimage/files.initrd.d/user_edit.list 
the /var/lib/iscsi/nodes/iqn.2001-05.com.equallogic\:1-234567-89abcdef0-123456789abcdef0-ssi-root/10.10.10.1\,3260

Let me know if it works.

-- 
Gruss / Regards,

Marc Grimme
Phone: +49-89 452 3538-14
http://www.atix.de/               http://www.open-sharedroot.org/

**

Visit us at LinuxWorld Conference & Expo 
31.10. - 01.11.2007 in Jaarbeurs Utrecht - The Netherlands
ATIX stand: Hall 9 / B 005

**
ATIX Informationstechnologie und Consulting AG
Einsteinstr. 10 
85716 Unterschleissheim
Deutschland/Germany

Phone: +49-89 452 3538-0
Fax:   +49-89 990 1766-0

Registergericht: Amtsgericht Muenchen
Registernummer: HRB 168930
USt.-Id.: DE209485962

Vorstand: 
Marc Grimme, Mark Hlawatschek, Thomas Merz (Vors.)

Vorsitzender des Aufsichtsrats:
Dr. Martin Buss

Re: [OSR-devel] iSCSI Mods - Changed Files Attached

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

On Fri, 12 Oct 2007, Marc Grimme wrote:

>> I have attached a tar ball of files that I changed (or added) in the
>> standard setup to get iSCSI to work.
>>
>> Please let me know if I omitted anything.
>>
>> There is probably some pruning that could be done to this (I went for
>> including full RPMs + configs), which was arguably sub-optimal - there is
>> likely to be some docs/man pages included (not that anyone is likely to
>> notice next to 70MB of drivers :^).
>>
>> I also hard-removed (C)LVM stuff - something that you probably won't want
>> to merge into the main tree.
>>
>> Thanks for all the help over the last few days, and for accepting my
>> patches. I really appreciate it. This is by far the most postive OSS
>> experience I have had to date. :-)
>
> Attached you'll find the latest rpm with iscsi included.
> Last thing you should have to have is either rootsource=iscsi as bootparam or
> in com_info <rootsource name="iscsi"/>.

Hmm... Would it perhaps be better to put this a level up in the XML? I'm 
not sure it makes sense to set this up on every node entry. It would make 
more sense to define it for the whole cluster. I don't really see 
different nodes using a different method to mount the same block device.

> Also add to the /etc/comoonics/bootimage/files.initrd.d/user_edit.list
> the /var/lib/iscsi/nodes/iqn.2001-05.com.equallogic\:1-234567-89abcdef0-123456789abcdef0-ssi-root/10.10.10.1\,3260
>
> Let me know if it works.

Thanks, I'll try it in a bit.

For now, I have a different question - is there a way to specify mount 
options (e.g. noatime) for the GFS shared root? I know there is "options" 
for nfsclient tag, but is there something similar for the rootvolume tag? 
What is the best way to do this?

Thanks.

Gordan

Re: [OSR-devel] iSCSI Mods - Changed Files Attached

[Mark H. <hla...@at...>]

> For now, I have a different question - is there a way to specify mount
> options (e.g. noatime) for the GFS shared root? I know there is "options"
> for nfsclient tag, but is there something similar for the rootvolume tag?
> What is the best way to do this?
You can define mount options  by a mountopts="..." attribute in the 
<rootvolue/> tag.
E.g. <rootvolume name="/dev/vg_axqad101_sr/lv_sharedroot" 
mountopts="noatime,nodiratime"/> 

Mark

Re: [OSR-devel] iSCSI Mods - Changed Files Attached

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

>> For now, I have a different question - is there a way to specify mount
>> options (e.g. noatime) for the GFS shared root? I know there is "options"
>> for nfsclient tag, but is there something similar for the rootvolume tag?
>> What is the best way to do this?
>
> You can define mount options  by a mountopts="..." attribute in the
> <rootvolue/> tag.
> E.g. <rootvolume name="/dev/vg_axqad101_sr/lv_sharedroot"
> mountopts="noatime,nodiratime"/>

Thanks for that. :-)

Gordan

Re: [OSR-devel] iSCSI Mods - Changed Files Attached

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

On Fri, 12 Oct 2007, Marc Grimme wrote:

> On Friday 12 October 2007 12:29:27 Gordan Bobic wrote:
>> I have attached a tar ball of files that I changed (or added) in the
>> standard setup to get iSCSI to work.
>>
>> Please let me know if I omitted anything.
>>
>> There is probably some pruning that could be done to this (I went for
>> including full RPMs + configs), which was arguably sub-optimal - there is
>> likely to be some docs/man pages included (not that anyone is likely to
>> notice next to 70MB of drivers :^).
>>
>> I also hard-removed (C)LVM stuff - something that you probably won't want
>> to merge into the main tree.
>>
>> Thanks for all the help over the last few days, and for accepting my
>> patches. I really appreciate it. This is by far the most postive OSS
>> experience I have had to date. :-)
>>
>> Gordan
>
> Attached you'll find the latest rpm with iscsi included.
> Last thing you should have to have is either rootsource=iscsi as bootparam or
> in com_info <rootsource name="iscsi"/>.
> Also add to the /etc/comoonics/bootimage/files.initrd.d/user_edit.list
> the /var/lib/iscsi/nodes/iqn.2001-05.com.equallogic\:1-234567-89abcdef0-123456789abcdef0-ssi-root/10.10.10.1\,3260
>
> Let me know if it works.

It appears to be broken. The new initrd fails to fire up iSCSI. Where my 
old hard-coded version would modprobe the required modules and start up 
iscsid and iscsi, the new version doesn't.

I added <rootsource name="iscsi"/> to the com_info section on every node.

Did I miss something?

:-(

Gordan

Re: [OSR-devel] iSCSI Mods - Changed Files Attached

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

>>> I have attached a tar ball of files that I changed (or added) in the
>>> standard setup to get iSCSI to work.
>>>
>>> Please let me know if I omitted anything.
>>>
>>> There is probably some pruning that could be done to this (I went for
>>> including full RPMs + configs), which was arguably sub-optimal - there is
>>> likely to be some docs/man pages included (not that anyone is likely to
>>> notice next to 70MB of drivers :^).
>>>
>>> I also hard-removed (C)LVM stuff - something that you probably won't want
>>> to merge into the main tree.
>>>
>>> Thanks for all the help over the last few days, and for accepting my
>>> patches. I really appreciate it. This is by far the most postive OSS
>>> experience I have had to date. :-)
>>>
>>> Gordan
>>
>> Attached you'll find the latest rpm with iscsi included.
>> Last thing you should have to have is either rootsource=iscsi as bootparam or
>> in com_info <rootsource name="iscsi"/>.
>> Also add to the /etc/comoonics/bootimage/files.initrd.d/user_edit.list
>> the /var/lib/iscsi/nodes/iqn.2001-05.com.equallogic\:1-234567-89abcdef0-123456789abcdef0-ssi-root/10.10.10.1\,3260
>>
>> Let me know if it works.
>
> It appears to be broken. The new initrd fails to fire up iSCSI. Where my
> old hard-coded version would modprobe the required modules and start up
> iscsid and iscsi, the new version doesn't.
>
> I added <rootsource name="iscsi"/> to the com_info section on every node.
>
> Did I miss something?

I just added the rootsource=iscsi kernel boot option, and that doesn't fix 
it. Carefully looking at the screen log, the iSCSI TCP transport module 
does appear to get loaded, but the iscsid and iscsi services don't get 
started.

Gordan

Re: [OSR-devel] iSCSI Mods - Changed Files Attached

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

On Mon, 15 Oct 2007, Gordan Bobic wrote:

>>>> I have attached a tar ball of files that I changed (or added) in the
>>>> standard setup to get iSCSI to work.
>>>>
>>>> Please let me know if I omitted anything.
>>>>
>>>> There is probably some pruning that could be done to this (I went for
>>>> including full RPMs + configs), which was arguably sub-optimal - there is
>>>> likely to be some docs/man pages included (not that anyone is likely to
>>>> notice next to 70MB of drivers :^).
>>>>
>>>> I also hard-removed (C)LVM stuff - something that you probably won't want
>>>> to merge into the main tree.
>>>>
>>>> Thanks for all the help over the last few days, and for accepting my
>>>> patches. I really appreciate it. This is by far the most postive OSS
>>>> experience I have had to date. :-)
>>>>
>>>> Gordan
>>>
>>> Attached you'll find the latest rpm with iscsi included.
>>> Last thing you should have to have is either rootsource=iscsi as bootparam or
>>> in com_info <rootsource name="iscsi"/>.
>>> Also add to the /etc/comoonics/bootimage/files.initrd.d/user_edit.list
>>> the /var/lib/iscsi/nodes/iqn.2001-05.com.equallogic\:1-234567-89abcdef0-123456789abcdef0-ssi-root/10.10.10.1\,3260
>>>
>>> Let me know if it works.
>>
>> It appears to be broken. The new initrd fails to fire up iSCSI. Where my
>> old hard-coded version would modprobe the required modules and start up
>> iscsid and iscsi, the new version doesn't.
>>
>> I added <rootsource name="iscsi"/> to the com_info section on every node.
>>
>> Did I miss something?
>
> I just added the rootsource=iscsi kernel boot option, and that doesn't fix
> it. Carefully looking at the screen log, the iSCSI TCP transport module
> does appear to get loaded, but the iscsid and iscsi services don't get
> started.

Hmm... It looks like iSCSI is getting started correctly after all. It does 
come up and brings up the block device. The problem is somewhere else. It 
may be a good idea to not silence the iscsi startup, just for easier 
overview of what happens and what doesn't (unless you particularly object 
to a few green OKs among the blues).

Gordan

Re: [OSR-devel] iSCSI Mods - Changed Files Attached

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

>>>>> I have attached a tar ball of files that I changed (or added) in the
>>>>> standard setup to get iSCSI to work.
>>>>>
>>>>> Please let me know if I omitted anything.
>>>>>
>>>>> There is probably some pruning that could be done to this (I went for
>>>>> including full RPMs + configs), which was arguably sub-optimal - there is
>>>>> likely to be some docs/man pages included (not that anyone is likely to
>>>>> notice next to 70MB of drivers :^).
>>>>>
>>>>> I also hard-removed (C)LVM stuff - something that you probably won't want
>>>>> to merge into the main tree.
>>>>>
>>>>> Thanks for all the help over the last few days, and for accepting my
>>>>> patches. I really appreciate it. This is by far the most postive OSS
>>>>> experience I have had to date. :-)
>>>>>
>>>> Attached you'll find the latest rpm with iscsi included.
>>>> Last thing you should have to have is either rootsource=iscsi as bootparam or
>>>> in com_info <rootsource name="iscsi"/>.
>>>> Also add to the /etc/comoonics/bootimage/files.initrd.d/user_edit.list
>>>> the /var/lib/iscsi/nodes/iqn.2001-05.com.equallogic\:1-234567-89abcdef0-123456789abcdef0-ssi-root/10.10.10.1\,3260
>>>>
>>>> Let me know if it works.
>>>
>>> It appears to be broken. The new initrd fails to fire up iSCSI. Where my
>>> old hard-coded version would modprobe the required modules and start up
>>> iscsid and iscsi, the new version doesn't.
>>>
>>> I added <rootsource name="iscsi"/> to the com_info section on every node.
>>>
>>> Did I miss something?
>>
>> I just added the rootsource=iscsi kernel boot option, and that doesn't fix
>> it. Carefully looking at the screen log, the iSCSI TCP transport module
>> does appear to get loaded, but the iscsid and iscsi services don't get
>> started.
>
> Hmm... It looks like iSCSI is getting started correctly after all. It does
> come up and brings up the block device. The problem is somewhere else. It
> may be a good idea to not silence the iscsi startup, just for easier
> overview of what happens and what doesn't (unless you particularly object
> to a few green OKs among the blues).

Something very weird is happening. With full debug enabled, configfs 
module is loaded, but mounting the configfs fails. :-/

Gordan

Re: [OSR-devel] iSCSI Mods - SOLVED!

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

On Mon, 15 Oct 2007, Gordan Bobic wrote:

>>>>>> I have attached a tar ball of files that I changed (or added) in the
>>>>>> standard setup to get iSCSI to work.
>>>>>>
>>>>>> Please let me know if I omitted anything.
>>>>>>
>>>>>> There is probably some pruning that could be done to this (I went for
>>>>>> including full RPMs + configs), which was arguably sub-optimal - there is
>>>>>> likely to be some docs/man pages included (not that anyone is likely to
>>>>>> notice next to 70MB of drivers :^).
>>>>>>
>>>>>> I also hard-removed (C)LVM stuff - something that you probably won't want
>>>>>> to merge into the main tree.
>>>>>>
>>>>>> Thanks for all the help over the last few days, and for accepting my
>>>>>> patches. I really appreciate it. This is by far the most postive OSS
>>>>>> experience I have had to date. :-)
>>>>>>
>>>>> Attached you'll find the latest rpm with iscsi included.
>>>>> Last thing you should have to have is either rootsource=iscsi as bootparam or
>>>>> in com_info <rootsource name="iscsi"/>.
>>>>> Also add to the /etc/comoonics/bootimage/files.initrd.d/user_edit.list
>>>>> the /var/lib/iscsi/nodes/iqn.2001-05.com.equallogic\:1-234567-89abcdef0-123456789abcdef0-ssi-root/10.10.10.1\,3260
>>>>>
>>>>> Let me know if it works.
>>>>
>>>> It appears to be broken. The new initrd fails to fire up iSCSI. Where my
>>>> old hard-coded version would modprobe the required modules and start up
>>>> iscsid and iscsi, the new version doesn't.
>>>>
>>>> I added <rootsource name="iscsi"/> to the com_info section on every node.
>>>>
>>>> Did I miss something?
>>>
>>> I just added the rootsource=iscsi kernel boot option, and that doesn't fix
>>> it. Carefully looking at the screen log, the iSCSI TCP transport module
>>> does appear to get loaded, but the iscsid and iscsi services don't get
>>> started.
>>
>> Hmm... It looks like iSCSI is getting started correctly after all. It does
>> come up and brings up the block device. The problem is somewhere else. It
>> may be a good idea to not silence the iscsi startup, just for easier
>> overview of what happens and what doesn't (unless you particularly object
>> to a few green OKs among the blues).
>
> Something very weird is happening. With full debug enabled, configfs
> module is loaded, but mounting the configfs fails. :-/

I'm not entirely sure how, but it was the existance of the 
/etc/sysconfig/comoonics-chroot file that was breaking things. I just 
looked through the new RPMs, and that's not where it came from. I can only 
guess that I created it to silence a warning, and then later removed it 
from /etc/comoonics file list. The configs got replaced by the new RPMs 
and put it back in, which is what broke it.

Instead of replacing the files in /etc/comoonics, perhaps it would 
be better to create them as file.rpmnew, to avoid clobbering an existing, 
good config.

Anyway, the new RPMs are good. They meet the "it works for me" approval.
:-)

Thanks again, guys.

Gordan

[OSR-devel] GFS Mount Options with mountopts

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

My cluster.conf says:
<rootvolume name = "/dev/sdb" mountopts = "noatime,nodiratime"/>

But /proc/mounts says:
/dev/sdb / gfs rw,hostdata=jid=0:id=131076:first=0 0 0
/dev/sdb /cdsl.local gfs rw,hostdata=jid=0:id=131076:first=0 0 0

It doesn't list the noatime and nodiratime options.

Am I doing something wrong here?

Gordan