Re: [OSR-devel] IPs in cluster.conf and manual startup

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

Just tried working around it by adding the ifcfg-eth1 file to the initrd 
build and it didn't help. It's as if the ifcfg file actually gets built at 
run-time. What program does this?

Gordan

On Tue, 6 Nov 2007, go...@bo... wrote:

> Thanks for that. :-)
>
> I'm having a problem with the way the ifcfg-eth* files are being handled
> for the initrd. My ifcfg-eth1 file doesn't get transferred across
> verbatim. This is a problem because I have to explicitly specify the
> HWADDR in my ifcfg files (therwise they come up on wrong subnets).
>
> It looks as if mkinitrd removes some lines from the file, and this causes
> eth1 to be physical eth0, which puts it on the wrong subnet, and that
> means it can't see the iSCSI shares.  :-(
>
> I checked the /etc/sysconfig/network-scripts/ifcfg-eth1 in the initrd, and
> it is indeed lacking the HWADDR line (and a few others).
>
> Am I missing something here? Does mkinitrd mangle the ifcfg-eth* files?
>
> Thanks.
>
> Gordan
>
> On Mon, 22 Oct 2007, Mark Hlawatschek wrote:
>
>>> I'm in a position where I have to move my GFS volume from one SAN to
>>> another, on a different IP block.
>>>
>>> If my IP for the SAN and cluster operation is assigned by DHCP, do I have
>>> to specify it in cluster.conf anyway? Or is specifying the MAC address
>>> sufficient? Or do I specify something like "dhcp" as the IP address?
>> Yes, it should be possible to use dhcp by adding this:
>> <eth name="eth0" ip="dhcp" mac="yourmacaddress" />
>> Please note, that defining a mac address is mandatory, because it defines the
>> node in the cluster.
>>
>>>
>>> If the cluster doesn't come up normally and I'm stuck in the initrd boot
>>> image, is there a documented list of procedures on how to get from there
>>> to mounting the GFS root volume in the right place sufficiently (i.e.
>>> including the host speciffic files, such as /etc/modprobe.conf) to re-make
>>> the initrd?
>> You need to do the following steps:
>> 1. mount your rootfs to /mnt/newroot if the cluster software fails to start,
>> use the lockproto=lock_nolock option to mount the fs. But make sure it's the
>> only node mounting the filesystem ;-) )
>> # mount -t gfs -o lockproto=lock_nolock /dev/foo /mnt/newroot
>> 2. mount --bind /dev /mnt/newroot/dev
>> 3. mount -t proc proc /mnt/newroot/proc
>> 4. mount -t sysfs none /mnt/newroot/sys
>> 5. mount --bind /mnt/newroot/cluster/cdsl/<nodeid> /mnt/newroot/cdsl.local
>> 6. chroot /mnt/newroot
>> 7. you can make your changes and build new initrd in the chroot
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Open-sharedroot-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/open-sharedroot-devel
>