[Spacewalk-list] Strange mounting problems while kickstarting

[Sascha Bendix]

Hi all,

I'm currently stuck in a weird situation and hope anyone of you has seen a similar situation before:

Short version: When try to kickstart a system, which was kickstarted before, the install process stalls when mounting the root device to /mnt/sysimage.

Long version:
I got a spacewalk server version 1.1 (with all current updates from the repository). After the upgrade I wanted to create a CentOS 5.5 kickstart installation profile. I unpacked the first of the install cds, create a distribution in spacewalk and created a kickstart profile.

For testing the kickstart profile I created a VMWare ESXi vm and bootet the according entry. To test overall spacewalk installation I first bootet my old CentOS 5.4 profile which was working well.

After this I tried my new CentOS 5.5 profile and it seems that the installation always crashed when trying to mount the root device. Here is a an extract of the syslog (booting with syslog=<remote-ip> loglevel=debug)

WARNING  Unresolvable dependency perl(Crypt::DES) in perl-Net-SNMP.
INFO     moving (1) to step install.
INFO     anaconda.methodstr = http://spacewalk.domain.tld/ks/dist/centos-5 1.
INFO     moving (1) to step enablefilesystems.
INFO     disk.commit() for /dev/sda.
INFO     formatting swap as swap.
INFO     formatting / as ext3.
INFO     Format command:  ['/usr/sbin/mke2fs', '/tmp/sda5', '-i', '4096', '-j'].
INFO     formatting /var/log as ext3.
INFO     Format command:  ['/usr/sbin/mke2fs', '/tmp/sda2', '-i', '4096', '-j'].
INFO     formatting /boot as ext3.<14>INFO     Format command:  ['/usr/sbin/mke2fs', '/tmp/sda1', '-i', '4096', '-j']
INFO     trying to mount sda5 on /.

After this message I can neither change the console nor anything else.

Oh I forgot, both profile use "clearpart --all" and create complete new partitions.

It's getting even stranger: When erasing the partition table before the kickstart boot (by booting into rescue mode, open fdisk and type o and w) it wents all fine.

Another bypass trick is to disable the pre script which tries to find the system-id file for using the same system profile when doing a reinstallation. But then you got two system profiles for the same system in spacewalk.

I already verified that the kernel was correctly downloaded and used a new kickstart profile. 

Has anybody seen a similar situation before or can give me a hint how to proceed debugging?

Thanks in advance

Sascha Bendix

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.