Re: [sisuite-users] software raid creation SI 3.9 FC6
> what I'm waiting for now, it's laying down the image (rsync and I get > these messages every X (once a md device finishes sync'n I guess) > (note i have tried 1000/1000 on speed and it took the same amount of > time as this appears to be taking). > > md: minimum _guaranteed_ reconstruction speed: 5000 KB/sec/disc. > md: using maximum available idle IO bandwidth (but not more than 10 > KB/sec) > for reconstruction. > md: using 128k window, over a total of 2007744 blocks. > md: md2: sync done. > RAID1 conf printout: > --- wd:2 rd:2 > disk 0, wo:0, o:1, dev:sda3 > disk 1, wo:0, o:1, dev:sdb3 Okay same issue this time, system finished after 4-5 hours and on boot it comes up with this Checking filesystems Checking all file systems. [/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a /dev/sda7 fsck.ext3: Device or resource busy while trying to open /dev/sda7 Filesystem mounted or opened exclusively by another program? [FAILED] *** An error occurred during the file system check. *** Dropping you to a shell; the system will reboot *** when you leave the shell. This is the second time, the volume is not dirty and if I stop the raid group and run fsck on /dev/sda7 it comes back clean. If I remove the .autofsck file the system will come up correctly.. I may need to move some of these issues elsewhere as I may be getting into something with software raid more so than SI setting it up (or?) Tory - 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/ ___ sisuite-users mailing list sisuite-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-users
[sisuite-users] SI installs to SAN luns instead of local disks
systemimager 4.0.0-1 (no uyok) imaging SLES10 SP1 The system I am imaging is attached to SAN via FC (emulex hba). During hardware scan, it loads the emulex hba driver "lpfc" before the lsi scsi controller driver "mptsas". So when autoinstall script begins systemimager sees the SAN lun as /dev/sda and installs to it. How can I force systemimager to install to the local disks instead? using a uyok setup, I can open up the initrd and edit the INSMOD-MODULES file to remove lpfc line, but that is a pain. I would love to be able to bypass uyok all together. -- -ashley Did you try poking at it with a stick? - 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/ ___ sisuite-users mailing list sisuite-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-users
Re: [sisuite-users] software raid creation SI 3.9 FC6
Imaging is still taking forever. the last couple of folks I've talked to said their images attempt to sync after the boot, not during the rsync (image creation process). I've modified the speed_limit files to have 1000 or so for min and max (took forever), I then changed it to 5000 and 10 and it's still taking forever, these images are taking like 3 hours each on 120gb drives. I really wish that it would not attempt to sync during the image and simply do it after the server comes up the first time (really, anyway this can happen? Or force the raid group stopped until a reboot and start it again?!) But I have had some success, got the system up, with the MD devices (no /etc/raidtab file) but things appeared to be running on the software raid and thus md devices. I did however have an empty /var volume which was "strange" (I'm imaging again after a few more tweaks to see what's what (but this 3-4 hour image timing is killin me!).. /proc/sys/dev/raid/speed_limit_max /proc/sys/dev/raid/speed_limit_min what I'm waiting for now, it's laying down the image (rsync and I get these messages every X (once a md device finishes sync'n I guess) (note i have tried 1000/1000 on speed and it took the same amount of time as this appears to be taking). md: minimum _guaranteed_ reconstruction speed: 5000 KB/sec/disc. md: using maximum available idle IO bandwidth (but not more than 10 KB/sec) for reconstruction. md: using 128k window, over a total of 2007744 blocks. md: md2: sync done. RAID1 conf printout: --- wd:2 rd:2 disk 0, wo:0, o:1, dev:sda3 disk 1, wo:0, o:1, dev:sdb3 Tory - 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/ ___ sisuite-users mailing list sisuite-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-users
Re: [sisuite-users] [ RFC ] SystemImager 4.0.2 or not?
On 2007-11-8 10:32, Andrea Righi wrote: > > Since rysnc is generally supplied by the linux distribution separately, I > > would not like to see SI require something that will conflict with what > > is provided by the base system. That's a headache and will just leave a > > lot of users back at SI 3.9.x until their distro goes to rsync 3. For > > fedora (which we use), that means a new release (at least f8, maybe f9) > > as they would not put it into an existing release as an update (if I > > understand the policy, and the policy is why we use fedora). > > There's a misunderstanding here... using rsync 3.0.0pre4 wouldn't introduce > any additional requirements. It will be only used by systemimager itself to > build the initrd_template and the BOEL initrd.img (read: it'll be > automatically shipped into the systemimager initrd). Ah, I get it. The rsync3 is packaged into the autoinstall system. Would getimage/updateclient continue to use the system rsync? Still, I can't really evaluate the stability risk in using rsync3 internally, but there don't appear to be complications for users aside from that. -- Patrick Dowler Tel/Tél: (250) 363-6914 | fax/télécopieur: (250) 363-0045 Canadian Astronomy Data Centre | Centre canadien de donnees astronomiques National Research Council Canada | Conseil national de recherches Canada Government of Canada | Gouvernement du Canada 5071 West Saanich Road | 5071, chemin West Saanich Victoria, BC | Victoria (C.-B.) - 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/ ___ sisuite-users mailing list sisuite-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-users
Re: [sisuite-users] [ RFC ] SystemImager 4.0.2 or not? (was: client netboot fails (rsync: failed to set times))
Of course I had already loaded 4.0.0 on my image server and as of today was looking at loading a machine(RH ES 4). I will download the pre-release packages and test. David K Livingstone CN Signals and Communications 10229 127 Avenue floor 2 Edmonton, AB, T5E 0B9 Ph : 780 472-3959 Fax : 780 472-3050 Email: [EMAIL PROTECTED] Andrea Righi <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 2007/11/08 11:43 Please respond to [EMAIL PROTECTED]; Please respond to sisuite-users@lists.sourceforge.net To sisuite-users@lists.sourceforge.net cc Subject Re: [sisuite-users] [ RFC ] SystemImager 4.0.2 or not? (was: client netboot fails (rsync: failed to set times)) [EMAIL PROTECTED] wrote: > > Andrea, > > I've read all the responses and there are merits to both 1 and 2 as > well as Bernard Li's response. > > - My vote goes for 2. > - should not have binaries availble which are broken and this will > fix the current problem without introducing any >other issues. > - option 1 should be released a 4.0.1( ie pre release of 4.0.2) and > tested. Well... I've already tested it, but obviously tests are limited by my resources. I've reinstalled a i386 with Debian4, suse10, ubuntu 7.10 and a PS3 with ubuntu 7.10. I was able to reproduce the problem in the PS3 and rsync 3.0.0pre4 fixed it. I didn't see any other problem. I would like to remember that the pre-release packages with rsync 3.0.0pre4 (that I've used for my tests) are available here: http://download.systemimager.org/~arighi/systemimager/ As Bernard correctly said we need more tests. Volunteers are really welcome... ;-) -Andrea - 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/ ___ sisuite-users mailing list sisuite-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-users - 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/___ sisuite-users mailing list sisuite-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-users
Re: [sisuite-users] LV creation fails with device-mapper: table ioctl failed
On Thu, Nov 08, 2007 at 10:18:38AM -0800, ashley wrote: > This is using UYOK and boel devstyle="static" is already set by > si_prepareclient. What I have not tried is using the systemimager > kernel/initrd. I am quite certain I did not get this error with > 3.8.0-1 previously on other sles9 installs. This is why I suspect > new sles9 kernel. More later. > Using 4.0.0-1 systemimager kernel/initrd works like a charm. Goodbye UYOK! This is for Sun x4200 hardware. I keep forgetting how much systemimager has grown up over the last 2 years I've been using it. You guys are the best! > > On Thu, Nov 08, 2007 at 12:00:31PM +0100, Andrea Righi wrote: > > Ashley Gould wrote: > > > I do not get this error when installing a SLES10 image. I suspect this is > > > because boel lvm is expecting devices via udev, but SLES9 uses a static > > > /dev? > > > This is a wild guess. The other thought is my goldenclient kernel version > > > doesn't like boel lvm. I tried with systemimager-3.9.6.-1 and 3.8.0-1 > > > also > > > (goldenclient and server), but got the same error. > > > > You could try two solutions: > > > > 1) UYOK (http://wiki.systemimager.org/index.php/UYOK) > > > > 2) change in your autoinstallscript.conf: > > > > > > > > into: > > > > > > > > and re-create the autoinstall-script by si_mkautoinstallscript. > > > > -Andrea > > > > - > > 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/ > > ___ > > sisuite-users mailing list > > sisuite-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/sisuite-users > > -- > > -ashley > > Did you try poking at it with a stick? > > > - > 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/ > ___ > sisuite-users mailing list > sisuite-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sisuite-users -- -ashley Did you try poking at it with a stick? - 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/ ___ sisuite-users mailing list sisuite-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-users
Re: [sisuite-users] [ RFC ] SystemImager 4.0.2 or not? (was: client netboot fails (rsync: failed to set times))
[EMAIL PROTECTED] wrote: > > Andrea, > > I've read all the responses and there are merits to both 1 and 2 as > well as Bernard Li's response. > > - My vote goes for 2. > - should not have binaries availble which are broken and this will > fix the current problem without introducing any >other issues. > - option 1 should be released a 4.0.1( ie pre release of 4.0.2) and > tested. Well... I've already tested it, but obviously tests are limited by my resources. I've reinstalled a i386 with Debian4, suse10, ubuntu 7.10 and a PS3 with ubuntu 7.10. I was able to reproduce the problem in the PS3 and rsync 3.0.0pre4 fixed it. I didn't see any other problem. I would like to remember that the pre-release packages with rsync 3.0.0pre4 (that I've used for my tests) are available here: http://download.systemimager.org/~arighi/systemimager/ As Bernard correctly said we need more tests. Volunteers are really welcome... ;-) -Andrea - 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/ ___ sisuite-users mailing list sisuite-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-users
Re: [sisuite-users] [ RFC ] SystemImager 4.0.2 or not?
Patrick Dowler wrote: > I agree with what Bernard says here: rebuild 4.0.0 asap so users with kernel > < > 2.6.22 aren't bitten by the bug. > > As for rsync, I am not sure I followed but is it a bug in rsync generally > that > is fixed in 3? Yes. > > Since rysnc is generally supplied by the linux distribution separately, I > would not like to see SI require something that will conflict with what is > provided by the base system. That's a headache and will just leave a lot of > users back at SI 3.9.x until their distro goes to rsync 3. For fedora (which > we use), that means a new release (at least f8, maybe f9) as they would not > put it into an existing release as an update (if I understand the policy, and > the policy is why we use fedora). There's a misunderstanding here... using rsync 3.0.0pre4 wouldn't introduce any additional requirements. It will be only used by systemimager itself to build the initrd_template and the BOEL initrd.img (read: it'll be automatically shipped into the systemimager initrd). -Andrea - 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/ ___ sisuite-users mailing list sisuite-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-users
Re: [sisuite-users] LV creation fails with device-mapper: table ioctl failed
This is using UYOK and boel devstyle="static" is already set by si_prepareclient. What I have not tried is using the systemimager kernel/initrd. I am quite certain I did not get this error with 3.8.0-1 previously on other sles9 installs. This is why I suspect new sles9 kernel. More later. On Thu, Nov 08, 2007 at 12:00:31PM +0100, Andrea Righi wrote: > Ashley Gould wrote: > > I do not get this error when installing a SLES10 image. I suspect this is > > because boel lvm is expecting devices via udev, but SLES9 uses a static > > /dev? > > This is a wild guess. The other thought is my goldenclient kernel version > > doesn't like boel lvm. I tried with systemimager-3.9.6.-1 and 3.8.0-1 also > > (goldenclient and server), but got the same error. > > You could try two solutions: > > 1) UYOK (http://wiki.systemimager.org/index.php/UYOK) > > 2) change in your autoinstallscript.conf: > > > > into: > > > > and re-create the autoinstall-script by si_mkautoinstallscript. > > -Andrea > > - > 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/ > ___ > sisuite-users mailing list > sisuite-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sisuite-users -- -ashley Did you try poking at it with a stick? - 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/ ___ sisuite-users mailing list sisuite-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-users
Re: [sisuite-users] [ RFC ] SystemImager 4.0.2 or not? (was: client netboot fails (rsync: failed to set times))
Andrea, I've read all the responses and there are merits to both 1 and 2 as well as Bernard Li's response. - My vote goes for 2. - should not have binaries availble which are broken and this will fix the current problem without introducing any other issues. - option 1 should be released a 4.0.1( ie pre release of 4.0.2) and tested. Thanks David K Livingstone CN Signals and Communications 10229 127 Avenue floor 2 Edmonton, AB, T5E 0B9 Ph : 780 472-3959 Fax : 780 472-3050 Email: [EMAIL PROTECTED] Andrea Righi <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 2007/11/07 16:29 Please respond to [EMAIL PROTECTED]; Please respond to sisuite-users@lists.sourceforge.net To Brian Elliott Finley <[EMAIL PROTECTED]>, Erich Focht <[EMAIL PROTECTED]>, Bernard Li <[EMAIL PROTECTED]> cc sisuite-dev s <[EMAIL PROTECTED]>, sisuite-users Subject [sisuite-users] [ RFC ] SystemImager 4.0.2 or not? (was: client netboot fails (rsync: failed to set times)) Hi all, it seems that someone is agree with me and someone is not about the solution to add the pre-release of rsync (3.0.0pre4) into the stable branch of SystemImager and tag the new 4.0.2 stable ASAP (4.0.1, since ".1" is odd, is reserved for development pre-releases). So, probably this is the first polling in these lists :-), don't know, but I would really like to know opinion of the community about this issue. The fact is that the current stable release of SystemImager 4.0.0 is not "stable" enough: there is a bug that occurs with rsync when it's built on a machine with a kernel >= 2.6.22 (that's actually my build server) and the installing client uses a kernel < 2.6.22: See http://www.systemimager.org:8000/trac.systemimager.org/ticket/6 for details, many thanks to Rochus Schmid for reporting this bug. The proposed solutions for now are: 1) use the pre-release of rsync that seems to fix the problem and tag SystemImager 4.0.2, leaving the 4.0.0 packages as they are, let me say that I would just proceed like the kernel guys do if there's a bug in the kernel (just leave all the previous released kernels "forzen" and available for download in any case, and always release new versions in case of errors/bugs) 2) remove the old 4.0.0 packages from SF.net (let me say "close" them to the users), rebuild all the packages in a build server with a kernel < 2.6.22 and then release the new packages using the same version number: 4.0.0 3) rebuild the packages in a build server with a kernel < 2.6.22 and changing the version number to 4.0.2, leaving 4.0.0 packages as they are on SF.net 4) other ideas are welcome... I vote for 1). -Andrea - 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/ ___ sisuite-users mailing list sisuite-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-users - 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/___ sisuite-users mailing list sisuite-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-users
Re: [sisuite-users] [ RFC ] SystemImager 4.0.2 or not?
I agree with what Bernard says here: rebuild 4.0.0 asap so users with kernel < 2.6.22 aren't bitten by the bug. As for rsync, I am not sure I followed but is it a bug in rsync generally that is fixed in 3? Since rysnc is generally supplied by the linux distribution separately, I would not like to see SI require something that will conflict with what is provided by the base system. That's a headache and will just leave a lot of users back at SI 3.9.x until their distro goes to rsync 3. For fedora (which we use), that means a new release (at least f8, maybe f9) as they would not put it into an existing release as an update (if I understand the policy, and the policy is why we use fedora). my 2c, Patrick On 2007-11-7 15:53, Bernard Li wrote: > Hi all: > > On 11/7/07, Andrea Righi <[EMAIL PROTECTED]> wrote: > > it seems that someone is agree with me and someone is not about the > > solution to add the pre-release of rsync (3.0.0pre4) into the stable > > branch of SystemImager and tag the new 4.0.2 stable ASAP (4.0.1, since > > ".1" is odd, is reserved for development pre-releases). > > I'm the 'someone' who does not agree with this :-) The main reason > being rsync is a key component of SystemImager, and using a > pre-release version (and mind you, a huge jump from 2.6.8 -> 3.0.0) > which has not been fully tested would bring the stability of the > release into question. Sure, 3.0.0pre4 might fix this particular > problem, but without full testing we will not know whether this brings > about _other_ issues that might be missed by both rsync and > systemimager developers/users. > > > So, probably this is the first polling in these lists :-), don't know, > > but I would really like to know opinion of the community about this > > issue. > > > > The fact is that the current stable release of SystemImager 4.0.0 is not > > "stable" enough: there is a bug that occurs with rsync when it's built on > > a machine with a kernel >= 2.6.22 (that's actually my build server) and > > the installing client uses a kernel < 2.6.22: > > > > See http://www.systemimager.org:8000/trac.systemimager.org/ticket/6 for > > details, many thanks to Rochus Schmid for reporting this bug. > > > > The proposed solutions for now are: > > > > 1) use the pre-release of rsync that seems to fix the problem and tag > > SystemImager 4.0.2, leaving the 4.0.0 packages as they are, let me say > > that I would just proceed like the kernel guys do if there's a bug in the > > kernel (just leave all the previous released kernels "forzen" and > > available for download in any case, and always release new versions in > > case of errors/bugs) > > > > 2) remove the old 4.0.0 packages from SF.net (let me say "close" them to > > the users), rebuild all the packages in a build server with a kernel < > > 2.6.22 and then release the new packages using the same version number: > > 4.0.0 > > > > 3) rebuild the packages in a build server with a kernel < 2.6.22 and > > changing the version number to 4.0.2, leaving 4.0.0 packages as they are > > on SF.net > > > > 4) other ideas are welcome... > > > > I vote for 1). > > Okay, this is my suggestion: > > Since 4.0.0 is already released, we should just leave it. I do not > feel strongly either way whether we decide to hide this release or > not, but one argument for hiding it would be that the binaries are > broken for users running Kernel < 2.6.22 (which I would think are the > majority of the users). I wouldn't want a new user to somehow stumble > upon the link for 4.0.0 and download something that does not work. > > My suggestion would be to increment the version number (for no > particular reason than to keep it distinct from the bad 4.0.0 release) > and simply rebuild all the files on a server that is running Kernel < > 2.6.22 (RPM, deb etc.) and (re)-release that. > > I also think it would not be unreasonable to postpone the release > until we can get some more testing done -- let's call this beta, and > then after getting some more testing, we make the release. > > I would like to take this opportunity to invite the community to help > us grow the project. The developers have put in a great deal of time > and effort into adding new features and as we support more features > and distribution/versions etc., we really need more volunteers to help > us test the software before we release it. This will ensure that our > code is as stable as possible prior to release. > > For argument's sake, I will call this solution b) :-) I'd like to > cast my vote on b) > > Cheers, > > Bernard > > - > 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/ > ___ > sisuite-users mailing list > sisuite-users@list
Re: [sisuite-users] LV creation fails with device-mapper: table ioctl failed
Ashley Gould wrote: > I do not get this error when installing a SLES10 image. I suspect this is > because boel lvm is expecting devices via udev, but SLES9 uses a static /dev? > This is a wild guess. The other thought is my goldenclient kernel version > doesn't like boel lvm. I tried with systemimager-3.9.6.-1 and 3.8.0-1 also > (goldenclient and server), but got the same error. You could try two solutions: 1) UYOK (http://wiki.systemimager.org/index.php/UYOK) 2) change in your autoinstallscript.conf: into: and re-create the autoinstall-script by si_mkautoinstallscript. -Andrea - 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/ ___ sisuite-users mailing list sisuite-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-users
Re: [sisuite-users] software raid creation SI 3.9 FC6
Tory M Blue wrote: > On 11/6/07, Tory M Blue <[EMAIL PROTECTED]> wrote: >> Greetings, >> >> So I've created my own autoinstallscript.conf file and ran a >> si_mkautoinstallscript against it and my image appears to create all >> the various MD devices and syncs them up (this process takes about 3 >> hours+ to lay down the image due to all the sync'n that's going on). > > Update: My master script had an issue I was not setting a label for my > root partition, however my grub.conf was looking for a label of "/" > and well it wasn't there, thus /dev/root could not be found. So I > fixed that oversight, got the system to image and come up, however it > came up on sda* vs md*, so I started looking further. Probably you're using RAID 1, and, at the boot, only a single device of the mirror was mounted, because the initrd in your image doesn't have the required software RAID stuff... have you tried to re-create it as I suggested in my previous email? > I found that my autoinstallscript.conf was wrong, I caught it when I > had to recreate it "since that's what Andrea wanted to see, and I had > umm "misplaced it"". I noticed that I set raid as a flag for md0 but > not for any other partition and thus I was obviously not creating a > raid relationship. > > So I'm imaging again and will see what happens. Not sure I'm out of > the woods, but obviously small typo's can create fun little issues. OK, keep us posted. -Andrea - 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/ ___ sisuite-users mailing list sisuite-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-users
Re: [sisuite-users] [Sisuite-devel] [ RFC ] SystemImager 4.0.2 or not? (was: client netboot fails (rsync: failed to set times))
Erich Focht wrote: > Hi, > > I'm for 1), too. If Brian's right and there was a decision on having the > second > digit as sign for stability, then I'd rather make it 4.0.1. As I said in the previous email, the next "official" version should be 4.0.2, according to the new versioning rules (4.0.1 is reserved for pre-releases of 4.0.2): http://wiki.systemimager.org/index.php/Developer_Guidelines#Versioning > Can you change the release notes of the 4.0.0 version on the sourceforge page? Sounds good. Done: http://sourceforge.net/project/shownotes.php?group_id=259&release_id=551739 > If you can add a comment on the bug, you should leave the version there. But > it has no value, actually, once you added the fixed version. You're not > deleting > the svn tags, so old versions are still available, even if you remove the > buggy > things from SF.net. Thanks, -Andrea - 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/ ___ sisuite-users mailing list sisuite-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-users
Re: [sisuite-users] [Sisuite-devel] [ RFC ] SystemImager 4.0.2 or not? (was: client netboot fails (rsync: failed to set times))
Hi, I'm for 1), too. If Brian's right and there was a decision on having the second digit as sign for stability, then I'd rather make it 4.0.1. If the architecture change of trunk is big enough for getting a 4.1.X version, better move 4.0.X into a si-4.0 branch, and evolve it separately into 4.0.1/2/3... Whether rsync is called 2.6.X or 3.0.X, I'm optimistic that code is generally improving. If the new version does the job, why not? Can you change the release notes of the 4.0.0 version on the sourceforge page? If you can add a comment on the bug, you should leave the version there. But it has no value, actually, once you added the fixed version. You're not deleting the svn tags, so old versions are still available, even if you remove the buggy things from SF.net. Regards, Erich On Thursday 08 November 2007 00:25, Andrea Righi wrote: > Hi all, > > it seems that someone is agree with me and someone is not about the solution > to > add the pre-release of rsync (3.0.0pre4) into the stable branch of > SystemImager > and tag the new 4.0.2 stable ASAP (4.0.1, since ".1" is odd, is reserved for > development pre-releases). > > So, probably this is the first polling in these lists :-), don't know, but I > would really like to know opinion of the community about this issue. > > The fact is that the current stable release of SystemImager 4.0.0 is not > "stable" enough: there is a bug that occurs with rsync when it's built on a > machine with a kernel >= 2.6.22 (that's actually my build server) and the > installing client uses a kernel < 2.6.22: > > See http://www.systemimager.org:8000/trac.systemimager.org/ticket/6 for > details, > many thanks to Rochus Schmid for reporting this bug. > > The proposed solutions for now are: > > 1) use the pre-release of rsync that seems to fix the problem and tag > SystemImager 4.0.2, leaving the 4.0.0 packages as they are, let me say that I > would just proceed like the kernel guys do if there's a bug in the kernel > (just > leave all the previous released kernels "forzen" and available for download in > any case, and always release new versions in case of errors/bugs) > > 2) remove the old 4.0.0 packages from SF.net (let me say "close" them to the > users), rebuild all the packages in a build server with a kernel < 2.6.22 and > then release the new packages using the same version number: 4.0.0 > > 3) rebuild the packages in a build server with a kernel < 2.6.22 and changing > the version number to 4.0.2, leaving 4.0.0 packages as they are on SF.net > > 4) other ideas are welcome... > > I vote for 1). > > -Andrea > > - > 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/ > ___ > sisuite-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/sisuite-devel > - 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/ ___ sisuite-users mailing list sisuite-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-users
Re: [sisuite-users] [ RFC ] SystemImager 4.0.2 or not? (was: client netboot fails (rsync: failed to set times))
Hi all: On 11/7/07, Andrea Righi <[EMAIL PROTECTED]> wrote: > it seems that someone is agree with me and someone is not about the solution > to > add the pre-release of rsync (3.0.0pre4) into the stable branch of > SystemImager > and tag the new 4.0.2 stable ASAP (4.0.1, since ".1" is odd, is reserved for > development pre-releases). I'm the 'someone' who does not agree with this :-) The main reason being rsync is a key component of SystemImager, and using a pre-release version (and mind you, a huge jump from 2.6.8 -> 3.0.0) which has not been fully tested would bring the stability of the release into question. Sure, 3.0.0pre4 might fix this particular problem, but without full testing we will not know whether this brings about _other_ issues that might be missed by both rsync and systemimager developers/users. > So, probably this is the first polling in these lists :-), don't know, but I > would really like to know opinion of the community about this issue. > > The fact is that the current stable release of SystemImager 4.0.0 is not > "stable" enough: there is a bug that occurs with rsync when it's built on a > machine with a kernel >= 2.6.22 (that's actually my build server) and the > installing client uses a kernel < 2.6.22: > > See http://www.systemimager.org:8000/trac.systemimager.org/ticket/6 for > details, > many thanks to Rochus Schmid for reporting this bug. > > The proposed solutions for now are: > > 1) use the pre-release of rsync that seems to fix the problem and tag > SystemImager 4.0.2, leaving the 4.0.0 packages as they are, let me say that I > would just proceed like the kernel guys do if there's a bug in the kernel > (just > leave all the previous released kernels "forzen" and available for download in > any case, and always release new versions in case of errors/bugs) > > 2) remove the old 4.0.0 packages from SF.net (let me say "close" them to the > users), rebuild all the packages in a build server with a kernel < 2.6.22 and > then release the new packages using the same version number: 4.0.0 > > 3) rebuild the packages in a build server with a kernel < 2.6.22 and changing > the version number to 4.0.2, leaving 4.0.0 packages as they are on SF.net > > 4) other ideas are welcome... > > I vote for 1). Okay, this is my suggestion: Since 4.0.0 is already released, we should just leave it. I do not feel strongly either way whether we decide to hide this release or not, but one argument for hiding it would be that the binaries are broken for users running Kernel < 2.6.22 (which I would think are the majority of the users). I wouldn't want a new user to somehow stumble upon the link for 4.0.0 and download something that does not work. My suggestion would be to increment the version number (for no particular reason than to keep it distinct from the bad 4.0.0 release) and simply rebuild all the files on a server that is running Kernel < 2.6.22 (RPM, deb etc.) and (re)-release that. I also think it would not be unreasonable to postpone the release until we can get some more testing done -- let's call this beta, and then after getting some more testing, we make the release. I would like to take this opportunity to invite the community to help us grow the project. The developers have put in a great deal of time and effort into adding new features and as we support more features and distribution/versions etc., we really need more volunteers to help us test the software before we release it. This will ensure that our code is as stable as possible prior to release. For argument's sake, I will call this solution b) :-) I'd like to cast my vote on b) Cheers, Bernard - 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/ ___ sisuite-users mailing list sisuite-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-users
