Kickstart generating partition numbers with 1 on end.

[Robert Walker_8]

Hi,

Over the past year playing with RHEL installs, generally reinstalling servers a number of times - I have found that a number of systems get 1 placed on the end of their label names (when looking at /etc/fstab or e2label). Thus root as / is /1 and /usr is /usr1.

This happens even when I tell Anaconda to initialise the disk completely and or so when using clearpart --initlabel --all as well.

Its a nuisance as everything refering to labels ends up with 1 on the end. I havent seen /2 or 2 added so cannot understand why it does this?

Any ideas?

[Vitaly Karasik_1]

is there any chance that there is second harddisk on these computers?

[Robert Walker_8]

Gday in this case the system is a virtual one running vmware and it has 6 scsi disks. It doesnt seem to matter if its virtual or real and whether it has one disk or two.

As the problem has happened on other servers. As for multiple drives it doesnt put 2, 3, 4 etc for each drive just 1 on the end.

It would appear as if clearpart isnt working properly, and that the part routine either sees an existing filesystem and thus decides to call it /1 to ensure no duplication?

[Alexander Chuzhoy]

At a time a used to test kickstart installation on some machine:
Sometimes the installation ended with "1" at the end of partition labels and sometime without - on the same machine.
I assumed that it's because sometimes the MBR wasn't cleared properly, so the system thinks that it has partitions already.

Anyway you can deal with it in postinstall section of kickstart-where you can simply relable the partitions with e2label utility -helped me.

[Robert Walker_8]

Gday Alexander,


Ive had problems using e2label and am wary of this as particularly the / or root partition - sometimes causes problems with grub and kernel booting etc.

Was hoping to find a preventative approach rather than using antibiotics as the cure!

Rob.

[Steven E. Protter]

Shalom,

This is a bug that I've had to manually fix post installation.

I have not seen it with RH 4 update 3, but have with prior releasees.

SEP

[Robert Walker_8]

Gday SEP,

It must still exist in RHEL 4 Update 3 as this is what were using AS & ES.

It is comming up alot as Im working on a kickstart process and running rebuilds a number of times on a test vmware server.

Thanks though!

Rob.

[Alexander Chuzhoy]

You can always clear the MBR before the kickstart...
As for the booting problem after e2label:
Of course you'd have to parse the /etc/fstab with sed and to remove 1 if you use the e2label- thus some scripting must be involved. Otherwise you have different missmatch between a label and a line in /etc/fstab - that's why the machine has problem booting.

[Robert Walker_8]

Gday again,

Have been trying to clear the mbr in the %pre part of anaconda kickstart script.

Even though this function works, I can see my echo command and the dd command working it doesnt seem to solve the problem.

Any ideas,

ta,

Robert.

for disks in `list-harddrives | cut -d " " -f 1`; do
echo "**************************************** Zapping MBR $disks ****************************************"
dd if=/dev/zero of=/tmp/$disks bs=1024 count=100
done

[Robert Walker_8]

Gday,


It would appear that I have got redhat to look at this one and have managed to convince them its a bug not a feature!

They have created a fix at developers level and passing it back to support group for testing.

Hope to have some news shortly!

[James Roberto]

Hi robert,

how did you go with Redhat in regards with the /1 partition? I totally had the same problem and had no idea why it was doing this. i am currenty running Redhat 4 update4. if you could reply that would be greatly appreciated.

thanks
james

[Robert Walker_8]

Gday James,


The last I heard from Redhat (7 Oct 06) was they have agreed it is a bug and have reopened a bugzilla that was found sometime ago on this problem:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209291

Robert.

[Robert Walker_8]

See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209291

As Redhat have finally decided this problem is a bug not a feature.

Hopefully we shall see a fix in the not too distant future :)

Robert.