+++ This bug was initially created as a clone of Bug #163921 +++ I'm not sure if this related to anaconda or some other component. Please advise. Description of problem: I installed FC3 on 14 systems using kickstart installation over NFS. In every single case, the installation created disk labels with a random "1" attached to the end of it. For example, a system "soda" was created with these statements in the kickstart file: ... install nfs --server=192.168.127.200 --dir=/export/fedora-core/3 zerombr yes clearpart --all --initlabel # Disk partitioning information part /boot --fstype ext3 --size 250 --ondisk sda part / --fstype ext3 --size 20480 --ondisk sda part swap --size 16384 --ondisk sda part /disk1 --fstype ext3 --size 1 --grow --ondisk=sda ... But /etc/fstab was created with these entries: [root@soda ~]# grep LABEL /etc/fstab LABEL=/1 / ext3 defaults 1 1 LABEL=/boot1 /boot ext3 defaults 1 2 LABEL=/disk11 /disk1 ext3 defaults 1 2 LABEL=SWAP-sda3 swap swap defaults 0 0 [root@soda ~]# Observe the extra "1" on "/", "/boot" and "/disk1". This extra character is also visible during boot up: /1: clean, 151906/2626560 files, 792774/5242880 blocks ^ Checking root filesystem succeeded Remounting root filesystem in read-write mode: succeeded No volume groups found Setting up Logical Volume Management: succeeded /boot1: clean, 52/64256 files, 31131/257008 blocks ^ On a different machine, with this kickstart statements: # Disk partitioning information part /boot --fstype ext3 --size 250 --ondisk sda part / --fstype ext3 --size 20480 --ondisk sda part swap --size 16384 --ondisk sdb part /disk1 --fstype ext3 --size 1 --grow --ondisk=sda part /disk2 --fstype ext3 --size 1 --grow --ondisk=sdb part /disk3 --fstype ext3 --size 1 --grow --ondisk=sdc part /disk4 --fstype ext3 --size 1 --grow --ondisk=sdd The labels came out to be: LABEL=/1 / ext3 defaults 1 1 LABEL=/boot1 /boot ext3 defaults 1 2 LABEL=/disk11 /disk1 ext3 defaults 1 2 LABEL=/disk2 /disk2 ext3 defaults 1 2 LABEL=/disk31 /disk3 ext3 defaults 1 2 LABEL=/disk41 /disk4 ext3 defaults 1 2 Note that /disk2 was set as expected. The machines work fine otherwise, but the labelling is very confusing. How reproducible: It seemed to happened very systematically since it happened on all 14 systems, and some of them were installed more than once (due to some fine tuning). The above odd label names happened every time. Steps to Reproduce: 1. create kickstart file 2. boot target system with FC3 disk1 CD, enter "linux ks" at the prompt. 3. after the system is installed, check /etc/fstab. Actual results: Shown above. A random "1" is appended to the LABEL=. Expected results: The labels assigned to each partition should not have random "1" appended. -- Additional comment from clumens on 2005-10-05 13:36 EST -- I believe this is fixed in Rawhide. Please test with FC5test1 when it comes out and verify. Feel free to reopen if you are still experiencing this problem at that time.
That problem happens on RHEL4, but not on RHEL3 or RHEL5 Beta. I scoured the sources, and couldn't find a specific changelog entry that would be dealing with this problem.
Also note, the problem is easily reproduceable: 1. Install system from scratch 2. Take anaconda-ks.cfg and uncomment the partitioning part 3. Restart the installation 4. Partitions are name "/1", "/boot1", etc. but no "/" or "/boot" partitions are present.
The 1's seem to appear and disappear on alternate installations. That is to say, /boot becomes /boot1 after re-installation, but then if you re-install with the same kickstart file, it goes back to being /boot again.
Any word on this? It's been months now with no activity. Obviously this wouldn't be a problem for folks using the default LVM drive configs but we do not use LVM and I am sure many others do not as well. Is there some issue keeping this from being fixed?
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Any updates on this? This is really hitting some of my customers hard.
This should be fixed in the next build of anaconda by just keeping track of which drives we cleared and not reading the labels from those. Please give this a good test with the next available tree containing a new anaconda and let me know if it is working better for you.
Hi Chris - Unfortunately, I'm not sure where to find the next available tree containing a new anaconda. Would that be in /mnt/redhat/nightly/RHEL4-U6-* on porkchop? Or somewhere else? ~Bryan
Yes, that'd be the right location. I need to make sure that the latest anaconda build makes it into that tree before this fix will be usable. I'll try to look into that this afternoon.
This is fixed in anaconda-10.1.1.66-1 which is in RHEL4-U6-re20070801.nightly at least.
This does not appear to be fixed in RHEL4-U6-re20070813.0 (anaconda 10.1.1.67-1). After the first install, /etc/fstab contains: # This file is edited by fstab-sync - see 'man fstab-sync' for details LABEL=/ / ext3 defaults 1 1 LABEL=/boot1 /boot ext3 defaults 1 2 none /dev/pts devpts gid=5,mode=620 0 0 none /dev/shm tmpfs defaults 0 0 none /proc proc defaults 0 0 none /sys sysfs defaults 0 0 LABEL=/usr/cache /usr/cache ext3 defaults 1 2 LABEL=/usr/render_tmp /usr/render_tmp ext3 defaults 1 2 LABEL=SWAP-hda6 swap swap defaults 0 0 After the second install with the same kickstart file, /etc/fstab contains: # This file is edited by fstab-sync - see 'man fstab-sync' for details LABEL=/1 / ext3 defaults 1 1 LABEL=/boot /boot ext3 defaults 1 2 none /dev/pts devpts gid=5,mode=620 0 0 none /dev/shm tmpfs defaults 0 0 none /proc proc defaults 0 0 none /sys sysfs defaults 0 0 LABEL=/usr/cache1 /usr/cache ext3 defaults 1 2 LABEL=/usr/render_tmp1 /usr/render_tmp ext3 defaults 1 2 LABEL=SWAP-hda6 swap swap defaults 0 0
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2007-0816.html
I had to verify, but it does indeed appear that the 4.6 fix hasn't yet been released for 5.1. I'm not sure as to the timeline and what the plans are around this, but we'll push this as a regression since it appears to be the case presently with 4.6 being out. This event sent from IssueTracker by fhirtz issue 135073
Still seeing this issue in RH5.1. anaconda-11.2.87-1 is the version on the DVD.
The issue should be resolved in Red Hat Enterprise Linux 5.2. See http://rhn.redhat.com/errata/RHBA-2008-0397.html and/or Bug 415861.