Bug 209291 - kickstart install creates incorrect labels by appending a trailing "1"
kickstart install creates incorrect labels by appending a trailing "1"
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: anaconda (Show other bugs)
4.0
All Linux
high Severity low
: ---
: ---
Assigned To: Chris Lumens
:
Depends On:
Blocks: 234251
  Show dependency treegraph
 
Reported: 2006-10-04 08:52 EDT by Bastien Nocera
Modified: 2010-10-22 02:17 EDT (History)
4 users (show)

See Also:
Fixed In Version: RHBA-2007-0816
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-15 11:35:23 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bastien Nocera 2006-10-04 08:52:40 EDT
+++ 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@redhat.com 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.
Comment 1 Bastien Nocera 2006-10-04 08:54:18 EDT
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.
Comment 2 Bastien Nocera 2006-10-04 08:56:51 EDT
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.
Comment 3 Bryan Mason 2006-10-24 14:50:22 EDT
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.
Comment 7 Need Real Name 2007-01-19 08:26:59 EST
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?
Comment 14 RHEL Product and Program Management 2007-05-09 05:26:16 EDT
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.
Comment 15 Bryan Mason 2007-06-13 17:22:02 EDT
Any updates on this?  This is really hitting some of my customers hard.
Comment 18 Chris Lumens 2007-07-13 10:34:19 EDT
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.
Comment 19 Bryan Mason 2007-07-13 19:15:32 EDT
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
Comment 20 Chris Lumens 2007-07-17 13:52:43 EDT
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.
Comment 21 Chris Lumens 2007-08-01 14:11:10 EDT
This is fixed in anaconda-10.1.1.66-1 which is in RHEL4-U6-re20070801.nightly at
least.
Comment 23 Bryan Mason 2007-09-26 16:55:52 EDT
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
Comment 26 errata-xmlrpc 2007-11-15 11:35:23 EST
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
Comment 30 Issue Tracker 2007-12-06 21:49:19 EST
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
Comment 35 Allen May 2009-10-21 10:59:45 EDT
Still seeing this issue in RH5.1.  anaconda-11.2.87-1 is the version on the DVD.
Comment 36 Bryan Mason 2009-10-21 12:41:12 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.