The policy for SystemImager in Debian stable is to add only the versions formally released under the "stable" branch. Moreover, at the moment, the current Debian maintainer (Dann) is looking for contributors (see http://wiki.systemimager.org/index.php/Debian_Packaging), so SystemImager in Debian is in the middle of a transition phase.
A similar transition is happening for systemconfigurator. This package is no more maintained by the creator (Sean) and now the official release is becoming the Erich's branch hosted into the OSCAR repository. But, we're trying to merge all the works in a common repository, so we hope that soon there will be *only* a single global repository hosted at svn.systemimager.org. See: http://svn.systemimager.org/listing.php?repname=systemconfigurator&path=%2F&sc=0 The same for the documentation and website.. soon all will converge to wiki.systemimager.org. Regarding the SystemImager "stable" and "unstable" conflicts, we'll release 3.8.0 soon, but we want to make it really stable ;-) and we're still adding recent releases into the "unstable" branch. If you use old distributions, kernels, etc you should use the last "stable", but with newer distributions, newer hardware, etc you can't expect that an old "stable" will support all the recent features. In this case is better to use an unstable release, even if it's "tagged" as unstable. Hope this clarify... -Andrea John Goerzen wrote: > Hi Andrea, > > I've been lurking here for awhile. I've got to say I am totally > confused about what represents the current, stable > systemimager/systemcofigurator. I'm just using what's in Debian right > now (3.6.3dfsg1-2). > > But: > > 1. Comments in the mailing list say that the latest development trees > are actually more stable than the latest "stable" tarballs. > > 2. Those same development ("unstable") tarballs contain huge warnings > about how unstable they are. > > 3. systemimager.org and sisuite.org sometimes have the same information > and sometimes conflict. It's unclear which is authoritative. > > 4. And now there is this OSCAR thing, which I've never heard of, > that sounds even more confusing. > > Please consider this a plea from a confused user to: > > * Make the stable tarballs actually be the most stable packages > > * Decide on one site, once and for all, to have the authoritative > systemimager info > > I would help if I knew what to do. > > But as it is, I fear that it will be easier to write my own program than > to try to wade through all of this. I am wasting a ton of time trying > to figure out which message is correct and which direction to commit our > group to. > > Thanks for all the work you do on this. I know that documentation and > release management are thankless tasks. But you have my thanks in > advance for this. > > -- John > > On Fri, Jan 12, 2007 at 11:29:22PM +0100, Andrea Righi wrote: >> I agree... it must be fixed it in systemconfigurator, even if sometimes >> I use the same post-install script workaround. >> >> Have you tried to use the systemconfigurator release shipped with OSCAR? >> The last stable release is available here: >> >> http://svn.oscar.openclustergroup.org/oscar/branches/branch-5-0/packages/sis/SRPMS/ >> >> Otherwise you should also try with the release in the trunk: >> >> http://svn.systemimager.org/listing.php?repname=systemconfigurator&path=%2Ftrunk%2F&rev=0&sc=0 >> >> Follow the instruction to download it here: http://svn.systemimager.org/ >> >> Regards, >> -Andrea >> >> Patrick Hartling wrote: >>> I have been tinkering with SystemImager 3.7.6 and System Configurator 2.2.2, >>> and I have things working just about the way that I need except for the very >>> last step. For some reason, the GRUB boot blocks are not being written to >>> the client, and this of course leaves me with a system that does not boot >>> without some additional tweaking. An attempt is made during the >>> auto-installation to run grub-install, but it fails without giving me enough >>> information to diagnose the problem. If I run 'grub-install /dev/hda' in a >>> post-install script, it works fine, but it seems like it should not be >>> necessary to run grub-install twice. >>> >>> The output from the first run of grub-install (done by System Configurator, >>> right?) is as follows: >>> >>> mktemp: cannot create temp file /tmp/grub-install.log.C25188": No such file >>> or directory >>> /sbin/grub-install: line 362: $log_file: ambiguous redirect >>> sed: can't read /boot/grub/device.map: No such file or directory >>> No suitable drive was found in the generated device map. >>> Reverting to backed up copy. >>> Probing devices to guess BIOS drives. This may take a long time. >>> end_request: I/O error, dev fd0, sector 0 >>> readline() on closed filehandle IN at /usr/lib/systemconfig/Boot/Grub.pm >>> line 189. >>> Use of uninitialized value in concatenation (.) or string at >>> /usr/lib/systemconfig/Boot/Grub.pm line 160. >>> Use of uninitialized value in substitution (s///) or string at >>> /usr/lib/systemconfig/Boot/Grub.pm line 164. >>> Use of uninitialized value in concatenation (.) or string at >>> /usr/lib/systemconfig/Boot/Grub.pm line 235. >>> Use of uninitialized value in concatenation (.) or string at >>> /usr/lib/systemconfig/Boot/Grub.pm line 237. >>> Probing devices to guess BIOS drives. This may take a long time. >>> end_request: I/O error, dev fd0, sector 0 >>> >>> There is nothing in /tmp/si.log about GRUB, so this is the most detail as I >>> have been able to find about what is happening when grub-install is run by >>> System Configurator. >>> >>> Is it possible that grub-install is not being run from within a chroot'd >>> environment? The problems with accessing /tmp and /boot/grub/device.map >>> (which I do have) seem strange to me. At the same time, the references to >>> /usr/lib/systemconfig/Boot/Grub.pm suggest to me that the execution >>> environment should be correct, but the line numbers in the warnings don't >>> match up with code that would produce those warnings. How does the >>> auto-installation get the System Configurator version that it uses to run >>> grub-install? >>> >>> If it makes any difference, I am testing SystemImager within a virtual >>> machine. I can make the fd0 access errors go away by simply disabling the >>> use of a floppy disk, but that does not fix the grub-install problems. >>> >>> -Patrick >> ------------------------------------------------------------------------- >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net's Techsay panel and you'll get the chance to share your >> opinions on IT & business topics through brief surveys - and earn cash >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >> _______________________________________________ >> Sisuite-users mailing list >> Sisuite-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/sisuite-users ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Sisuite-users mailing list Sisuite-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-users
