Menu
▾
▴
open-sharedroot-devel — Mailinglist for developer discussions
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: Marc G. <gr...@at...> - 2007-10-11 08:02:37
|
On Thursday 11 October 2007 09:48:34 Gordan Bobic wrote: > Guys, > > 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. So when the initrd gets the iscsi disk as scsi-disk all the rest should be done automatically. 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. Regards Marc. > > But this doesn't seem to do anything. No errors get reported, it just > doesn't do it. > > Any ideas? Should this work? Or do I have to mount the new root somewhere > else and then chroot into it and fire up init - or something like that? > > 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 07:53:19
|
I just had a slightly different idea about all this. There appear to be iSCSI initiator tools to get the root fs over iSCSI working. If this works, then would it not be better to just use that to just get the iSCSI boot-strapped, mount the gfs with lock_nolock read-only, use that to get the init booting, get the cman/fence working, and then remount root r/w with lock_dlm? Would this not yield a smaller initrd and simplify the process? What would be the drawbacks of this approach? Gordan |
|
From: Gordan B. <go...@bo...> - 2007-10-11 07:48:42
|
Guys, 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 / But this doesn't seem to do anything. No errors get reported, it just doesn't do it. Any ideas? Should this work? Or do I have to mount the new root somewhere else and then chroot into it and fire up init - or something like that? Gordan |
|
From: Marc G. <gr...@at...> - 2007-10-11 07:35:56
|
On Thursday 11 October 2007 09:21:32 Gordan Bobic wrote: > On Wed, 10 Oct 2007, Marc Grimme wrote: > > On Wednesday 10 October 2007 19:57:50 Gordan Bobic wrote: > >> Does mkinitrd resolve RPM dependencies? Or does it only extract the RPMS > >> listed (and then only the subsets specified)? > > > > It does not resolve it only extracts. That would have been too hard and > > then we'll end up with a whole distro in initrd. > > Well, rpm -q --requires gives you a dependency chain to follow, so it's > not particularly hard to resolve the dependencies. But when a bare minimum > of a distribution still requires 180MB of the glibc in the default > installation, one starts to wonder if maybe it's all gone horribly > wrong... We didn't include and think about deps because of this and many other reasons. > > >> I'm trying to put together a list of what is required to fire up the > >> iscsi subsystem, and I'm starting to get a feeling that it won't be long > >> before I might as well put the whole distro into the initrd. :-( > > > > No you don't need gnome and X11. ;-) > > You know, that's a little too close to the truth to be funny... :-/ There is no option, if you build a sharedroot cluster you need a bigger initrd (gzip ~ 50MB is still acceptable). Cause all clusterservices that influence cluster recovery need to run outside the rootfs. Regards 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/ |
|
From: Gordan B. <go...@bo...> - 2007-10-11 07:21:35
|
On Wed, 10 Oct 2007, Marc Grimme wrote: > On Wednesday 10 October 2007 19:57:50 Gordan Bobic wrote: >> Does mkinitrd resolve RPM dependencies? Or does it only extract the RPMS >> listed (and then only the subsets specified)? > > It does not resolve it only extracts. That would have been too hard and then > we'll end up with a whole distro in initrd. Well, rpm -q --requires gives you a dependency chain to follow, so it's not particularly hard to resolve the dependencies. But when a bare minimum of a distribution still requires 180MB of the glibc in the default installation, one starts to wonder if maybe it's all gone horribly wrong... >> I'm trying to put together a list of what is required to fire up the iscsi >> subsystem, and I'm starting to get a feeling that it won't be long before >> I might as well put the whole distro into the initrd. :-( > > No you don't need gnome and X11. ;-) You know, that's a little too close to the truth to be funny... :-/ Gordan |
|
From: Marc G. <gr...@at...> - 2007-10-10 19:00:34
|
On Wednesday 10 October 2007 19:57:50 Gordan Bobic wrote: > Does mkinitrd resolve RPM dependencies? Or does it only extract the RPMS > listed (and then only the subsets specified)? It does not resolve it only extracts. That would have been too hard and then we'll end up with a whole distro in initrd. > > I'm trying to put together a list of what is required to fire up the iscsi > subsystem, and I'm starting to get a feeling that it won't be long before > I might as well put the whole distro into the initrd. :-( No you don't need gnome and X11. ;-) 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: Marc G. <gr...@at...> - 2007-10-10 18:58:57
|
On Wednesday 10 October 2007 19:06:35 Gordan Bobic wrote:
> Below is a patch to fix this problem.
> Without the first part being in double quotes, empty strings break the
> != comparison.
> With the first part being in double quotes, spaces break things.
>
> So we do two comparisons instead of one. There's probably a neat way to
> combine this, but this works. :-)
Great thanks very much. We'll test it and it'll be in the next release.
Regards Marc.
>
> Gordan
>
> /opt/atix/comoonics-bootimage/boot-scripts/etc/chroot-lib.sh
>
> --- chroot-lib.sh 2007-10-10 18:01:33.000000000 +0100
> +++ chroot-lib.sh.new 2007-10-10 18:01:50.000000000 +0100
> @@ -330,6 +330,7 @@
> # FIXME:
> # if [ "${line:0:1}" != '#' ]; then does not work. Don't know
> WHY the shit!!
> #
> + if [ "${line:0:1}" ]; then
> if [ ${line:0:1} != '#' ]; then
> if [ ! -e "$line" ] && [ "${line:0:7}" = '@perlcc' ]; then
> # take next as filename and compile
> @@ -392,6 +393,7 @@
> get_dependent_files $filename
> fi
> fi
> + fi
> done <$filename
> }
> #************ get_all_files_dependent
>
> -------------------------------------------------------------------------
> 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-10 17:58:00
|
Does mkinitrd resolve RPM dependencies? Or does it only extract the RPMS listed (and then only the subsets specified)? I'm trying to put together a list of what is required to fire up the iscsi subsystem, and I'm starting to get a feeling that it won't be long before I might as well put the whole distro into the initrd. :-( Gordan |
|
From: Gordan B. <go...@bo...> - 2007-10-10 17:06:51
|
Below is a patch to fix this problem.
Without the first part being in double quotes, empty strings break the
!= comparison.
With the first part being in double quotes, spaces break things.
So we do two comparisons instead of one. There's probably a neat way to
combine this, but this works. :-)
Gordan
/opt/atix/comoonics-bootimage/boot-scripts/etc/chroot-lib.sh
--- chroot-lib.sh 2007-10-10 18:01:33.000000000 +0100
+++ chroot-lib.sh.new 2007-10-10 18:01:50.000000000 +0100
@@ -330,6 +330,7 @@
# FIXME:
# if [ "${line:0:1}" != '#' ]; then does not work. Don't know
WHY the shit!!
#
+ if [ "${line:0:1}" ]; then
if [ ${line:0:1} != '#' ]; then
if [ ! -e "$line" ] && [ "${line:0:7}" = '@perlcc' ]; then
# take next as filename and compile
@@ -392,6 +393,7 @@
get_dependent_files $filename
fi
fi
+ fi
done <$filename
}
#************ get_all_files_dependent
|
|
From: Gordan B. <go...@bo...> - 2007-10-10 15:35:52
|
On Wed, 10 Oct 2007, Marc Grimme wrote: >>> no the iscsid.conf should be created from cluster.conf. Because of the ip >>> of the iscsi-source. It might be one server gets it root from on >>> iscsi-device and another from another iscsi-device. >>> Some customers have clusters with different roots for different nodes. >> >> Err - I thought this was about _shared_ roots, not unshared-roots. :-p > > Yes it still is. One cluster with root x and another with root y but still in > the same cluster. ;-) >> What makes iscsid.conf from cluster.conf, then? > You. ;-) That seems contradictory. Do I create the iscsid.conf myself, or does it get created from cluster.conf? If I create it myself, then it should arguably be copied by the initrd maker from the source machine - at least in cases where the machines in the cluster all use the same root. > That has to be done. I don't remember how it looks like. I implemented it a > long time ago. But wouldn't it do it to just copy a template /etc/iscsi.conf > into the initrd and then add the lines for the device from the cluster.conf. > You should get the value for the rootsource as described on my blog. That's what I was saying - the initrd maker needs to include /etc/iscsi/iscsid.conf in the initrd. >> And what would configure the /var/lib/iscsi/*? > > Hmm. What is in there? The iscsi device information yielded by the iscsi discovery step. What I usually do is set iscsid.conf to "manual" and put the username/password for the share there. Then I do iSCSI discovery, and modify the file for the share I want to mount to set that share connecting to "automatic". Only the automatic shares get automatically attached to /dev/sd? nodes. Then I can mount the device as a normal block device. So, if this is to be automated, it would need to copy the pre-prepared /var/lib/iscsi/* files into the initrd. Unless you're about to tell me that there is a better, auto-magical way to achieve all this, purely from the cluster.conf file. >> I've found I have to jump through a few hoops to get this working even >> without the shared GFS. I have to set up connections to manual, and set >> the username/password up in iscsid.conf, then do the iscsi discovery, then > > Uhh, username/password. > Ahh rootsource="iscsi://username:password@iscsi-ip:port/" that sound not too > bad. You'd need the iSCSI volume ID in there as well somehow. This would typically look something like the following: iqn.2001-05.com.mydomain:x-xxxxxx-xxxxxxxxx-xxxxxxxxxxxxxxxx-nodename where x is a hex number. >> just change the volume I want to mount to automatic. Then it correctly >> mounts on the correct /dev/sd? device. > > Ok these commands should be added to iscsiLoad in > boot-scripts/etc/iscsi-lib.sh. That sounds a tad complicated for something to build at start-up. I think just including the iscsid.conf and /var/log/iscsi/* would be a better option. >>>> 3) Add iscsi and iscsid init scripts to the relevant run-level on OSR >>>> initrd. >>> >>> there are no run-levels inside the initrd ;-( . So the starting has to be >>> done manually within iscsi-lib and the iscsiLoad Function. >> >> Well, run-levels aren't what I meant as such. Are init scripts handled in >> a similar way to the full setup? Even if it is a startup script invoking: >> iscsid start >> iscsi start > This can easily be done why not. Cannot think of anything against it. OK. I just wanted to make sure I'm following the intended paradigm, rather than start mixing BSD ways with SystemV ways. :-) >> I have yet to get a single node booting off GFS as root. I'm some way off >> having a whole cluster running at the moment. Need to get the iSCSI >> working first. > Yes. > This takes some time. But is nice when it is running. Do entries in: /etc/comoonics/bootimage/files.initrd.d/* support wildcards? i.e. can I just include a line in a file that says: /var/lib/iscsi/* ? >>> rootvolume has to be given always. It tells where to mount the rootfs >>> from. rootsource is optional: I would use it for telling the cluster that >>> the rootdevice itself is an iscsione and the ipadress is x.y.z. >> >> Right, OK. But before this can work, surely the iscsi daemons have to be >> running first? > > If so start them before. Where is the template init script file that ends up on the initrd? Presumably that is where I would need to add this. >>> com-expert: imediately starts a shell after initrd is loaded. >> >> Well, at the moment it fails with the message that it can't find root and >> drops me to the initrd shell. What I need at that point is functioning >> iscsi components. I think that is logically the next thing I need to add >> to the initrd. > > exactly ;-) If/when I can get this working, do you want me to post the changes/patch here? I would have thought that most people who use SANs/GFS would be needing iSCSI support. Gordan |
|
From: Gordan B. <go...@bo...> - 2007-10-10 14:22:24
|
While building the initrd on CentOS5 (RHEL5): Copying files...cp: cannot stat `/etc/profile.d/krb5.csh': No such file or directory cp: cannot stat `/etc/profile.d/krb5.sh': No such file or directory krb5.sh and krb5.csh appear to have been removed from the distributions. They don't appear in Fedora 7+ or RHEL5+. They were only there up to and including FC6/RHEL4.x. Perhaps they should be removed from the list of things to bundle into the initrd? Gordan |
|
From: Marc G. <gr...@at...> - 2007-10-10 14:03:11
|
On Wednesday 10 October 2007 15:45:37 Gordan Bobic wrote: > On Wed, 10 Oct 2007, Marc Grimme wrote: > > no the iscsid.conf should be created from cluster.conf. Because of the ip > > of the iscsi-source. It might be one server gets it root from on > > iscsi-device and another from another iscsi-device. > > Some customers have clusters with different roots for different nodes. > > Err - I thought this was about _shared_ roots, not unshared-roots. :-p Yes it still is. One cluster with root x and another with root y but still in the same cluster. ;-) > What makes iscsid.conf from cluster.conf, then? You. ;-) That has to be done. I don't remember how it looks like. I implemented it a long time ago. But wouldn't it do it to just copy a template /etc/iscsi.conf into the initrd and then add the lines for the device from the cluster.conf. You should get the value for the rootsource as described on my blog. > And what would configure the /var/lib/iscsi/*? Hmm. What is in there? > I've found I have to jump through a few hoops to get this working even > without the shared GFS. I have to set up connections to manual, and set > the username/password up in iscsid.conf, then do the iscsi discovery, then Uhh, username/password. Ahh rootsource="iscsi://username:password@iscsi-ip:port/" that sound not too bad. > just change the volume I want to mount to automatic. Then it correctly > mounts on the correct /dev/sd? device. Ok these commands should be added to iscsiLoad in boot-scripts/etc/iscsi-lib.sh. > > >> 3) Add iscsi and iscsid init scripts to the relevant run-level on OSR > >> initrd. > > > > there are no run-levels inside the initrd ;-( . So the starting has to be > > done manually within iscsi-lib and the iscsiLoad Function. > > Well, run-levels aren't what I meant as such. Are init scripts handled in > a similar way to the full setup? Even if it is a startup script invoking: > iscsid start > iscsi start This can easily be done why not. Cannot think of anything against it. > I have yet to get a single node booting off GFS as root. I'm some way off > having a whole cluster running at the moment. Need to get the iSCSI > working first. Yes. This takes some time. But is nice when it is running. > > > > > rootvolume has to be given always. It tells where to mount the rootfs > > from. rootsource is optional: I would use it for telling the cluster that > > the rootdevice itself is an iscsione and the ipadress is x.y.z. > > Right, OK. But before this can work, surely the iscsi daemons have to be > running first? If so start them before. > > com-expert: imediately starts a shell after initrd is loaded. > > Well, at the moment it fails with the message that it can't find root and > drops me to the initrd shell. What I need at that point is functioning > iscsi components. I think that is logically the next thing I need to add > to the initrd. exactly ;-) > > > > It is but RHEL5 has slightly different packages. > > Right - so in theory, once there are multiple machines running, they'll > all wait in initrd for enough machines to reach quorum, and then mount the > root and proceed from there? exactly. > > 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 Have fun and don't lose temper -- 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 |
|
From: Gordan B. <go...@bo...> - 2007-10-10 13:45:42
|
On Wed, 10 Oct 2007, Marc Grimme wrote: >>>> 2.1) Extracting rpms...Cannot find rpm "comoonics-cs". Skipping. >>>> Cannot find rpm "GFS". Skipping. >>>> Cannot find rpm "ccs". Skipping. >>>> Cannot find rpm "dlm". Skipping. >>>> Cannot find rpm "fence". Skipping. >>>> Cannot find rpm "magma". Skipping. >>>> Cannot find rpm "magma-plugins". Skipping. >>>> Cannot find rpm "OpenIPMI-tools". Skipping. >>>> >>>> Where can these be found, and where should they be put for this step to >>>> find them? >>> >>> Follow the instructions on >>> http://www.opensharedroot.org/documentation/rhel5-gfs-shared-root-mini-ho >>> wto >> >> I did. Nowhere does it manage yum installing packages GFS, ccs, dlm, >> fence, magma, magma-plugins or OpenIPMI-tools. > > Hm. you still seem to have old depfiles. Remove the comoonics-bootimage rpms > and delete /etc/comoonics/bootimage and reinstall. This should go away then: > [root@axqa03_1 ~]# mkinitrd /boot/initrd_sr-2.6.18-52.el5xen.img > 2.6.18-52.el5xen > Extracting rpms...Cannot find rpm "comoonics-cs". Skipping. > Cannot find rpm "OpenIPMI-tools". Skipping. > [ OK ] > Retrieving dependent > files.../opt/atix/comoonics-bootimage/boot-scripts/etc/chroot-lib.sh: line > 333: [: !=: unary operator expected > found 4306 [ OK ] > Copying files...cp: cannot stat `/etc/profile.d/krb5.csh': No such file or > directory > cp: cannot stat `/etc/profile.d/krb5.sh': No such file or directory > cp: cannot stat `/etc/sysconfig/comoonics-chroot': No such file or directory > [ OK ] > Copying kernelmodules (2.6.18-52.el5xen)... [ OK ] > builddate_file [ OK ] > [ OK ] > Post settings .. [ OK ] > Cpio and compress.. [ OK ] > Cleaning up (/tmp/initrd.mnt.G24645, )... [ OK ] > -rw-r--r-- 1 root root 42731 Oct 10 14:42 /boot/initrd_sr-2.6.18-52.el5xen.img The problem went away when I manually yum installed comoonics-cs and OpenIPMI-tools RPMs. >>>> 3) iSCSI - this doesn't appear to get included on the initrd. This is >>>> kind of important. How do I add it, so that I can mount the SAN being >>>> used for the shared GFS root? >>> >>> We did not implement it yet. Feel free to do it. Use the latest rpms and >>> adapt the code. Latest HEAD rpms are attached. >>> Please edit against them. And send either patches or the changed files >>> directly to me. >> >> OK. Presumably, this would mean: >> >> 1) Install standard iscsi-initiator-utils rpm into the OSR initrd. > > yes. >> 2) Copy the /etc/iscsi/iscsid.conf /var/lib/iscsi/* into the OSR initrd > > no the iscsid.conf should be created from cluster.conf. Because of the ip of > the iscsi-source. It might be one server gets it root from on iscsi-device > and another from another iscsi-device. > Some customers have clusters with different roots for different nodes. Err - I thought this was about _shared_ roots, not unshared-roots. :-p What makes iscsid.conf from cluster.conf, then? And what would configure the /var/lib/iscsi/*? I've found I have to jump through a few hoops to get this working even without the shared GFS. I have to set up connections to manual, and set the username/password up in iscsid.conf, then do the iscsi discovery, then just change the volume I want to mount to automatic. Then it correctly mounts on the correct /dev/sd? device. >> 3) Add iscsi and iscsid init scripts to the relevant run-level on OSR >> initrd. > > there are no run-levels inside the initrd ;-( . So the starting has to be done > manually within iscsi-lib and the iscsiLoad Function. Well, run-levels aren't what I meant as such. Are init scripts handled in a similar way to the full setup? Even if it is a startup script invoking: iscsid start iscsi start >> On a separate note - the instructions say that /etc/sysconfig/network is >> to be unshared. > Yes. Because of the hostsname. >> I think /etc/sysconfig/network-scripts should be unshared, >> too, unless all IPs are assigned via DHCP - which may or may not be the >> case. Although if they were assigned by DHCP, that would be kind of neat > > Yes, every ifcfg-eth? has to be hostdependent. Unless using dhcp. >> because it would mean you can purely network boot them via PXE (even if >> the initrd is 50MB+!). > > It once worked that customers had the ip=dhcp in the cluster.conf and it got > its clusterip from a dhcp server. If you like give it a try. I have yet to get a single node booting off GFS as root. I'm some way off having a whole cluster running at the moment. Need to get the iSCSI working first. >>> Find more information here: >>> http://www.opensharedroot.org/Members/marc/blog/comoonics-bootimage/conce >>> pt-of-integrating-iscsi-support-to-latest-bootimage You should be able to >>> add comments or just send me an email on what you think. >> >> Hmm. Do we need this specified in cluster.conf? >> Are the rootsource, rootvolume and chrootenv tags the standard way to >> achieve this? > > rootvolume has to be given always. It tells where to mount the rootfs from. > rootsource is optional: I would use it for telling the cluster that the > rootdevice itself is an iscsione and the ipadress is x.y.z. Right, OK. But before this can work, surely the iscsi daemons have to be running first? >>> If you need more bins or rpms included in the initrd (which I expect to >>> be) have a look at /etc/comoonics/bootimage/files.initrd.d >>> and /etc/comoonics/bootimage/rpms.initrd.d. >> >> Thanks for that. Do you envisage anything over and above what I listed >> above to be required? I'm not quite up to speed on the cluster.conf stuff, >> but would the 3 steps to get iSCSI going be sufficient to get the initrd >> connectable to the SAN at least? Once it gets that far, even mounting the >> root manually wouldn't be too bad. > > To do anything manually you can always use two or better three nice options at > bootcmdline: > com-debug: switches on debugging. > com-step: adds steps to the bootprocess where you can jump into a shell with > break and leave and continue the bootprocess with exit. > com-expert: imediately starts a shell after initrd is loaded. Well, at the moment it fails with the message that it can't find root and drops me to the initrd shell. What I need at that point is functioning iscsi components. I think that is logically the next thing I need to add to the initrd. >> Incidentally, how is the fencing/cluster stuff handled in the initrd? I >> didn't notice cman being included. > > It is but RHEL5 has slightly different packages. Right - so in theory, once there are multiple machines running, they'll all wait in initrd for enough machines to reach quorum, and then mount the root and proceed from there? Gordan |
|
From: Marc G. <gr...@at...> - 2007-10-10 13:30:19
|
On Wednesday 10 October 2007 14:59:25 Gordan Bobic wrote: > On Wed, 10 Oct 2007, Marc Grimme wrote: > >> 1) Python libraries assume python 2.3. RHEL5 (CentOS5 in my case) uses > >> python 2.4. That means that if this is intended for RHEL5, the libraries > >> should end up in /usr/lib/python2.4/site-packages/comoonics > >> At the moment, they end up in > >> /usr/lib/python2.3/site-packages/comoonics, which means they don't work. > > > > There should be a rhel5 channel available. It's not yet official but it > > proves to be quite stable. We are right now in the last steps before > > qa-ing. Use the following yum.repositories. > > > > [comoonics-preview] > > name=Packages for the comoonics shared root cluster > > baseurl=http://download.atix.de/yum/comoonics/redhat-el5/preview/noarch/ > > enabled=1 > > gpgcheck=1 > > gpgkey=http://download.atix.de/yum/comoonics/comoonics-RPM-GPG.key > > > > [comoonics-preview-i386] > > name=Packages for the comoonics shared root cluster > > baseurl=http://download.atix.de/yum/comoonics/redhat-el5/preview/$arch > > enabled=1 > > gpgcheck=1 > > gpgkey=http://download.atix.de/yum/comoonics/comoonics-RPM-GPG.key > > > > [comoonics-addons] > > name=Addon Packages for utilities > > baseurl=http://download.atix.de/yum/comoonics/redhat-el5/addons/noarch/ > > enabled=1 > > gpgcheck=1 > > gpgkey=http://download.atix.de/yum/comoonics/comoonics-RPM-GPG.key > > > > That will be anounced recently on www.opensharedroot.org. > > OK, that seems to solve the problem of el4 packages creeping in and > breaking things. :-) > > >> 2) When making the initrd: > >> > >> 2.1) Extracting rpms...Cannot find rpm "comoonics-cs". Skipping. > >> Cannot find rpm "GFS". Skipping. > >> Cannot find rpm "ccs". Skipping. > >> Cannot find rpm "dlm". Skipping. > >> Cannot find rpm "fence". Skipping. > >> Cannot find rpm "magma". Skipping. > >> Cannot find rpm "magma-plugins". Skipping. > >> Cannot find rpm "OpenIPMI-tools". Skipping. > >> > >> Where can these be found, and where should they be put for this step to > >> find them? > > > > Follow the instructions on > > http://www.opensharedroot.org/documentation/rhel5-gfs-shared-root-mini-ho > >wto > > I did. Nowhere does it manage yum installing packages GFS, ccs, dlm, > fence, magma, magma-plugins or OpenIPMI-tools. Hm. you still seem to have old depfiles. Remove the comoonics-bootimage rpms and delete /etc/comoonics/bootimage and reinstall. This should go away then: [root@axqa03_1 ~]# mkinitrd /boot/initrd_sr-2.6.18-52.el5xen.img 2.6.18-52.el5xen Extracting rpms...Cannot find rpm "comoonics-cs". Skipping. Cannot find rpm "OpenIPMI-tools". Skipping. [ OK ] Retrieving dependent files.../opt/atix/comoonics-bootimage/boot-scripts/etc/chroot-lib.sh: line 333: [: !=: unary operator expected found 4306 [ OK ] Copying files...cp: cannot stat `/etc/profile.d/krb5.csh': No such file or directory cp: cannot stat `/etc/profile.d/krb5.sh': No such file or directory cp: cannot stat `/etc/sysconfig/comoonics-chroot': No such file or directory [ OK ] Copying kernelmodules (2.6.18-52.el5xen)... [ OK ] builddate_file [ OK ] [ OK ] Post settings .. [ OK ] Cpio and compress.. [ OK ] Cleaning up (/tmp/initrd.mnt.G24645, )... [ OK ] -rw-r--r-- 1 root root 42731 Oct 10 14:42 /boot/initrd_sr-2.6.18-52.el5xen.img > > >> 2.2) Retrieving dependent > >> files.../opt/atix/comoonics-bootimage/boot-scripts/etc/chroot-lib.sh: > >> line 333: [: !=: unary operator expected > > > > you can ignore that. > > > >> found 3545 > >> > >> What is actually causing this? I looked at the script, and I have a > >> feeling it's caused by the '#' comparison, but I'm not sure. > > > > We are aware of that *warning* but you can savely ignore it. > > OK. Is it the '#' that kills it? What about "\#"? Mark? What do you think? > > >> 3) iSCSI - this doesn't appear to get included on the initrd. This is > >> kind of important. How do I add it, so that I can mount the SAN being > >> used for the shared GFS root? > > > > We did not implement it yet. Feel free to do it. Use the latest rpms and > > adapt the code. Latest HEAD rpms are attached. > > Please edit against them. And send either patches or the changed files > > directly to me. > > OK. Presumably, this would mean: > > 1) Install standard iscsi-initiator-utils rpm into the OSR initrd. yes. > 2) Copy the /etc/iscsi/iscsid.conf /var/lib/iscsi/* into the OSR initrd no the iscsid.conf should be created from cluster.conf. Because of the ip of the iscsi-source. It might be one server gets it root from on iscsi-device and another from another iscsi-device. Some customers have clusters with different roots for different nodes. > 3) Add iscsi and iscsid init scripts to the relevant run-level on OSR > initrd. there are no run-levels inside the initrd ;-( . So the starting has to be done manually within iscsi-lib and the iscsiLoad Function. > > On a separate note - the instructions say that /etc/sysconfig/network is > to be unshared. Yes. Because of the hostsname. > I think /etc/sysconfig/network-scripts should be unshared, > too, unless all IPs are assigned via DHCP - which may or may not be the > case. Although if they were assigned by DHCP, that would be kind of neat Yes, every ifcfg-eth? has to be hostdependent. Unless using dhcp. > because it would mean you can purely network boot them via PXE (even if > the initrd is 50MB+!). It once worked that customers had the ip=dhcp in the cluster.conf and it got its clusterip from a dhcp server. If you like give it a try. > > > Find more information here: > > http://www.opensharedroot.org/Members/marc/blog/comoonics-bootimage/conce > >pt-of-integrating-iscsi-support-to-latest-bootimage You should be able to > > add comments or just send me an email on what you think. > > Hmm. Do we need this specified in cluster.conf? > Are the rootsource, rootvolume and chrootenv tags the standard way to > achieve this? rootvolume has to be given always. It tells where to mount the rootfs from. rootsource is optional: I would use it for telling the cluster that the rootdevice itself is an iscsione and the ipadress is x.y.z. > > > If you need more bins or rpms included in the initrd (which I expect to > > be) have a look at /etc/comoonics/bootimage/files.initrd.d > > and /etc/comoonics/bootimage/rpms.initrd.d. > > Thanks for that. Do you envisage anything over and above what I listed > above to be required? I'm not quite up to speed on the cluster.conf stuff, > but would the 3 steps to get iSCSI going be sufficient to get the initrd > connectable to the SAN at least? Once it gets that far, even mounting the > root manually wouldn't be too bad. To do anything manually you can always use two or better three nice options at bootcmdline: com-debug: switches on debugging. com-step: adds steps to the bootprocess where you can jump into a shell with break and leave and continue the bootprocess with exit. com-expert: imediately starts a shell after initrd is loaded. > > Incidentally, how is the fencing/cluster stuff handled in the initrd? I > didn't notice cman being included. It is but RHEL5 has slightly different packages. > > > Have fun and thanks (hope you'll enjoy the open-sharedroot concept as > > much as we do) > > Thank you for responding, I appreciate it. > > Gordan Regards Marc. > > ------------------------------------------------------------------------- > 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: Marc G. <gr...@at...> - 2007-10-10 13:12:47
|
On Wednesday 10 October 2007 15:04:08 Gordan Bobic wrote: > While making the initrd: > > cp: cannot stat `/etc/sysconfig/comoonics-chroot': No such file or > directory > > What should be in this file? That file is used for compatibility with users working with bootimage-1.2 with RHEL4 and having the chroot on a special filesystem. This can be savely ignored and could be stated as costemic *warning*. Question is why is it in the dependencies? Mark?? Any idea? Regards 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-10 13:04:11
|
While making the initrd: cp: cannot stat `/etc/sysconfig/comoonics-chroot': No such file or directory What should be in this file? Gordan |
|
From: Gordan B. <go...@bo...> - 2007-10-10 13:00:30
|
On Wed, 10 Oct 2007, Marc Grimme wrote: >> 1) Python libraries assume python 2.3. RHEL5 (CentOS5 in my case) uses >> python 2.4. That means that if this is intended for RHEL5, the libraries >> should end up in /usr/lib/python2.4/site-packages/comoonics >> At the moment, they end up in /usr/lib/python2.3/site-packages/comoonics, >> which means they don't work. > There should be a rhel5 channel available. It's not yet official but it proves > to be quite stable. We are right now in the last steps before qa-ing. > Use the following yum.repositories. > > [comoonics-preview] > name=Packages for the comoonics shared root cluster > baseurl=http://download.atix.de/yum/comoonics/redhat-el5/preview/noarch/ > enabled=1 > gpgcheck=1 > gpgkey=http://download.atix.de/yum/comoonics/comoonics-RPM-GPG.key > > [comoonics-preview-i386] > name=Packages for the comoonics shared root cluster > baseurl=http://download.atix.de/yum/comoonics/redhat-el5/preview/$arch > enabled=1 > gpgcheck=1 > gpgkey=http://download.atix.de/yum/comoonics/comoonics-RPM-GPG.key > > [comoonics-addons] > name=Addon Packages for utilities > baseurl=http://download.atix.de/yum/comoonics/redhat-el5/addons/noarch/ > enabled=1 > gpgcheck=1 > gpgkey=http://download.atix.de/yum/comoonics/comoonics-RPM-GPG.key > > That will be anounced recently on www.opensharedroot.org. OK, that seems to solve the problem of el4 packages creeping in and breaking things. :-) >> 2) When making the initrd: >> >> 2.1) Extracting rpms...Cannot find rpm "comoonics-cs". Skipping. >> Cannot find rpm "GFS". Skipping. >> Cannot find rpm "ccs". Skipping. >> Cannot find rpm "dlm". Skipping. >> Cannot find rpm "fence". Skipping. >> Cannot find rpm "magma". Skipping. >> Cannot find rpm "magma-plugins". Skipping. >> Cannot find rpm "OpenIPMI-tools". Skipping. >> >> Where can these be found, and where should they be put for this step to >> find them? > Follow the instructions on > http://www.opensharedroot.org/documentation/rhel5-gfs-shared-root-mini-howto I did. Nowhere does it manage yum installing packages GFS, ccs, dlm, fence, magma, magma-plugins or OpenIPMI-tools. >> 2.2) Retrieving dependent >> files.../opt/atix/comoonics-bootimage/boot-scripts/etc/chroot-lib.sh: line >> 333: [: !=: unary operator expected > you can ignore that. >> found 3545 >> >> What is actually causing this? I looked at the script, and I have a >> feeling it's caused by the '#' comparison, but I'm not sure. > > We are aware of that *warning* but you can savely ignore it. OK. Is it the '#' that kills it? What about "\#"? >> 3) iSCSI - this doesn't appear to get included on the initrd. This is kind >> of important. How do I add it, so that I can mount the SAN being used for >> the shared GFS root? > > We did not implement it yet. Feel free to do it. Use the latest rpms and adapt > the code. Latest HEAD rpms are attached. > Please edit against them. And send either patches or the changed files > directly to me. OK. Presumably, this would mean: 1) Install standard iscsi-initiator-utils rpm into the OSR initrd. 2) Copy the /etc/iscsi/iscsid.conf /var/lib/iscsi/* into the OSR initrd 3) Add iscsi and iscsid init scripts to the relevant run-level on OSR initrd. On a separate note - the instructions say that /etc/sysconfig/network is to be unshared. I think /etc/sysconfig/network-scripts should be unshared, too, unless all IPs are assigned via DHCP - which may or may not be the case. Although if they were assigned by DHCP, that would be kind of neat because it would mean you can purely network boot them via PXE (even if the initrd is 50MB+!). > Find more information here: > http://www.opensharedroot.org/Members/marc/blog/comoonics-bootimage/concept-of-integrating-iscsi-support-to-latest-bootimage > You should be able to add comments or just send me an email on what you think. Hmm. Do we need this specified in cluster.conf? Are the rootsource, rootvolume and chrootenv tags the standard way to achieve this? > If you need more bins or rpms included in the initrd (which I expect to be) > have a look at /etc/comoonics/bootimage/files.initrd.d > and /etc/comoonics/bootimage/rpms.initrd.d. Thanks for that. Do you envisage anything over and above what I listed above to be required? I'm not quite up to speed on the cluster.conf stuff, but would the 3 steps to get iSCSI going be sufficient to get the initrd connectable to the SAN at least? Once it gets that far, even mounting the root manually wouldn't be too bad. Incidentally, how is the fencing/cluster stuff handled in the initrd? I didn't notice cman being included. > Have fun and thanks (hope you'll enjoy the open-sharedroot concept as much as > we do) Thank you for responding, I appreciate it. Gordan |
|
From: Marc G. <gr...@at...> - 2007-10-10 12:24:01
|
Hi Gordan, On Wednesday 10 October 2007 12:35:52 Gordan Bobic wrote: > Hi, > > I've recently started playing with the shared-root idea, and I've > discovered a few bugs. How do I report them and/or submit patches? > > 1) Python libraries assume python 2.3. RHEL5 (CentOS5 in my case) uses > python 2.4. That means that if this is intended for RHEL5, the libraries > should end up in /usr/lib/python2.4/site-packages/comoonics > At the moment, they end up in /usr/lib/python2.3/site-packages/comoonics, > which means they don't work. There should be a rhel5 channel available. It's not yet official but it proves to be quite stable. We are right now in the last steps before qa-ing. Use the following yum.repositories. [comoonics-preview] name=Packages for the comoonics shared root cluster baseurl=http://download.atix.de/yum/comoonics/redhat-el5/preview/noarch/ enabled=1 gpgcheck=1 gpgkey=http://download.atix.de/yum/comoonics/comoonics-RPM-GPG.key [comoonics-preview-i386] name=Packages for the comoonics shared root cluster baseurl=http://download.atix.de/yum/comoonics/redhat-el5/preview/$arch enabled=1 gpgcheck=1 gpgkey=http://download.atix.de/yum/comoonics/comoonics-RPM-GPG.key [comoonics-addons] name=Addon Packages for utilities baseurl=http://download.atix.de/yum/comoonics/redhat-el5/addons/noarch/ enabled=1 gpgcheck=1 gpgkey=http://download.atix.de/yum/comoonics/comoonics-RPM-GPG.key That will be anounced recently on www.opensharedroot.org. > > 2) When making the initrd: > > 2.1) Extracting rpms...Cannot find rpm "comoonics-cs". Skipping. > Cannot find rpm "GFS". Skipping. > Cannot find rpm "ccs". Skipping. > Cannot find rpm "dlm". Skipping. > Cannot find rpm "fence". Skipping. > Cannot find rpm "magma". Skipping. > Cannot find rpm "magma-plugins". Skipping. > Cannot find rpm "OpenIPMI-tools". Skipping. > > Where can these be found, and where should they be put for this step to > find them? Follow the instructions on http://www.opensharedroot.org/documentation/rhel5-gfs-shared-root-mini-howto > > 2.2) Retrieving dependent > files.../opt/atix/comoonics-bootimage/boot-scripts/etc/chroot-lib.sh: line > 333: [: !=: unary operator expected you can ignore that. > found 3545 > > What is actually causing this? I looked at the script, and I have a > feeling it's caused by the '#' comparison, but I'm not sure. We are aware of that *warning* but you can savely ignore it. > > 3) iSCSI - this doesn't appear to get included on the initrd. This is kind > of important. How do I add it, so that I can mount the SAN being used for > the shared GFS root? We did not implement it yet. Feel free to do it. Use the latest rpms and adapt the code. Please edit against them. And send either patches or the changed files directly to me. Find more information here: http://www.opensharedroot.org/Members/marc/blog/comoonics-bootimage/concept-of-integrating-iscsi-support-to-latest-bootimage You should be able to add comments or just send me an email on what you think. If you need more bins or rpms included in the initrd (which I expect to be) have a look at /etc/comoonics/bootimage/files.initrd.d and /etc/comoonics/bootimage/rpms.initrd.d. Have fun and thanks (hope you'll enjoy the open-sharedroot concept as much as we do) Marc. > > Many thanks. > > 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-10 10:36:03
|
Hi, I've recently started playing with the shared-root idea, and I've discovered a few bugs. How do I report them and/or submit patches? 1) Python libraries assume python 2.3. RHEL5 (CentOS5 in my case) uses python 2.4. That means that if this is intended for RHEL5, the libraries should end up in /usr/lib/python2.4/site-packages/comoonics At the moment, they end up in /usr/lib/python2.3/site-packages/comoonics, which means they don't work. 2) When making the initrd: 2.1) Extracting rpms...Cannot find rpm "comoonics-cs". Skipping. Cannot find rpm "GFS". Skipping. Cannot find rpm "ccs". Skipping. Cannot find rpm "dlm". Skipping. Cannot find rpm "fence". Skipping. Cannot find rpm "magma". Skipping. Cannot find rpm "magma-plugins". Skipping. Cannot find rpm "OpenIPMI-tools". Skipping. Where can these be found, and where should they be put for this step to find them? 2.2) Retrieving dependent files.../opt/atix/comoonics-bootimage/boot-scripts/etc/chroot-lib.sh: line 333: [: !=: unary operator expected found 3545 What is actually causing this? I looked at the script, and I have a feeling it's caused by the '#' comparison, but I'm not sure. 3) iSCSI - this doesn't appear to get included on the initrd. This is kind of important. How do I add it, so that I can mount the SAN being used for the shared GFS root? Many thanks. Gordan |
|
From: Marc G. <gr...@at...> - 2006-01-30 13:31:01
|
Hello, we have now a (beta version) mini-howto sharedroot with gfs available on http://open-sharedroot.sourceforge.net/ . Have fun and we are happy about any feetback. -- Gruss / Regards, Marc Grimme Phone: +49-89 121 409-54 http://www.atix.de/ ** ATIX - Ges. fuer Informationstechnologie und Consulting mbH Einsteinstr. 10 - 85716 Unterschleissheim - Germany |
12 messages has been excluded from this view by a project administrator.
