The error message states the following "An error occurred trying to format system/root_lv. This problem is serious, and the install cannot continue. Press
And on tty5 (Alt + 5) another informative message "Could not stat /dev/system/root_lv --- No such file or directory. The device apparently does not exist; did you specify it correctly?"
It worked fine with the 5.0 tree, but when I wanted to kickstart with 5.1 I get an error that mkfs fails with /dev/system/root_lv and yes - there isn't a lvm path like that under the /dev.
After allot of debugging and messing around I found a workaround for it! It isn't easy nor is it for novice administrators so I would recommend just plain old install without the LVM support.
The problem is that the kickstart wont bring up lvm volumes before it tries to make a file system on them. Yes, it creates the physical volume, volume group and logical volumes, but it fails to activate them as the the LV-s are marked as created in the prep stages. This leaves us with a fully working LVM setup that is not activated and so the install crashes.
To fix the problem we need to hack the minstg2.img file in the repository. First make a backup of this file and copy it to a different folder. As I hacked it under Fedora 8 we need a package called "squashfs-tools" to unpack the image.
In the local folder run "unsquashfs minstg2.img" - this will create "squashfs-root" folder with the file system unpacked inside.
The problematic file is located "squashfs-root/usr/lib/anaconda" and the file is "fsset.py".
On line 1753 there is "self.volumesCreated = 1" - this should be changed "self.volumesCreated = 0".
Warning - watch the spacing as python is very touchy with extra or missing spaces.
Save the file and "cd ../../../../" back to the beginning.
Now we need to create and new image and for that I strongly recommend creating an image with a different name.
To create the image run "mksquashfs squashfs-root test.img" and it will create the new image.
Warning - back up the original if you have not done it for now!!!
copy the test.img the the repository server and replace the original minstg2.img with the test.img.
This should do the trick and kickstarting PC-s with LVM should work now.
As I mentioned - this is an hack not a solution, so if you have automatic mirroring and the image gets rewritten with the old one copy the test.image back.
Also this bug could be fixed in the future so this hack will get obsoleted some time...
Update: Added exact error messages and my local mirror updated the minstg2.img from upstream, so I had to copy the test.img to the minstg2.img again...
Have fun.
Blogged with Flock
6 comments:
Just wondering... have you created a bug report?
The interesting thing on this issue is that it does not exist in RHEL5.1, only in Centos 5.1...
Btw. Instead of messing around with minstg2.img, just create an update image and copy it to the os/images directory.
cd path_to_centos_cd/os/images
dd if=/dev/zero of=updates.img bs=1k count=1440
mke2fs updates.img
mount updates.img /mnt -o loop
cp fsset.py /mnt
umount /mnt
If I remember correctly I found a bug report on the subject.
I cant comment on RHEL as I don't have a RHEL repository. The few servers that we have are installed from the original CD and CD install works. We have around 10 administrators who kickstart servers and PC-s from our internal repositories through http. As I'm responsible for the kictart generation and repository management I'm keen to hack th original problematic parts and sha1 the broken and fixed versions. This will give me report as to what is still broken and what is fixed/unknown so its just how I do things :)
updates.img is a nice touch, but unfortunately we sync our internal repository so when an updated minstg2.img is out the added updates.img can cause more problems than solve them. Instead I have a small php script that administrator can run to check if the image is still broken and if it is it will copy test.img to minstg2.img. It is a crude fix, but at least the administrators know if they have the ability to kickstart or not. And if the hash is not good nor bad they get a message to inform me (just in case I have missed that in my daily report).
It is not just about fixing a problem, it is about giving feedback to the administrators so they would not guess if everything works or not.
*sigh* Well, for what it's worth, for anyone else running into this problem, it would seem that RHEL 5.2 also has this "bug" present.
I've found another work-around - create a swap volume on the LVM.
The LVM gets activated if there is a swap on it - create a silly small one - you don't need to use it.
It worked for me, tons of thanks to you.
It solved my 15+ days effort.
I just hit this problem too in CentOS 5.4!
This was my kickstart disk config:
zerombr
bootloader --location=mbr --append="vga=791"
clearpart --drives=sda --all
part /boot --fstype ext3 --size=100 --ondisk=sda --asprimary
part pv.01 --size=100 --grow --ondisk=sda --asprimary
volgroup VolGroup00 pv.01
logvol / --fstype ext3 --name=root --vgname=VolGroup00 --size=100 --grow
Which failed as above so I had to add a small swap LV as a workaround:
logvol swap --fstype swap --name=swap --vgname=VolGroup00 --size=100
logvol / --fstype ext3 --name=root --vgname=VolGroup00 --size=100 --grow
Most annoying!
Post a Comment