Re: [sisuite-users] Imaging issues with RH ES 4
[EMAIL PROTECTED] wrote: Andrea, Find below the autoinstallscript.conf. What appears to have happended is that /selinux was imaged and then propagated to the new machine. By removing /selinux files, creating /.autorelabel and rebooting /selinux was properly mounted and 'fixfiles relabel' was run. Hi all, I think that we should add some common unwanted patters to the exclusions automatically made by systemimager during image retrieval by si_getimage. In some recent distributions some pseudo-filesystem are not reported with mount. On the other looking in /proc/mounts doesn't resolve, because there are also the filesystems mounted *under* others (usually rootfs, initramfs, etc). Here is a list of patterns that we could always exclude: # selinux stuff /selinux/* # eventfs in SuSE /lib/klibc/events/* # mounted media devices not reported by mount /media/* # NFS stuff /var/lib/nfs/* # LVM caches and backups (automatically re-created at the first boot) /etc/lvm/.cache /etc/lvm/backup/* /etc/lvm/archive/* What do you think? Do you know other patterns that should be automatically excluded? Regards, -Andrea PS for David: have you tried to remove /selinux/* from your image and try to repeat the installation? this is equivalent to run si_getimage with --exclude '/selinux/*'. - 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.phpp=sourceforgeCID=DEVDEV ___ sisuite-users mailing list sisuite-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-users
Re: [sisuite-users] Cannot Open libc.so.6
Kenneth Jacker Tue, 13 Feb 2007 10:15:22 -0800 ar But... why do you have /lib64 if your machine is a i686??? That I never found out ... :-( After removing the the /lib64 files, I rebuilt SI and it worked! The last problem was finally solved. -Kenneth Looks like I got bitten by this as well... the package libc6-amd64 in Debian appears to be a default package in the upcoming Etch release. My image server is Intel hardware, and I know I didn't add this package myself. (It may have been a dependency of some other package, but I don't know for sure.) I removed it, rebuilt, and now things exist in /lib rather than /lib64. With Etch moving closer to release, maybe a note in the Debian install section about this package causing issues for 32-bit systems is warranted? (perhaps under the list of dependencies?) On a related note, do average folk have edit rights to the wiki, if an account is created? I hate to sound lazy by suggesting changes if it was something that you would prefer we do. But then, I know for certain projects, you don't want the general public editing things all willy-nilly, either. jef - 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.phpp=sourceforgeCID=DEVDEV ___ sisuite-users mailing list sisuite-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-users
Re: [sisuite-users] building debian packages
On Feb 20, 2007, at 2:39 PM, Bas van der Vlies wrote: The debian packages are available at: ftp://ftp.sara.nl/pub/outgoing/systemimager I have only tested the release with rsync and i could reinstall a node. In the systemimager-server package are also the monitord and the bittorent init.d scripts. They belong in a separate package but for the moment it is oke. The main goal for us is to test the bittorent setup I just want to thanks the developers for version 3.7.6. We are upgrading from 3.2 and with the new version it is more configurable and easier to setup. The monitor software works as a charm and we are pleased with the bittorent functionality. Thanks -- Bas van der Vlies [EMAIL PROTECTED] - 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.phpp=sourceforgeCID=DEVDEV ___ sisuite-users mailing list sisuite-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-users
Re: [sisuite-users] Imaging issues with RH ES 4
Yes I have removed the /selinux/* from the image however I'm waiting for some new machines to try again. I agree that adding the patterns would be the fast solution.Of course the best solution would be to have mount/mtab show all mounts ... I could open a ticket with RH however I'm not sure I would get too far. Andrea Righi [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 2007/02/22 04:17 Please respond to [EMAIL PROTECTED]; Please respond to sisuite-users@lists.sourceforge.net To [EMAIL PROTECTED] cc sisuite-dev sisuite-devel@lists.sourceforge.net, sisuite-users@lists.sourceforge.net Subject Re: [sisuite-users] Imaging issues with RH ES 4 [EMAIL PROTECTED] wrote: Andrea, Find below the autoinstallscript.conf. What appears to have happended is that /selinux was imaged and then propagated to the new machine. By removing /selinux files, creating /.autorelabel and rebooting /selinux was properly mounted and 'fixfiles relabel' was run. Hi all, I think that we should add some common unwanted patters to the exclusions automatically made by systemimager during image retrieval by si_getimage. In some recent distributions some pseudo-filesystem are not reported with mount. On the other looking in /proc/mounts doesn't resolve, because there are also the filesystems mounted *under* others (usually rootfs, initramfs, etc). Here is a list of patterns that we could always exclude: # selinux stuff /selinux/* # eventfs in SuSE /lib/klibc/events/* # mounted media devices not reported by mount /media/* # NFS stuff /var/lib/nfs/* # LVM caches and backups (automatically re-created at the first boot) /etc/lvm/.cache /etc/lvm/backup/* /etc/lvm/archive/* What do you think? Do you know other patterns that should be automatically excluded? Regards, -Andrea PS for David: have you tried to remove /selinux/* from your image and try to repeat the installation? this is equivalent to run si_getimage with --exclude '/selinux/*'. - 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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=DEVDEV___ sisuite-users mailing list sisuite-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-users
Re: [sisuite-users] Booting From Local Hard drive
Hi... My problem got solved, here is the solution. Solution: While I was searching for the solution of this problem, I saw almost same problem posted on syslinux users mailing lists. Here is the link (http://syslinux.zytor.com/archives/2007-February/008075.html ) and this problem got solved by installing new version of Pxelinux bootloader. Since I was using version 2.00 of pxelinux, so I thought to upgrade it to syslinux-3.36 I downloaded syslinux version 3.36 from this link (http://www.kernel.org/pub/linux/utils/boot/syslinux/) This was syslinux-3.36.tar.gz , so I untared it using the command (tar xvzf ) Then I copied pxelinux.0 ( from syslinux-3.36) to /tftpboot , but before copying the new file, I made a backup of the old pxelinux.0 of pxelinux version 2.00 ( b/e I wanted to check if there was some problem in the old version or not) After pxelinux bootloader got upgraded to new version, I rebooted the client. The client tried to boot from the local hard drive after configuring itself from the network, it waited a couple of secs and LILO came up! And all was good. For checking if there was really some problem with the old version, I again replaced the backup file of pxelinux.0 from the new pxelinux.0 file. Rebooted the client, it tried to boot from the local hard drive after configuring itself from the network, but it again got stuck there! So there was problem with the pxelinux old version bootloader (version 2.00) as it never allows the client to boot from the local hard drive after it configures itself from the network. Im Thankful to all of those who suggested me solutions to this problem. Best Regards, Hiba Express yourself instantly with MSN Messenger! MSN Messenger Download today it's FREE! - 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.phpp=sourceforgeCID=DEVDEV___ sisuite-users mailing list sisuite-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-users
