You can subscribe to this list here.
2006 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(105) |
Nov
(10) |
Dec
(7) |
2008 |
Jan
|
Feb
(31) |
Mar
(13) |
Apr
(7) |
May
|
Jun
(2) |
Jul
(1) |
Aug
|
Sep
(4) |
Oct
|
Nov
(23) |
Dec
|
2009 |
Jan
(25) |
Feb
(24) |
Mar
(10) |
Apr
(8) |
May
(4) |
Jun
(6) |
Jul
(27) |
Aug
(1) |
Sep
|
Oct
(2) |
Nov
(7) |
Dec
(25) |
2010 |
Jan
|
Feb
(7) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
(1) |
From: Gordan B. <go...@bo...> - 2007-10-11 13:22:41
|
On Thu, 11 Oct 2007, Marc Grimme wrote: >> Almost everything works now. >> I had to move the scsi_start to _before_ the dm initialisation, so that >> the locally attached SCSI drives show up before the iSCSI devices. >> >> So, the start-up order is: >> SCSI >> iSCSI >> dm >> >> Now things just seem to end with a failure to get things going: >> >> Mounting configfs [FAILED] >> Starting service /sbin/ccsd [FAILED] >> >> No glaring errors on the console. >> >> I have attached the comoonics-boot.log >> >> Can anyone hazard a guess as to what goes wrong? Could it be that there is >> no two-node option in cluster-conf, so it can't get quorate with just one >> node? >> > I would also need /var/comoonics/chroot/var/log/comoonics-boot.log (fixed in > cvs) and please also boot with bootoption com-debug. Rebooted with com-debug. No /var/comoonics/chroot/var/log/comoonics-boot.log file appears in the initrd. New /var/log/comoonics-boot.log attached. Gordan |
From: Marc G. <gr...@at...> - 2007-10-11 11:51:29
|
On Thursday 11 October 2007 13:34:04 Gordan Bobic wrote: > Hi, > > Almost everything works now. > I had to move the scsi_start to _before_ the dm initialisation, so that > the locally attached SCSI drives show up before the iSCSI devices. > > So, the start-up order is: > SCSI > iSCSI > dm > > Now things just seem to end with a failure to get things going: > > Mounting configfs [FAILED] > Starting service /sbin/ccsd [FAILED] > > No glaring errors on the console. > > I have attached the comoonics-boot.log > > Can anyone hazard a guess as to what goes wrong? Could it be that there is > no two-node option in cluster-conf, so it can't get quorate with just one > node? > > Gordan I would also need /var/comoonics/chroot/var/log/comoonics-boot.log (fixed in cvs) and please also boot with bootoption com-debug. -- 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 |
From: Gordan B. <go...@bo...> - 2007-10-11 11:40:32
|
On Thu, 11 Oct 2007, Marc Grimme wrote: >>>> Just looking through the initrd init script - what is supposed to be in >>>> /etc/sysconfig/comoonics-chroot ? It's mentioned in the comments, but I >>>> don't see it referenced in the actualy code. >>> >>> If you have a local disk in your server you can use it to move all the >>> files on it and save some memory. >>> >>> This can either be done configured in /etc/sysconfig/comoonics-chroot >>> installed via comoonics-bootimage-compat (or something use: yum search >>> comoonics-bootimage) or with the cluster.conf section . >>> >>> <chrootenv mountpoint="/var/comoonics/chroot" fstype="ext3" >>> device="/dev/vg_local/lv_chroot" >>> chrootdir="/var/comoonics/chroot"/> >>> >>> All services needed for the cluster outside the sharedroot will be >>> running there. >> >> So, it's effectively an initrd replacement? Doesn't the initrd get >> de-allocated once the shared root is mounted? > > No completely. The initrd or better the memory disk will also be used after > the init in initrd has given over to init on sharedroot. Because fencing and > the whole cluster-com which is running in userspace cannot run on a cluster > filesystem that might get froozen when problems are at hand. So we also > introduced a way to migrate the ramdisk on localdisks. That is the chrootenv > which is only copy of the initrd where services like fenced and the like run > on. So, what does the content of the /etc/sysconfig/comoonics-chroot need to be to make use of this? What FS should this be on? Presumably every cluster node would have this on it's local disk, then. Does this need to be build with something like the initrd image? Are there any docs on this, so I can read up on it before asking too many questions? :^) Gordan |
From: Gordan B. <go...@bo...> - 2007-10-11 11:36:31
|
On Thu, 11 Oct 2007, Mark Hlawatschek wrote: >> Ah, minor problem. Not a big deal, but potentially a problem nevertheless. >> If we fire up iSCSI _first_ (i.e. before normal SCSI), then the iSCSI >> drive appears as sda, and the local disk becomes sdb. Does anyone think >> this might end up being a problem? I can't immediately think of why this >> might be a problem, other than it perhaps being a little illogical to have >> the local disks listed _after_ remote disks. >> >> I expect the solution would be to just modprobe sd_mod before starting up >> iSCSI. >> > I agree. I think the iscsi disks should started after the local disks. I had to move the whole scsi_start up, because loading sd_mod isn't enough - you have to load the scsi adapter drivers first, which scsi_start handles. Gordan |
From: Gordan B. <go...@bo...> - 2007-10-11 11:35:30
|
>> Ah, minor problem. Not a big deal, but potentially a problem nevertheless. >> If we fire up iSCSI _first_ (i.e. before normal SCSI), then the iSCSI >> drive appears as sda, and the local disk becomes sdb. Does anyone think >> this might end up being a problem? I can't immediately think of why this >> might be a problem, other than it perhaps being a little illogical to have >> the local disks listed _after_ remote disks. >> >> I expect the solution would be to just modprobe sd_mod before starting up >> iSCSI. >> >> Any thoughts on this? > > Just do it. We long ago stopped relying on any order of on which disk lies > what. So no problem from our side. OK, see other email. Changed ordering to: start_scsi iSCSI start-up dm That way the devices come up in the right order, and the dm stuff still starts up before we try to mount anything. Gordan |
From: Gordan B. <go...@bo...> - 2007-10-11 11:34:46
|
Hi, Almost everything works now. I had to move the scsi_start to _before_ the dm initialisation, so that the locally attached SCSI drives show up before the iSCSI devices. So, the start-up order is: SCSI iSCSI dm Now things just seem to end with a failure to get things going: Mounting configfs [FAILED] Starting service /sbin/ccsd [FAILED] No glaring errors on the console. I have attached the comoonics-boot.log Can anyone hazard a guess as to what goes wrong? Could it be that there is no two-node option in cluster-conf, so it can't get quorate with just one node? Gordan |
From: Marc G. <gr...@at...> - 2007-10-11 11:31:42
|
On Thursday 11 October 2007 12:34:48 Gordan Bobic wrote: > >>>>>>>>> And, obviously, I'd need to make all this happen before the > >>>>>>>>> normal boot process tries to mount the root disk. > >>>>>>>> > >>>>>>>> Do it before or right after scsi-start is called. > >>>>>>> > >>>>>>> I can't find any reference to "scsi-start". Where does this happen? > >>>>>> > >>>>>> It's scsi_start in linux.generic.sh Line 239. > >>>>> > >>>>> D'oh! What a difference an _ makes. > >>>>> > >>>>> I think the iSCSI stuff should be added before the dm_start stuff, > >>>>> which is just before the scsi_start. > >>>>> > >>>>> Right, that seems to have worked. Almost there. Now I get: > >>>>> > >>>>> Mounting LABEL=/ on /mnt/newroot..device not found error [FAILED] > >>>>> Mounting /cdsl.local on /cluster/cdsl/3..no cdsldir found > >>>>> "/mnt/mewroot//cluster/cdsl" > >>>>> Could not mount cdsl /cdsl.local to /cluster/cdsl/3. Exiting > >>>>> > >>>>> Where does it get the LABEL=/ from? I'm pretty sure I didn't set any. > >>>> > >>>> Concerning LABEL=/ > >>>> I think you should check you bootloader config and change root=LABEL=/ > >>>> to root=/dev/sd.. That should do it. > >>> > >>> What files is that in? > >> > >> Just looking through the initrd init script - what is supposed to be in > >> /etc/sysconfig/comoonics-chroot ? It's mentioned in the comments, but I > >> don't see it referenced in the actualy code. > > > > If you have a local disk in your server you can use it to move all the > > files on it and save some memory. > > > > This can either be done configured in /etc/sysconfig/comoonics-chroot > > installed via comoonics-bootimage-compat (or something use: yum search > > comoonics-bootimage) or with the cluster.conf section . > > > > <chrootenv mountpoint="/var/comoonics/chroot" fstype="ext3" > > device="/dev/vg_local/lv_chroot" > > chrootdir="/var/comoonics/chroot"/> > > > > All services needed for the cluster outside the sharedroot will be > > running there. > > So, it's effectively an initrd replacement? Doesn't the initrd get > de-allocated once the shared root is mounted? No completely. The initrd or better the memory disk will also be used after the init in initrd has given over to init on sharedroot. Because fencing and the whole cluster-com which is running in userspace cannot run on a cluster filesystem that might get froozen when problems are at hand. So we also introduced a way to migrate the ramdisk on localdisks. That is the chrootenv which is only copy of the initrd where services like fenced and the like run on. [root@axqa03_1 ~]# ls -l /proc/$(cat /var/comoonics/chroot/var/run/fenced.pid)/ total 0 dr-xr-xr-x 2 root root 0 Oct 11 13:31 attr -r-------- 1 root root 0 Oct 11 13:31 auxv -r--r--r-- 1 root root 0 Oct 11 13:31 cmdline -r--r--r-- 1 root root 0 Oct 11 13:31 cpuset lrwxrwxrwx 1 root root 0 Oct 11 13:31 cwd -> /cdsl.local/var/comoonics/chroot -r-------- 1 root root 0 Oct 11 13:31 environ lrwxrwxrwx 1 root root 0 Oct 11 13:31 exe -> /cdsl.local/var/comoonics/chroot/sbin/fenced dr-x------ 2 root root 0 Oct 11 13:31 fd -rw-r--r-- 1 root root 0 Oct 11 13:31 loginuid -r--r--r-- 1 root root 0 Oct 11 13:31 maps -rw------- 1 root root 0 Oct 11 13:31 mem -r--r--r-- 1 root root 0 Oct 11 13:31 mounts -r-------- 1 root root 0 Oct 11 13:31 mountstats -rw-r--r-- 1 root root 0 Oct 11 13:31 oom_adj -r--r--r-- 1 root root 0 Oct 11 13:31 oom_score lrwxrwxrwx 1 root root 0 Oct 11 13:31 root -> /cdsl.local/var/comoonics/chroot -r--r--r-- 1 root root 0 Oct 11 13:31 schedstat -r-------- 1 root root 0 Oct 11 13:31 smaps -r--r--r-- 1 root root 0 Oct 11 13:31 stat -r--r--r-- 1 root root 0 Oct 11 13:31 statm -r--r--r-- 1 root root 0 Oct 11 13:31 status dr-xr-xr-x 3 root root 0 Oct 11 13:31 task -r--r--r-- 1 root root 0 Oct 11 13:31 wchan Marc. > > Gordan > > ------------------------------------------------------------------------- > 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 -- 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 |
From: Mark H. <hla...@at...> - 2007-10-11 11:31:23
|
> Ah, minor problem. Not a big deal, but potentially a problem nevertheless. > If we fire up iSCSI _first_ (i.e. before normal SCSI), then the iSCSI > drive appears as sda, and the local disk becomes sdb. Does anyone think > this might end up being a problem? I can't immediately think of why this > might be a problem, other than it perhaps being a little illogical to have > the local disks listed _after_ remote disks. > > I expect the solution would be to just modprobe sd_mod before starting up > iSCSI. > I agree. I think the iscsi disks should started after the local disks. -- Gruss / Regards, Dipl.-Ing. Mark Hlawatschek Phone: +49-89 452 3538-15 http://www.atix.de/ http://www.open-sharedroot.org/ ** 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 |
From: Marc G. <gr...@at...> - 2007-10-11 11:27:34
|
On Thursday 11 October 2007 12:23:53 Gordan Bobic wrote: > >>>>>>>>> And, obviously, I'd need to make all this happen before the > >>>>>>>>> normal boot process tries to mount the root disk. > >>>>>>>> > >>>>>>>> Do it before or right after scsi-start is called. > >>>>>>> > >>>>>>> I can't find any reference to "scsi-start". Where does this happen? > >>>>>> > >>>>>> It's scsi_start in linux.generic.sh Line 239. > >>>>> > >>>>> D'oh! What a difference an _ makes. > >>>>> > >>>>> I think the iSCSI stuff should be added before the dm_start stuff, > >>>>> which is just before the scsi_start. > >>>>> > >>>>> Right, that seems to have worked. Almost there. Now I get: > >>>>> > >>>>> Mounting LABEL=/ on /mnt/newroot..device not found error [FAILED] > >>>>> Mounting /cdsl.local on /cluster/cdsl/3..no cdsldir found > >>>>> "/mnt/mewroot//cluster/cdsl" > >>>>> Could not mount cdsl /cdsl.local to /cluster/cdsl/3. Exiting > >>>>> > >>>>> Where does it get the LABEL=/ from? I'm pretty sure I didn't set any. > >>>> > >>>> Concerning LABEL=/ > >>>> I think you should check you bootloader config and change root=LABEL=/ > >>>> to root=/dev/sd.. That should do it. > >>> > >>> What files is that in? > >> > >> this is setup by your root environment. Normally in grub. There should > >> be something comparable on your pxe environment if you use it. > >> default from redhat: > >> [root@mobilix-01 ~]# cat /proc/cmdline > >> ro root=LABEL=/ rhgb quiet > >> sharedroot cluster: > >> [root@axqa03_1 ~]# cat /proc/cmdline > >> root=/dev/vg_axqa03_sr/lv_sharedroot com-step com-debug > > > > Oh, THAT root= parameter! Right. I'm feeling really stupid now. :'( > > Ah, minor problem. Not a big deal, but potentially a problem nevertheless. > If we fire up iSCSI _first_ (i.e. before normal SCSI), then the iSCSI > drive appears as sda, and the local disk becomes sdb. Does anyone think > this might end up being a problem? I can't immediately think of why this > might be a problem, other than it perhaps being a little illogical to have > the local disks listed _after_ remote disks. > > I expect the solution would be to just modprobe sd_mod before starting up > iSCSI. > > Any thoughts on this? Just do it. We long ago stopped relying on any order of on which disk lies what. So no problem from our side. > > Gordan > > ------------------------------------------------------------------------- > 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 -- 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 |
From: Gordan B. <go...@bo...> - 2007-10-11 10:34:53
|
>>>>>>>>> And, obviously, I'd need to make all this happen before the normal >>>>>>>>> boot process tries to mount the root disk. >>>>>>>> >>>>>>>> Do it before or right after scsi-start is called. >>>>>>> >>>>>>> I can't find any reference to "scsi-start". Where does this happen? >>>>>> >>>>>> It's scsi_start in linux.generic.sh Line 239. >>>>> >>>>> D'oh! What a difference an _ makes. >>>>> >>>>> I think the iSCSI stuff should be added before the dm_start stuff, >>>>> which is just before the scsi_start. >>>>> >>>>> Right, that seems to have worked. Almost there. Now I get: >>>>> >>>>> Mounting LABEL=/ on /mnt/newroot..device not found error [FAILED] >>>>> Mounting /cdsl.local on /cluster/cdsl/3..no cdsldir found >>>>> "/mnt/mewroot//cluster/cdsl" >>>>> Could not mount cdsl /cdsl.local to /cluster/cdsl/3. Exiting >>>>> >>>>> Where does it get the LABEL=/ from? I'm pretty sure I didn't set any. >>>> >>>> Concerning LABEL=/ >>>> I think you should check you bootloader config and change root=LABEL=/ >>>> to root=/dev/sd.. That should do it. >>> >>> What files is that in? >> >> Just looking through the initrd init script - what is supposed to be in >> /etc/sysconfig/comoonics-chroot ? It's mentioned in the comments, but I >> don't see it referenced in the actualy code. > If you have a local disk in your server you can use it to move all the files > on it and save some memory. > > This can either be done configured in /etc/sysconfig/comoonics-chroot > installed via comoonics-bootimage-compat (or something use: yum search > comoonics-bootimage) or with the cluster.conf section . > > <chrootenv mountpoint="/var/comoonics/chroot" fstype="ext3" > device="/dev/vg_local/lv_chroot" > chrootdir="/var/comoonics/chroot"/> > > All services needed for the cluster outside the sharedroot will be running > there. So, it's effectively an initrd replacement? Doesn't the initrd get de-allocated once the shared root is mounted? Gordan |
From: Marc G. <gr...@at...> - 2007-10-11 10:30:52
|
On Thursday 11 October 2007 12:13:29 Gordan Bobic wrote: > On Thu, 11 Oct 2007, Gordan Bobic wrote: > >>>>>>> And, obviously, I'd need to make all this happen before the normal > >>>>>>> boot process tries to mount the root disk. > >>>>>> > >>>>>> Do it before or right after scsi-start is called. > >>>>> > >>>>> I can't find any reference to "scsi-start". Where does this happen? > >>>> > >>>> It's scsi_start in linux.generic.sh Line 239. > >>> > >>> D'oh! What a difference an _ makes. > >>> > >>> I think the iSCSI stuff should be added before the dm_start stuff, > >>> which is just before the scsi_start. > >>> > >>> Right, that seems to have worked. Almost there. Now I get: > >>> > >>> Mounting LABEL=/ on /mnt/newroot..device not found error [FAILED] > >>> Mounting /cdsl.local on /cluster/cdsl/3..no cdsldir found > >>> "/mnt/mewroot//cluster/cdsl" > >>> Could not mount cdsl /cdsl.local to /cluster/cdsl/3. Exiting > >>> > >>> Where does it get the LABEL=/ from? I'm pretty sure I didn't set any. > >> > >> Concerning LABEL=/ > >> I think you should check you bootloader config and change root=LABEL=/ > >> to root=/dev/sd.. That should do it. > > > > What files is that in? > > Just looking through the initrd init script - what is supposed to be in > /etc/sysconfig/comoonics-chroot ? It's mentioned in the comments, but I > don't see it referenced in the actualy code. If you have a local disk in your server you can use it to move all the files on it and save some memory. This can either be done configured in /etc/sysconfig/comoonics-chroot installed via comoonics-bootimage-compat (or something use: yum search comoonics-bootimage) or with the cluster.conf section . <chrootenv mountpoint="/var/comoonics/chroot" fstype="ext3" device="/dev/vg_local/lv_chroot" chrootdir="/var/comoonics/chroot"/> All services needed for the cluster outside the sharedroot will be running there. Marc. > > Gordan > > ------------------------------------------------------------------------- > 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 -- 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 |
From: Gordan B. <go...@bo...> - 2007-10-11 10:24:04
|
>>>>>>>>> And, obviously, I'd need to make all this happen before the normal >>>>>>>>> boot process tries to mount the root disk. >>>>>>>> >>>>>>>> Do it before or right after scsi-start is called. >>>>>>> >>>>>>> I can't find any reference to "scsi-start". Where does this happen? >>>>>> >>>>>> It's scsi_start in linux.generic.sh Line 239. >>>>> >>>>> D'oh! What a difference an _ makes. >>>>> >>>>> I think the iSCSI stuff should be added before the dm_start stuff, which >>>>> is just before the scsi_start. >>>>> >>>>> Right, that seems to have worked. Almost there. Now I get: >>>>> >>>>> Mounting LABEL=/ on /mnt/newroot..device not found error [FAILED] >>>>> Mounting /cdsl.local on /cluster/cdsl/3..no cdsldir found >>>>> "/mnt/mewroot//cluster/cdsl" >>>>> Could not mount cdsl /cdsl.local to /cluster/cdsl/3. Exiting >>>>> >>>>> Where does it get the LABEL=/ from? I'm pretty sure I didn't set any. >>>> >>>> Concerning LABEL=/ >>>> I think you should check you bootloader config and change root=LABEL=/ to >>>> root=/dev/sd.. That should do it. >>> >>> What files is that in? >> >> this is setup by your root environment. Normally in grub. There should be >> something comparable on your pxe environment if you use it. >> default from redhat: >> [root@mobilix-01 ~]# cat /proc/cmdline >> ro root=LABEL=/ rhgb quiet >> sharedroot cluster: >> [root@axqa03_1 ~]# cat /proc/cmdline >> root=/dev/vg_axqa03_sr/lv_sharedroot com-step com-debug > > Oh, THAT root= parameter! Right. I'm feeling really stupid now. :'( Ah, minor problem. Not a big deal, but potentially a problem nevertheless. If we fire up iSCSI _first_ (i.e. before normal SCSI), then the iSCSI drive appears as sda, and the local disk becomes sdb. Does anyone think this might end up being a problem? I can't immediately think of why this might be a problem, other than it perhaps being a little illogical to have the local disks listed _after_ remote disks. I expect the solution would be to just modprobe sd_mod before starting up iSCSI. Any thoughts on this? Gordan |
From: Gordan B. <go...@bo...> - 2007-10-11 10:15:05
|
On Thu, 11 Oct 2007, Marc Grimme wrote: >>>>>>>> And, obviously, I'd need to make all this happen before the normal >>>>>>>> boot process tries to mount the root disk. >>>>>>> >>>>>>> Do it before or right after scsi-start is called. >>>>>> >>>>>> I can't find any reference to "scsi-start". Where does this happen? >>>>> >>>>> It's scsi_start in linux.generic.sh Line 239. >>>> >>>> D'oh! What a difference an _ makes. >>>> >>>> I think the iSCSI stuff should be added before the dm_start stuff, which >>>> is just before the scsi_start. >>>> >>>> Right, that seems to have worked. Almost there. Now I get: >>>> >>>> Mounting LABEL=/ on /mnt/newroot..device not found error [FAILED] >>>> Mounting /cdsl.local on /cluster/cdsl/3..no cdsldir found >>>> "/mnt/mewroot//cluster/cdsl" >>>> Could not mount cdsl /cdsl.local to /cluster/cdsl/3. Exiting >>>> >>>> Where does it get the LABEL=/ from? I'm pretty sure I didn't set any. >>> >>> Concerning LABEL=/ >>> I think you should check you bootloader config and change root=LABEL=/ to >>> root=/dev/sd.. That should do it. >> >> What files is that in? > > this is setup by your root environment. Normally in grub. There should be > something comparable on your pxe environment if you use it. > default from redhat: > [root@mobilix-01 ~]# cat /proc/cmdline > ro root=LABEL=/ rhgb quiet > sharedroot cluster: > [root@axqa03_1 ~]# cat /proc/cmdline > root=/dev/vg_axqa03_sr/lv_sharedroot com-step com-debug Oh, THAT root= parameter! Right. I'm feeling really stupid now. :'( Gordan |
From: Gordan B. <go...@bo...> - 2007-10-11 10:13:33
|
On Thu, 11 Oct 2007, Gordan Bobic wrote: >>>>>>> And, obviously, I'd need to make all this happen before the normal >>>>>>> boot process tries to mount the root disk. >>>>>> >>>>>> Do it before or right after scsi-start is called. >>>>> >>>>> I can't find any reference to "scsi-start". Where does this happen? >>>> >>>> It's scsi_start in linux.generic.sh Line 239. >>> >>> D'oh! What a difference an _ makes. >>> >>> I think the iSCSI stuff should be added before the dm_start stuff, which >>> is just before the scsi_start. >>> >>> Right, that seems to have worked. Almost there. Now I get: >>> >>> Mounting LABEL=/ on /mnt/newroot..device not found error [FAILED] >>> Mounting /cdsl.local on /cluster/cdsl/3..no cdsldir found >>> "/mnt/mewroot//cluster/cdsl" >>> Could not mount cdsl /cdsl.local to /cluster/cdsl/3. Exiting >>> >>> Where does it get the LABEL=/ from? I'm pretty sure I didn't set any. >> >> Concerning LABEL=/ >> I think you should check you bootloader config and change root=LABEL=/ to >> root=/dev/sd.. That should do it. > > What files is that in? Just looking through the initrd init script - what is supposed to be in /etc/sysconfig/comoonics-chroot ? It's mentioned in the comments, but I don't see it referenced in the actualy code. Gordan |
From: Marc G. <gr...@at...> - 2007-10-11 10:09:48
|
On Thursday 11 October 2007 11:54:16 Gordan Bobic wrote: > On Thu, 11 Oct 2007, Marc Grimme wrote: > >>>>>> And, obviously, I'd need to make all this happen before the normal > >>>>>> boot process tries to mount the root disk. > >>>>> > >>>>> Do it before or right after scsi-start is called. > >>>> > >>>> I can't find any reference to "scsi-start". Where does this happen? > >>> > >>> It's scsi_start in linux.generic.sh Line 239. > >> > >> D'oh! What a difference an _ makes. > >> > >> I think the iSCSI stuff should be added before the dm_start stuff, which > >> is just before the scsi_start. > >> > >> Right, that seems to have worked. Almost there. Now I get: > >> > >> Mounting LABEL=/ on /mnt/newroot..device not found error [FAILED] > >> Mounting /cdsl.local on /cluster/cdsl/3..no cdsldir found > >> "/mnt/mewroot//cluster/cdsl" > >> Could not mount cdsl /cdsl.local to /cluster/cdsl/3. Exiting > >> > >> Where does it get the LABEL=/ from? I'm pretty sure I didn't set any. > > > > Concerning LABEL=/ > > I think you should check you bootloader config and change root=LABEL=/ to > > root=/dev/sd.. That should do it. > > What files is that in? this is setup by your root environment. Normally in grub. There should be something comparable on your pxe environment if you use it. default from redhat: [root@mobilix-01 ~]# cat /proc/cmdline ro root=LABEL=/ rhgb quiet sharedroot cluster: [root@axqa03_1 ~]# cat /proc/cmdline root=/dev/vg_axqa03_sr/lv_sharedroot com-step com-debug > > Gordan > > ------------------------------------------------------------------------- > 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 -- 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 |
From: Gordan B. <go...@bo...> - 2007-10-11 09:54:18
|
On Thu, 11 Oct 2007, Marc Grimme wrote: >>>>>> And, obviously, I'd need to make all this happen before the normal >>>>>> boot process tries to mount the root disk. >>>>> >>>>> Do it before or right after scsi-start is called. >>>> >>>> I can't find any reference to "scsi-start". Where does this happen? >>> >>> It's scsi_start in linux.generic.sh Line 239. >> >> D'oh! What a difference an _ makes. >> >> I think the iSCSI stuff should be added before the dm_start stuff, which >> is just before the scsi_start. >> >> Right, that seems to have worked. Almost there. Now I get: >> >> Mounting LABEL=/ on /mnt/newroot..device not found error [FAILED] >> Mounting /cdsl.local on /cluster/cdsl/3..no cdsldir found >> "/mnt/mewroot//cluster/cdsl" >> Could not mount cdsl /cdsl.local to /cluster/cdsl/3. Exiting >> >> Where does it get the LABEL=/ from? I'm pretty sure I didn't set any. > > Concerning LABEL=/ > I think you should check you bootloader config and change root=LABEL=/ to > root=/dev/sd.. That should do it. What files is that in? Gordan |
From: Gordan B. <go...@bo...> - 2007-10-11 09:52:08
|
On Thu, 11 Oct 2007, Marc Grimme wrote: >> Right, that seems to have worked. Almost there. Now I get: >> >> Mounting LABEL=/ on /mnt/newroot..device not found error [FAILED] > > hmm. That looks weired. Have a look at /var/log/comoonics-boot.log or send it > and I can tell you more. > >> Mounting /cdsl.local on /cluster/cdsl/3..no cdsldir found >> "/mnt/mewroot//cluster/cdsl" >> Could not mount cdsl /cdsl.local to /cluster/cdsl/3. Exiting >> >> Where does it get the LABEL=/ from? I'm pretty sure I didn't set any. > > That's new for me as well. Where does the initrd get the root fs to mount? fstab? It looks like the RHEL5 install put the labels on for me. >>>>>> Or will specifying the iscsi stuff in cluster.conf make all this work? >>>>>> Given that the iscsi components weren't in the standard initrd, I'm >>>>>> not too convinced this will work (although there's a distinct >>>>>> possibility that this is totally unrelated and irrelevant in this >>>>>> case). >>>>> >>>>> Yes I agree. Make it work for you and we'll integrate it so it'll only >>>>> be called if iscsi is selected. >>>> >>>> LOL! I must say I'm not used to getting integrated into the development >>>> effort this quickly. Not that I don't mind. :-) >>> >>> We'll integrate it in preview and tag it as experimental. But as iscsi >>> integration is on our list but only in next major version we are happy to >>> use anything that is provided by others. >> >> It surprises me that the whole concept didn't start with iSCSI. How else >> can you provide a shared GFS root for a cluster? NBDs? Shared SCSI bus (2 >> controllers in 2 machines with the drives shared on the chain)? > > We started with SAN based on FibreChannel. Cause initially there was something > we found quite nice which was called DMEP or DLOCKs or something that did the > locking inside the SCSI-Protocol. But it didn't work out. > > iSCSI wasn't there and gnbd either. There was only FibreChannel or a shared > parallel scsi bus. Ah, I see! So, what you're really saying is that getting iSCSI to work is actually quite important. :-) Well, with a bit of luck, and help from you, I'll probably have it up and running by the time the day is up. :-) Speaking of which - would you prefer a patch for all the changes I made, or would a tar ball of the modified files suffice for inclusion in the rpms in the repository? Gordan |
From: Marc G. <gr...@at...> - 2007-10-11 09:44:05
|
On Thursday 11 October 2007 11:22:56 Gordan Bobic wrote: > On Thu, 11 Oct 2007, Marc Grimme wrote: > >>>>> So when the initrd gets the iscsi disk as scsi-disk all the rest > >>>>> should be done automatically. > >>>> > >>>> Where is the template startup script for the initrd? A few things > >>>> require a bit of manual intervention, because for some reason iscsid > >>>> doesn't trigger loading of iscsi_tcp module which is required _before_ > >>>> iscsid loads. > >>> > >>> linuxrc.generic.sh is the main init-script. > >> > >> Aha! I see now what all the talk about iscsi-lib.sh was. This is what > >> gets the parameters from the cluster.conf about the root source on iscsi > >> stuff. > >> > >> But what can this do without the iscsi tools being included in the > >> standard initrd? > >> > >> On a separte note, is this "old" iSCSI speciffic (i.e. pre-Open-iSCSI, > >> as i see mentions of Cisco), or is it just a convenient "dump your iSCSI > >> initialisation stuff here" script? > > > > You can ignore or use anything in iscsi-lib.sh. It is very old. And long > > ago RHEL3 and I can't remember much of it. As it was only a "study" to > > prove it works. > > Wow! This goes back as far as RHEL3? I'm impressed. :-) > > >>>> And, obviously, I'd need to make all this happen before the normal > >>>> boot process tries to mount the root disk. > >>> > >>> Do it before or right after scsi-start is called. > >> > >> I can't find any reference to "scsi-start". Where does this happen? > > > > It's scsi_start in linux.generic.sh Line 239. > > D'oh! What a difference an _ makes. > > I think the iSCSI stuff should be added before the dm_start stuff, which > is just before the scsi_start. > > Right, that seems to have worked. Almost there. Now I get: > > Mounting LABEL=/ on /mnt/newroot..device not found error [FAILED] > Mounting /cdsl.local on /cluster/cdsl/3..no cdsldir found > "/mnt/mewroot//cluster/cdsl" > Could not mount cdsl /cdsl.local to /cluster/cdsl/3. Exiting > > Where does it get the LABEL=/ from? I'm pretty sure I didn't set any. > > >>>> Or will specifying the iscsi stuff in cluster.conf make all this work? > >>>> Given that the iscsi components weren't in the standard initrd, I'm > >>>> not too convinced this will work (although there's a distinct > >>>> possibility that this is totally unrelated and irrelevant in this > >>>> case). > >>> > >>> Yes I agree. Make it work for you and we'll integrate it so it'll only > >>> be called if iscsi is selected. > >> > >> LOL! I must say I'm not used to getting integrated into the development > >> effort this quickly. Not that I don't mind. :-) > > > > We'll integrate it in preview and tag it as experimental. But as iscsi > > integration is on our list but only in next major version we are happy to > > use anything that is provided by others. > > It surprises me that the whole concept didn't start with iSCSI. How else > can you provide a shared GFS root for a cluster? NBDs? Shared SCSI bus (2 > controllers in 2 machines with the drives shared on the chain)? > > Gordan > > ------------------------------------------------------------------------- > 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 Concerning LABEL=/ I think you should check you bootloader config and change root=LABEL=/ to root=/dev/sd.. That should do it. -- 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 |
From: Marc G. <gr...@at...> - 2007-10-11 09:39:34
|
On Thursday 11 October 2007 11:22:56 Gordan Bobic wrote: > On Thu, 11 Oct 2007, Marc Grimme wrote: > >>>>> So when the initrd gets the iscsi disk as scsi-disk all the rest > >>>>> should be done automatically. > >>>> > >>>> Where is the template startup script for the initrd? A few things > >>>> require a bit of manual intervention, because for some reason iscsid > >>>> doesn't trigger loading of iscsi_tcp module which is required _before_ > >>>> iscsid loads. > >>> > >>> linuxrc.generic.sh is the main init-script. > >> > >> Aha! I see now what all the talk about iscsi-lib.sh was. This is what > >> gets the parameters from the cluster.conf about the root source on iscsi > >> stuff. > >> > >> But what can this do without the iscsi tools being included in the > >> standard initrd? > >> > >> On a separte note, is this "old" iSCSI speciffic (i.e. pre-Open-iSCSI, > >> as i see mentions of Cisco), or is it just a convenient "dump your iSCSI > >> initialisation stuff here" script? > > > > You can ignore or use anything in iscsi-lib.sh. It is very old. And long > > ago RHEL3 and I can't remember much of it. As it was only a "study" to > > prove it works. > > Wow! This goes back as far as RHEL3? I'm impressed. :-) It was started in 1999 or 2000 I don't rember exactly with some old SuSE version. > > >>>> And, obviously, I'd need to make all this happen before the normal > >>>> boot process tries to mount the root disk. > >>> > >>> Do it before or right after scsi-start is called. > >> > >> I can't find any reference to "scsi-start". Where does this happen? > > > > It's scsi_start in linux.generic.sh Line 239. > > D'oh! What a difference an _ makes. > > I think the iSCSI stuff should be added before the dm_start stuff, which > is just before the scsi_start. yes. agreed. > > Right, that seems to have worked. Almost there. Now I get: > > Mounting LABEL=/ on /mnt/newroot..device not found error [FAILED] hmm. That looks weired. Have a look at /var/log/comoonics-boot.log or send it and I can tell you more. > Mounting /cdsl.local on /cluster/cdsl/3..no cdsldir found > "/mnt/mewroot//cluster/cdsl" > Could not mount cdsl /cdsl.local to /cluster/cdsl/3. Exiting > > Where does it get the LABEL=/ from? I'm pretty sure I didn't set any. That's new for me as well. > > >>>> Or will specifying the iscsi stuff in cluster.conf make all this work? > >>>> Given that the iscsi components weren't in the standard initrd, I'm > >>>> not too convinced this will work (although there's a distinct > >>>> possibility that this is totally unrelated and irrelevant in this > >>>> case). > >>> > >>> Yes I agree. Make it work for you and we'll integrate it so it'll only > >>> be called if iscsi is selected. > >> > >> LOL! I must say I'm not used to getting integrated into the development > >> effort this quickly. Not that I don't mind. :-) > > > > We'll integrate it in preview and tag it as experimental. But as iscsi > > integration is on our list but only in next major version we are happy to > > use anything that is provided by others. > > It surprises me that the whole concept didn't start with iSCSI. How else > can you provide a shared GFS root for a cluster? NBDs? Shared SCSI bus (2 > controllers in 2 machines with the drives shared on the chain)? We started with SAN based on FibreChannel. Cause initially there was something we found quite nice which was called DMEP or DLOCKs or something that did the locking inside the SCSI-Protocol. But it didn't work out. iSCSI wasn't there and gnbd either. There was only FibreChannel or a shared parallel scsi bus. Marc -- Gruss / Regards, Marc Grimme Phone: +49-89 452 3538-14 http://www.atix.de/ http://www.open-sharedroot.org/ |
From: Gordan B. <go...@bo...> - 2007-10-11 09:23:04
|
On Thu, 11 Oct 2007, Marc Grimme wrote: >>>>> So when the initrd gets the iscsi disk as scsi-disk all the rest should >>>>> be done automatically. >>>> >>>> Where is the template startup script for the initrd? A few things >>>> require a bit of manual intervention, because for some reason iscsid >>>> doesn't trigger loading of iscsi_tcp module which is required _before_ >>>> iscsid loads. >>> >>> linuxrc.generic.sh is the main init-script. >> >> Aha! I see now what all the talk about iscsi-lib.sh was. This is what gets >> the parameters from the cluster.conf about the root source on iscsi stuff. >> >> But what can this do without the iscsi tools being included in the >> standard initrd? >> >> On a separte note, is this "old" iSCSI speciffic (i.e. pre-Open-iSCSI, as >> i see mentions of Cisco), or is it just a convenient "dump your iSCSI >> initialisation stuff here" script? > > You can ignore or use anything in iscsi-lib.sh. It is very old. And long ago > RHEL3 and I can't remember much of it. As it was only a "study" to prove it > works. Wow! This goes back as far as RHEL3? I'm impressed. :-) >>>> And, obviously, I'd need to make all this happen before the normal boot >>>> process tries to mount the root disk. >>> >>> Do it before or right after scsi-start is called. >> >> I can't find any reference to "scsi-start". Where does this happen? > > It's scsi_start in linux.generic.sh Line 239. D'oh! What a difference an _ makes. I think the iSCSI stuff should be added before the dm_start stuff, which is just before the scsi_start. Right, that seems to have worked. Almost there. Now I get: Mounting LABEL=/ on /mnt/newroot..device not found error [FAILED] Mounting /cdsl.local on /cluster/cdsl/3..no cdsldir found "/mnt/mewroot//cluster/cdsl" Could not mount cdsl /cdsl.local to /cluster/cdsl/3. Exiting Where does it get the LABEL=/ from? I'm pretty sure I didn't set any. >>>> Or will specifying the iscsi stuff in cluster.conf make all this work? >>>> Given that the iscsi components weren't in the standard initrd, I'm not >>>> too convinced this will work (although there's a distinct possibility >>>> that this is totally unrelated and irrelevant in this case). >>> >>> Yes I agree. Make it work for you and we'll integrate it so it'll only be >>> called if iscsi is selected. >> >> LOL! I must say I'm not used to getting integrated into the development >> effort this quickly. Not that I don't mind. :-) > > We'll integrate it in preview and tag it as experimental. But as iscsi > integration is on our list but only in next major version we are happy to use > anything that is provided by others. It surprises me that the whole concept didn't start with iSCSI. How else can you provide a shared GFS root for a cluster? NBDs? Shared SCSI bus (2 controllers in 2 machines with the drives shared on the chain)? Gordan |
From: Marc G. <gr...@at...> - 2007-10-11 08:59:17
|
On Thursday 11 October 2007 10:45:58 Gordan Bobic wrote: > On Thu, 11 Oct 2007, Marc Grimme wrote: > >>>> I have iscsi loading and letting me see the relevant shares. I can > >>>> mount them. But how do I then remount root to a GFS share on iSCSI? > >>>> > >>>> I tried: > >>>> > >>>> mount -t gfs -o lockproto=lock_nolock,remount /dev/sdb2 / > >>> > >>> Normally the bootimage itself should take over the mounting. You should > >>> not bother with it. I don't know if you can easily remout a gfs with > >>> changing the lockproto. So as you don't get any errors and it didn't do > >>> anything it does not work. > >>> > >>> But again, normally the initrd mounts the gfs filesystem you specified > >>> within you cluster.conf. We didn't test with raw-devices we are always > >>> using LVM/CLVM lvs for doing the mount. > >> > >> I'm not convinced the problem is in the lack of (C)LVM. > > > > Me either and I didn't say so. I just more or less said it is best > > practice to use (C)LVM and yes it is not required. But we don't test > > without so I don't know if it really works although it should. > > I must say I'm not a fan of LVM, clustered or otherwise. It seems like yet > another technology to solve a problem that doesn't exist - or at least > shouldn't with even a small amount of forward planning. And it's made > doubly redudant when you consider that modern RAID, both hardware and > Linux software, allows transparent on-line growing of RAID by adding > additional disks/controllers. > > >>> So when the initrd gets the iscsi disk as scsi-disk all the rest should > >>> be done automatically. > >> > >> Where is the template startup script for the initrd? A few things > >> require a bit of manual intervention, because for some reason iscsid > >> doesn't trigger loading of iscsi_tcp module which is required _before_ > >> iscsid loads. > > > > linuxrc.generic.sh is the main init-script. > > Aha! I see now what all the talk about iscsi-lib.sh was. This is what gets > the parameters from the cluster.conf about the root source on iscsi stuff. > > But what can this do without the iscsi tools being included in the > standard initrd? > > On a separte note, is this "old" iSCSI speciffic (i.e. pre-Open-iSCSI, as > i see mentions of Cisco), or is it just a convenient "dump your iSCSI > initialisation stuff here" script? You can ignore or use anything in iscsi-lib.sh. It is very old. And long ago RHEL3 and I can't remember much of it. As it was only a "study" to prove it works. > > >> And, obviously, I'd need to make all this happen before the normal boot > >> process tries to mount the root disk. > > > > Do it before or right after scsi-start is called. > > I can't find any reference to "scsi-start". Where does this happen? It's scsi_start in linux.generic.sh Line 239. > > >> Or will specifying the iscsi stuff in cluster.conf make all this work? > >> Given that the iscsi components weren't in the standard initrd, I'm not > >> too convinced this will work (although there's a distinct possibility > >> that this is totally unrelated and irrelevant in this case). > > > > Yes I agree. Make it work for you and we'll integrate it so it'll only be > > called if iscsi is selected. > > LOL! I must say I'm not used to getting integrated into the development > effort this quickly. Not that I don't mind. :-) We'll integrate it in preview and tag it as experimental. But as iscsi integration is on our list but only in next major version we are happy to use anything that is provided by others. > > I must say that I'm now thinking that the idea of configuring iscsi stuff > via cluster.conf is kind of neat. But I'll get it running the "manual" way > first, as I think it'll be easier to debug until I get it running. > > Now if only I can figure out what you meant by scsi-start - grep finds > nothing. :-( see above. > > Gordan > > P.S. > > Any chance we can get the mailing list to set the ReplyTo header to go > back to the list? > > ------------------------------------------------------------------------- > 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 -- 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 |
From: Gordan B. <go...@bo...> - 2007-10-11 08:53:31
|
Is there a change log for the comoonics-bootimage released in the past 24 hours? I just want to make sure it didn't end up clobbering any of the changes I've made to my setup. Gordan |
From: Gordan B. <go...@bo...> - 2007-10-11 08:46:05
|
On Thu, 11 Oct 2007, Marc Grimme wrote: >>>> I have iscsi loading and letting me see the relevant shares. I can mount >>>> them. But how do I then remount root to a GFS share on iSCSI? >>>> >>>> I tried: >>>> >>>> mount -t gfs -o lockproto=lock_nolock,remount /dev/sdb2 / >>> >>> Normally the bootimage itself should take over the mounting. You should >>> not bother with it. I don't know if you can easily remout a gfs with >>> changing the lockproto. So as you don't get any errors and it didn't do >>> anything it does not work. >>> >>> But again, normally the initrd mounts the gfs filesystem you specified >>> within you cluster.conf. We didn't test with raw-devices we are always >>> using LVM/CLVM lvs for doing the mount. >> >> I'm not convinced the problem is in the lack of (C)LVM. > > Me either and I didn't say so. I just more or less said it is best practice to > use (C)LVM and yes it is not required. But we don't test without so I don't > know if it really works although it should. I must say I'm not a fan of LVM, clustered or otherwise. It seems like yet another technology to solve a problem that doesn't exist - or at least shouldn't with even a small amount of forward planning. And it's made doubly redudant when you consider that modern RAID, both hardware and Linux software, allows transparent on-line growing of RAID by adding additional disks/controllers. >>> So when the initrd gets the iscsi disk as scsi-disk all the rest should >>> be done automatically. >> >> Where is the template startup script for the initrd? A few things require >> a bit of manual intervention, because for some reason iscsid doesn't >> trigger loading of iscsi_tcp module which is required _before_ iscsid >> loads. > > linuxrc.generic.sh is the main init-script. Aha! I see now what all the talk about iscsi-lib.sh was. This is what gets the parameters from the cluster.conf about the root source on iscsi stuff. But what can this do without the iscsi tools being included in the standard initrd? On a separte note, is this "old" iSCSI speciffic (i.e. pre-Open-iSCSI, as i see mentions of Cisco), or is it just a convenient "dump your iSCSI initialisation stuff here" script? >> And, obviously, I'd need to make all this happen before the normal boot >> process tries to mount the root disk. > > Do it before or right after scsi-start is called. I can't find any reference to "scsi-start". Where does this happen? >> Or will specifying the iscsi stuff in cluster.conf make all this work? >> Given that the iscsi components weren't in the standard initrd, I'm not >> too convinced this will work (although there's a distinct possibility that >> this is totally unrelated and irrelevant in this case). > > Yes I agree. Make it work for you and we'll integrate it so it'll only be > called if iscsi is selected. LOL! I must say I'm not used to getting integrated into the development effort this quickly. Not that I don't mind. :-) I must say that I'm now thinking that the idea of configuring iscsi stuff via cluster.conf is kind of neat. But I'll get it running the "manual" way first, as I think it'll be easier to debug until I get it running. Now if only I can figure out what you meant by scsi-start - grep finds nothing. :-( Gordan P.S. Any chance we can get the mailing list to set the ReplyTo header to go back to the list? |
From: Marc G. <gr...@at...> - 2007-10-11 08:24:04
|
On Thursday 11 October 2007 10:10:42 Gordan Bobic wrote: > On Thu, 11 Oct 2007, Marc Grimme wrote: > >> I have iscsi loading and letting me see the relevant shares. I can mount > >> them. But how do I then remount root to a GFS share on iSCSI? > >> > >> I tried: > >> > >> mount -t gfs -o lockproto=lock_nolock,remount /dev/sdb2 / > > > > Normally the bootimage itself should take over the mounting. You should > > not bother with it. I don't know if you can easily remout a gfs with > > changing the lockproto. So as you don't get any errors and it didn't do > > anything it does not work. > > > > But again, normally the initrd mounts the gfs filesystem you specified > > within you cluster.conf. We didn't test with raw-devices we are always > > using LVM/CLVM lvs for doing the mount. > > I'm not convinced the problem is in the lack of (C)LVM. Me either and I didn't say so. I just more or less said it is best practice to use (C)LVM and yes it is not required. But we don't test without so I don't know if it really works although it should. > > > So when the initrd gets the iscsi disk as scsi-disk all the rest should > > be done automatically. > > Where is the template startup script for the initrd? A few things require > a bit of manual intervention, because for some reason iscsid doesn't > trigger loading of iscsi_tcp module which is required _before_ iscsid > loads. linuxrc.generic.sh is the main init-script. > > And, obviously, I'd need to make all this happen before the normal boot > process tries to mount the root disk. Do it before or right after scsi-start is called. > > Or will specifying the iscsi stuff in cluster.conf make all this work? > Given that the iscsi components weren't in the standard initrd, I'm not > too convinced this will work (although there's a distinct possibility that > this is totally unrelated and irrelevant in this case). Yes I agree. Make it work for you and we'll integrate it so it'll only be called if iscsi is selected. > > > To test it switch on com-step and break where scsi is detected. Setup you > > iscsi stuff and exit and let the initrd init process do the rest. > > That should work. > > OK. Where is the initrd init script? linuxrc.generic.sh. Marc -- 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 |
From: Gordan B. <go...@bo...> - 2007-10-11 08:10:56
|
On Thu, 11 Oct 2007, Marc Grimme wrote: >> I have iscsi loading and letting me see the relevant shares. I can mount >> them. But how do I then remount root to a GFS share on iSCSI? >> >> I tried: >> >> mount -t gfs -o lockproto=lock_nolock,remount /dev/sdb2 / > > Normally the bootimage itself should take over the mounting. You should not > bother with it. I don't know if you can easily remout a gfs with changing the > lockproto. So as you don't get any errors and it didn't do anything it does > not work. > > But again, normally the initrd mounts the gfs filesystem you specified within > you cluster.conf. We didn't test with raw-devices we are always using > LVM/CLVM lvs for doing the mount. I'm not convinced the problem is in the lack of (C)LVM. > So when the initrd gets the iscsi disk as scsi-disk all the rest should be > done automatically. Where is the template startup script for the initrd? A few things require a bit of manual intervention, because for some reason iscsid doesn't trigger loading of iscsi_tcp module which is required _before_ iscsid loads. And, obviously, I'd need to make all this happen before the normal boot process tries to mount the root disk. Or will specifying the iscsi stuff in cluster.conf make all this work? Given that the iscsi components weren't in the standard initrd, I'm not too convinced this will work (although there's a distinct possibility that this is totally unrelated and irrelevant in this case). > To test it switch on com-step and break where scsi is detected. Setup you > iscsi stuff and exit and let the initrd init process do the rest. > That should work. OK. Where is the initrd init script? Gordan |