Re: fai setup
> hello all, > i ran the fai-setup, and it was fine. > however, in fai guide there is written that "it needs more than 390MB MBtes > disk space" and my fai-setup has just 302MB of data. > i hope there is no problem with the setup. > Did you notice any error messages? If not, you should be fine. Mine has 570MB, but that is of course non-standard. Don't panic - keep going and see what happens once you start installing your clients. Best, Michael pgpGnRim3jsk7.pgp Description: PGP signature
install different kernel
Hello, I am a little confused ATM. What is the correct way to install a different kernel (than installed on the fai-server) on a client. We have a setup with dhcp, tftpd and pxe. If I set another kernel in the pxelinux.cfg/XXX file, everything works fine. In the very last steps of the client setup there comes an error, that the kernel modules for the different are missing. So howto add another kernel? Install is as an debian package? BR Uwe -- kiste lat: 54.322684, lon: 10.13586
Re: install different kernel
Uwe Kastens wrote: > Hello, > > I am a little confused ATM. What is the correct way to install a > different kernel (than installed on the fai-server) on a client. Make an entry for the different kernel package in your software package lists - but see below. > We have a setup with dhcp, tftpd and pxe. If I set another kernel in the > pxelinux.cfg/XXX file, everything works fine. In the very last steps > of the client setup there comes an error, that the kernel modules for > the different are missing. Wait. Here, you're not talking about the kernel and modules being _installed_ but the kernel and modules _running at install time_. That's a difference. You did correctly set the installation kernel(and maybe initrd) in the pxe config, but the modules for this kernel need to be in the nfsroot or put altogether in the initial ramdisk. Just create the right nfsroot, or copy the data into the nfsroot (I'm not sure how to get such a modification persistent right now). > So howto add another kernel? Install is as an debian package? Yes, to gat a different kernel _installed_ , a package is the best and recommended way. Otherwise, you can also use fcopy and ftar to unpack files and directories with kernel and modules data. Henning
grub-install problem
Hello,
We need to patch grub-install each time we build nfsroot new. Anybody
else with this problem?
debian lenny
*** /srv/fai/nfsroot/live/filesystem.dir/usr/sbin/grub-install.orig
2009-02-06 13:39:42.0 +0100
--- /srv/fai/nfsroot/live/filesystem.dir/usr/sbin/grub-install
2009-02-06 13:40:30.0 +0100
*** test -n "$mklog" && log_file=`$mklog`
*** 371,377
sync
# On XFS, sync() is not enough.
! if [ `grub-probe -t fs ${grubdir}` = "xfs" ] ; then
xfs_freeze -f ${grubdir} && xfs_freeze -u ${grubdir}
# We don't have set -e. If xfs_freeze failed, it's worth trying anyway,
# maybe we're lucky.
--- 371,377
sync
# On XFS, sync() is not enough.
! if [ `grub-probe --device-map=${device_map} -t fs ${grubdir}` = "xfs"
] ; then
xfs_freeze -f ${grubdir} && xfs_freeze -u ${grubdir}
# We don't have set -e. If xfs_freeze failed, it's worth trying anyway,
# maybe we're lucky.
BR
Uwe
--
kiste lat: 54.322684, lon: 10.13586
Re: grub-install problem
> Hello, > > We need to patch grub-install each time we build nfsroot new. Anybody > else with this problem? > > debian lenny > [...] Yes, see here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=513216 (with exactly the same bugfix). Apparently you can safely ignore this error. Best, Michael pgpOmNPmKefwW.pgp Description: PGP signature
Re: setup-storage for raid5 + lvm
[...] > > The error message is the following (full log is at > http://paste.debian.net/34215/) > The uninitialized stuff warnings indicated some bugs that I need to look into, but that doesn't seem to be the showstopper. > > Executing: /lib/udev/vol_id -u /dev/sda2 > Command /lib/udev/vol_id -u /dev/sda2 had exit code 4 > Failed to obtain UUID for /dev/sda2 > > I originally wanted to have one swap slice on each disk, but in this > case the error is on the sdb swap partition: > > Executing: /lib/udev/vol_id -u /dev/sdb2 > Command /lib/udev/vol_id -u /dev/sdb2 had exit code 4 > Failed to obtain UUID for /dev/sdb2 > > Any clue? > That should only occur with some old mkswap versions that did not set up the UUID, but that doesn't seem to be the case here: Executing: udevsettle --timeout=10 && mkswap /dev/sda2 (STDOUT) Setting up swapspace version 1, size = 1069281 kB (STDOUT) no label, UUID=3aa0ad8c-b7c9-428d-a2be-3511298c86af So, mysteriously, that information is lost afterwards. Hmm, looking at the code of vol_id it seems that parted might have overridden the volume id for /dev/sda2 (instead of /dev/sda1 or /dev/sda3). Could you re-run that failing installation and, once it aborts, do parted -s /dev/sda print Thanks, Michael pgps9Bjmqc7Be.pgp Description: PGP signature
Re: setup-storage for raid5 + lvm
Michael Tautschnig a écrit : Executing: /lib/udev/vol_id -u /dev/sda2 Command /lib/udev/vol_id -u /dev/sda2 had exit code 4 Failed to obtain UUID for /dev/sda2 I originally wanted to have one swap slice on each disk, but in this case the error is on the sdb swap partition: Executing: /lib/udev/vol_id -u /dev/sdb2 Command /lib/udev/vol_id -u /dev/sdb2 had exit code 4 Failed to obtain UUID for /dev/sdb2 Any clue? That should only occur with some old mkswap versions that did not set up the UUID, but that doesn't seem to be the case here: Executing: udevsettle --timeout=10 && mkswap /dev/sda2 (STDOUT) Setting up swapspace version 1, size = 1069281 kB (STDOUT) no label, UUID=3aa0ad8c-b7c9-428d-a2be-3511298c86af So, mysteriously, that information is lost afterwards. Hmm, looking at the code of vol_id it seems that parted might have overridden the volume id for /dev/sda2 (instead of /dev/sda1 or /dev/sda3). Could you re-run that failing installation and, once it aborts, do parted -s /dev/sda print This looks ok: # parted -s /dev/sda print [...] Number Start End SizeType File system Flags 1 32.3kB 535MB 535MB primary ext2 raid 2 535MB 1604MB 1069MB primary linux-swap 3 1604MB 320GB 318GB primary raid No raid on sda2, but vol_id disagrees: # /lib/udev/vol_id --export /dev/sda2 ID_FS_USAGE=raid ID_FS_TYPE=linux_raid_member [...] So vol_id needs the --skip-raid option to return the uuid; a small patch of setup-storage makes the installation work much better: --- Fstab.pm.~1~2009-04-22 11:41:56.0 + +++ Fstab.pm2009-04-27 12:41:55.0 + @@ -94,7 +94,7 @@ # or labels, use these if available my @uuid = (); &FAI::execute_ro_command( -"/lib/udev/vol_id -u $device_name", \...@uuid, 0); +"/lib/udev/vol_id --skip-raid -u $device_name", \...@uuid, 0); # every device must have a uuid, otherwise this is an error (unless we # are testing only) I don't know if this patch is a good idea, though, or if this behavior of vol_id should be considered as a feature or a bug. -- Nicolas
Re: setup-storage for raid5 + lvm
[...] >> >> So, mysteriously, that information is lost afterwards. Hmm, looking at the >> code >> of vol_id it seems that parted might have overridden the volume id for >> /dev/sda2 (instead of /dev/sda1 or /dev/sda3). Could you re-run that failing >> installation and, once it aborts, do >> >> parted -s /dev/sda print >> >> > > This looks ok: > > # parted -s /dev/sda print > [...] > Number Start End SizeType File system Flags > 1 32.3kB 535MB 535MB primary ext2 raid > 2 535MB 1604MB 1069MB primary linux-swap 3 1604MB > 320GB 318GB primary raid > > > No raid on sda2, but vol_id disagrees: > > # /lib/udev/vol_id --export /dev/sda2 > ID_FS_USAGE=raid > ID_FS_TYPE=linux_raid_member > [...] > Did /dev/sda2 ever belong to a RAID array? Could you please try - parted -s /dev/sda set 2 raid off - run vol_id - mkswap /dev/sda2 - run vol_id > So vol_id needs the --skip-raid option to return the uuid; a small patch > of setup-storage makes the installation work much better: > > --- Fstab.pm.~1~2009-04-22 11:41:56.0 + > +++ Fstab.pm2009-04-27 12:41:55.0 + > @@ -94,7 +94,7 @@ > # or labels, use these if available > my @uuid = (); > &FAI::execute_ro_command( > -"/lib/udev/vol_id -u $device_name", \...@uuid, 0); > +"/lib/udev/vol_id --skip-raid -u $device_name", \...@uuid, 0); > > # every device must have a uuid, otherwise this is an error (unless we > # are testing only) > > I don't know if this patch is a good idea, though, or if this behavior > of vol_id should be considered as a feature or a bug. > Hmm, that feels a bit like a hack as I don't yet understand why there is a RAID signature at all. And furthermore this option is not available in etch's udev. Best, Michael pgpT3e5kA5FfW.pgp Description: PGP signature
Re: setup-storage for raid5 + lvm
Michael Tautschnig a écrit : [...] So, mysteriously, that information is lost afterwards. Hmm, looking at the code of vol_id it seems that parted might have overridden the volume id for /dev/sda2 (instead of /dev/sda1 or /dev/sda3). Could you re-run that failing installation and, once it aborts, do parted -s /dev/sda print This looks ok: # parted -s /dev/sda print [...] Number Start End SizeType File system Flags 1 32.3kB 535MB 535MB primary ext2 raid 2 535MB 1604MB 1069MB primary linux-swap 3 1604MB 320GB 318GB primary raid No raid on sda2, but vol_id disagrees: # /lib/udev/vol_id --export /dev/sda2 ID_FS_USAGE=raid ID_FS_TYPE=linux_raid_member [...] Did /dev/sda2 ever belong to a RAID array? Could you please try - parted -s /dev/sda set 2 raid off - run vol_id - mkswap /dev/sda2 - run vol_id Nothing interesting happens... The disk has been in a raid 1 array a while ago, but the partitioning was different, and has been cleaned up by the new installation. -- Nicolas
Re: setup-storage for raid5 + lvm
> Michael Tautschnig a écrit : >> [...] >> So, mysteriously, that information is lost afterwards. Hmm, looking at the code of vol_id it seems that parted might have overridden the volume id for /dev/sda2 (instead of /dev/sda1 or /dev/sda3). Could you re-run that failing installation and, once it aborts, do parted -s /dev/sda print >>> This looks ok: >>> >>> # parted -s /dev/sda print >>> [...] >>> Number Start End SizeType File system Flags >>> 1 32.3kB 535MB 535MB primary ext2 raid >>> 2 535MB 1604MB 1069MB primary linux-swap 3 >>> 1604MB 320GB 318GB primary raid >>> >>> >>> No raid on sda2, but vol_id disagrees: >>> >>> # /lib/udev/vol_id --export /dev/sda2 >>> ID_FS_USAGE=raid >>> ID_FS_TYPE=linux_raid_member >>> [...] >>> >>> >> >> Did /dev/sda2 ever belong to a RAID array? Could you please try >> - parted -s /dev/sda set 2 raid off >> - run vol_id >> - mkswap /dev/sda2 >> - run vol_id >> > > Nothing interesting happens... The disk has been in a raid 1 array a > while ago, but the partitioning was different, and has been cleaned up > by the new installation. > Ok, maybe mdadm helps, but I don't know for sure how to apply it: - Does mdadm --zero-superblock /dev/sda2 work? If not, you might need to run mdadm --zero-superblock /dev/sda. - Does running vol_id work afterwards? Thanks, Michael pgpdbig5dSMCL.pgp Description: PGP signature
Re: setup-storage for raid5 + lvm
Michael Tautschnig a écrit : Michael Tautschnig a écrit : [...] So, mysteriously, that information is lost afterwards. Hmm, looking at the code of vol_id it seems that parted might have overridden the volume id for /dev/sda2 (instead of /dev/sda1 or /dev/sda3). Could you re-run that failing installation and, once it aborts, do parted -s /dev/sda print This looks ok: # parted -s /dev/sda print [...] Number Start End SizeType File system Flags 1 32.3kB 535MB 535MB primary ext2 raid 2 535MB 1604MB 1069MB primary linux-swap 3 1604MB 320GB 318GB primary raid No raid on sda2, but vol_id disagrees: # /lib/udev/vol_id --export /dev/sda2 ID_FS_USAGE=raid ID_FS_TYPE=linux_raid_member [...] Did /dev/sda2 ever belong to a RAID array? Could you please try - parted -s /dev/sda set 2 raid off - run vol_id - mkswap /dev/sda2 - run vol_id Nothing interesting happens... The disk has been in a raid 1 array a while ago, but the partitioning was different, and has been cleaned up by the new installation. Ok, maybe mdadm helps, but I don't know for sure how to apply it: - Does mdadm --zero-superblock /dev/sda2 work? If not, you might need to run mdadm --zero-superblock /dev/sda. - Does running vol_id work afterwards? You got it: # mdadm --zero-superblock /dev/sda2 # /lib/udev/vol_id -u /dev/sda2 6428a2d1-c30d-4916-ab6b-625117989651 # I wonder how this mdadm data was still there, though... Thanks for your help, -- Nicolas
