Bug 410011 - kickstart/anaconda partition order
kickstart/anaconda partition order
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
9
All Linux
low Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
:
: 441424 453813 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-04 05:04 EST by Bjorge Solli
Modified: 2010-01-14 15:18 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-08-26 13:57:18 EDT
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 Bjorge Solli 2007-12-04 05:04:08 EST
Description of problem:
From fedora-list@redhat.com
Bjorge Solli wrote:
> Chris Snook wrote:
>> Bjorge Solli wrote:
>>> Empty disk before install, both fedora 7 and 8.
>>>
>>> When I use part like this in a ks-file:
>>> #Partition clearing information
>>> clearpart --all --initlabel
>>> #Disk partitioning information
>>> part /reboot --fstype=vfat --size=256 --asprimary
>>> part / --fstype=ext3 --size=40000 --asprimary
>>> part swap --size=2048 --asprimary
>>> part /scratch --fstype=ext3 --size=1 --grow --asprimary
>>>
>>> ..they don't show up in that order. Is there a way to tell fedora to keep
the order? I tried using anaconda too, with the same result.
>>>
>>> regards
>>> Bjørge
>>>
>>> PS. --onpart would not work since the partition table is empty or different
before install.
>>>
>>
>> I've always done the partitioning in %pre and used onpart.  You can also get
things in the desired order if you use --onpart for only the second out of three
partitions, but I don't know of a way to do this with four partitions.  This
probably deserves a BZ, as it's been around (and annoying) for quite a while.

> I'm opting to do it in %pre too, but it should be possible to do in the
kickstartfile, imho.

Agreed.  I've been irked about this for a while.

Version-Release number of selected component (if applicable):
At least in fedora 7 and 8

How reproducible:
every time.

Steps to Reproduce:
1. use kickstart or visual mode
2. partitioning part
3. insert patitions as described, in that order.
4. the final order is not the same
  
Actual results:
wrong order of partitions

Expected results:
same order as entered

Additional info:
Comment 1 Chris Lumens 2008-04-20 16:54:25 EDT
*** Bug 441424 has been marked as a duplicate of this bug. ***
Comment 2 Andy Lindeberg 2008-06-04 10:09:51 EDT
Have you encountered the same problem in Fedora 9?
Comment 3 George R. Goffe 2008-06-05 02:33:58 EDT
Hi,

I looked at anaconda for a while and found the sort that changes the order of
the partitions.

I AM NOT a python guy. 

Why is the partition map even sorted at all?

I can try to find my info on this if you really want it. I did the research a
long time ago... around fc 5 era or maybe rhel 3. Yes! It's been a thorn in my
side for a LONG time too. :-(

Regards,

George...
Comment 4 Bjorge Solli 2008-06-05 04:52:32 EDT
(In reply to comment #2)
> Have you encountered the same problem in Fedora 9?

Yes.
Comment 5 Wenzhuo Zhang 2008-08-01 00:30:50 EDT
When installing RHEL5, I added several lvm logical volumes in Disk Druid in the
following order:

swap  2048M
/     1024M
/usr  4092M
/tmp  512M
/var  10240M
/home 20480M

But anaconda actually created the logical volumes in the following order:

/
/home
/usr
/var
/tmp
swap

As I recall, anaconda has had this problem since the old days of rh5/6. When I
wanted to create partitions in my prefered order, I had to switch to the
console, and partition the hardisks manually beforehand.

IMHO, anaconda should preserve the partition ordering as entered, and ideally,
Disk Druid should allow users to move up and down partitions/raid/volumes.
Comment 6 Chris Lumens 2008-08-06 15:35:39 EDT
*** Bug 453813 has been marked as a duplicate of this bug. ***
Comment 7 George R. Goffe 2008-08-06 17:00:34 EDT
Do "we" have a current status on this bug?

I REALLY object to it's classification of low in priority. I have had to jump through hoops to get around this problem. The research I have done shows a sort of the partition table with makes absolutely NO SENSE TO ME. Why is the sort even being done?

As for answering the question of Fedora Core 9, I tried installing and running FC9 for a few weeks and found it WOEFULLY deficient in functionality.

Thanks!

George...
Comment 8 Bjorge Solli 2008-08-19 04:31:50 EDT
(In reply to comment #7)
> I REALLY object to it's classification of low in priority. 

I am unsertain if it should be me (as the reporter) or the assigned group that should escalate the classification.

Bjørge
Comment 9 George R. Goffe 2008-08-19 18:29:19 EDT
(In reply to comment #8)
> (In reply to comment #7)
> > I REALLY object to it's classification of low in priority. 
> 
> I am unsertain if it should be me (as the reporter) or the assigned group that
> should escalate the classification.
> 
> Bjørge

Bjorge,

I am CERTAIN that my comment was addressed to the assigned group for this bug. 

I apologize if I have mis-directed my comment on this bug.

Regards,

George...
Comment 10 Bjorge Solli 2008-08-20 03:12:22 EDT
Oh, that I got, I just wondered if it was apropriate for me, who set it to low in the first place when I reported it, to bump it up as no maintainer seems to look at this. I just set it to medium. If that was not for me to do, I politely ask the maintainer(s) to set it to low again.

Bjørge
Comment 11 Chris Lumens 2008-08-26 13:57:18 EDT
What are you trying to solve by putting the partitions into a specific order?  I think for the typical use case, most people really don't care, and adding widgets into the UI is going to make things even more complicated than they already are.  The partitioning code as it exists today is in a bit of a holding pattern, so we are unlikely to even consider working on this for quite a while.

For the kickstart case, you can easily add your partitions exactly the way you want them with a %pre scripts and then use --onpart for your various partitions.  We've provided all the capability to do this sort of complicated partition manipulation, you just have to put the pieces together.
Comment 12 David Woodhouse 2008-08-26 14:17:58 EDT
When setting up RAID and making one disk a clone of another, I want the disks to be identical. I want /dev/md0 to be comprised of /dev/sda1 and /dev/sdb1 -- I don't want it to be /dev/sda1 and /dev/sdb3. Because that's just going to confuse the hell out of me if I ever have to do any maintenance.

I have a machine with DMA problems which with recent (libata) kernels has taken to kicking one device out of the RAID1 every time it boots, before it falls back to using PIO. So I'm _often_ re-adding devices to the RAID. And if those had random partition numbers I'd have screwed it up by now.
Comment 13 Wenzhuo Zhang 2008-08-27 20:39:57 EDT
1. The disk throughput at outer cylinders is faster than that at inner cylinders. So it's a good idea to put swap at the outer cylinders.

2. To reduce unnecessary seek time, it's advisable to put the biggest partition at the end.
Comment 14 Wenzhuo Zhang 2008-08-27 20:51:17 EDT
Another anaconda problem that I encountered the other day (It is unrelated to this bug, but I don't feel like filing a new bug because I don't have access to this machine now):

The default partition scheme of anaconda doesn't work for a server machine with 600+GB RAID storage. LVM fails when creating the last swap partition, because there is not enough disk space.

To workaround the installation failure, I had to modify the default partition scheme so that a little disk space is left unused.

There is definitely rounding bug with disk space calculation in anaconda.
Comment 15 George R. Goffe 2008-08-27 22:28:44 EDT
Howdy,

Let me say this. I STRENUOUSLY object to this closure. This "feature" is indeed a bug.

I ask you, where is the logic of sorting the entries? 

It is implied by the partitioning process that what you ask for IS what you get. Yes? NOT some programmers idea of what the user "should" want or "should" do. You have NO idea what any user wants to do or why and unless you ask them you'll never know. You can make recommendations which is helpful if only to present a differing viewpoint, but "we" are NOT required to follow those recommendations. To force your own concept of what should or shouldn't be done isn't reasonable.

I have found that if you tell your customer no too many times, they'll go somewhere else. I'm sure that RedHat doesn't want this to happen.

George...
Comment 16 Bjorge Solli 2008-08-28 03:03:09 EDT
(In reply to comment #11)
> For the kickstart case, you can easily add your partitions exactly the way you
> want them with a %pre scripts and then use --onpart for your various
> partitions.  We've provided all the capability to do this sort of complicated
> partition manipulation, you just have to put the pieces together.

I have around 500 running clients and 200 laptops coming soon. Having different partition sheme on these is asking for trouble. I actually do what you suggest today, but the code is UGLY:

## START CODE snippet

 standard )
  echo " - standard partitioning - overwrite everything"
  #remove existing partitions
  #lets choose the first disc:
  pdisk=`cat /proc/partitions | tail -n +2 | sed -e 's/^.* //' | grep '[^0-9]$' | head -1`
  #wipe partition table
  dd if=/dev/zero of=/dev/$pdisk bs=1k count=1000
  #create partitions
  ( echo "n" ; echo "p" ; echo "1" ; echo "1" ; echo "32" ; 
      echo "n" ; echo "p" ; echo "2" ; echo ; echo "+40000M" ; 
      echo "n" ; echo "p" ; echo "3" ; echo ; echo "+2048M" ; 
      echo "n" ; echo "p" ; echo ; echo ;
      echo "t" ; echo "1" ; echo "6" ;
      echo "t" ; echo "3" ; echo "82" ; echo "w" ) | fdisk /dev/${pdisk}
  parted -s /dev/${disk} mkfs 1 fat16 
  parted -s /dev/${disk} mkfs 2 ext2
  cat > /tmp/partition.inc << __EOF__
#Disk partitioning information
part /reboot --noformat --onpart=${pdisk}1
part / --fstype=ext3 --onpart=${pdisk}2 
part swap --onpart=${pdisk}3
part /scratch --fstype=ext3 --onpart=${pdisk}4

## END CODE

Then I include /tmp/partition.inc later on. Not pretty at all, and far from easy to maintain.

My point is that I would not have to do this if the sorting was removed. I have talked with people at RedHat who think this is an undesired "feature", why you insist on keeping it I cannot comprehend. The RedHat employee actually incuraged me to file this bug. I might as well file it under RHEL because it exists there too.
Comment 17 Bjorge Solli 2008-08-28 03:06:04 EDT
Can I make a suggestion for change? Move the sorting to the UI, that way it will not affect kickstart installations, and at the same time sort the partition table nicely for the average user.
Comment 18 Chris Snook 2008-08-28 09:27:08 EDT
(In reply to comment #13)
> 1. The disk throughput at outer cylinders is faster than that at inner
> cylinders. So it's a good idea to put swap at the outer cylinders.

Some disks map the cylinders starting from the inside, and some map them starting from the outside.  Reliably determining this is... non-trivial at best.

I'd rather just let the user decide.  If they happen to pick something sub-optimal the difference still won't be very bad on modern hardware.
Comment 19 Andy Lindeberg 2008-08-28 16:23:39 EDT
(In reply to comment #14)
> Another anaconda problem that I encountered the other day (It is unrelated to
> this bug, but I don't feel like filing a new bug because I don't have access to
> this machine now):

Please file a separate bug for this. It will more than likely not get dealt with if it is not in its own report.

(In reply to comment #15)
> Howdy,
> 
> Let me say this. I STRENUOUSLY object to this closure. This "feature" is indeed
> a bug.

We're planning on totally rewriting the partitioning code in the near enough future that there isn't much reason to take care of this now - it's a lot of work to put into something that's going to be thrown out.
Comment 20 Wenzhuo Zhang 2008-08-28 19:28:11 EDT
(In reply to comment #19)
> Please file a separate bug for this. It will more than likely not get dealt
> with if it is not in its own report.

Bug #460602.
Comment 21 Federico Sacerdoti 2010-01-06 15:36:46 EST
Just saw this behavior in a RHEL 5.4 install (anaconda-11.1.2.168-1). I am frankly a little shocked, we are publishing a paper in USENIX FAST this year about how disk performance on outer platters can be 2x faster and how to structure high-volume data analysis code to take advantage of this fact. How you find out which partition actually lands on the outside of the platter is your problem, but when you do, you want anaconda to respect your ordering!

Regarding comment#19, "Re-writing the code in the near future" is not comforting. We've been around enough to know how accurate "near future" is, and not to rely on it. For serious users, and I thought RHEL catered to this demographic, partition order matters in certain cases, and this is still not fixed. 

I am going to patch anaconda to remove the sort. George, re comment#7, do you have the filename and line number? Might save me some time.
Comment 22 George R. Goffe 2010-01-06 16:41:25 EST
Federico

I am currently using a CentOS 5.4 system. I can look for this and let you know what I find. Ok with you?

George...
Comment 23 Bjorge Solli 2010-01-07 03:49:37 EST
(In reply to comment #19)
> We're planning on totally rewriting the partitioning code in the near enough
> future that there isn't much reason to take care of this now - it's a lot of
> work to put into something that's going to be thrown out.  

Is the code replaced in fedora 10, 11 or 12?

Regards
Bjørge
Comment 24 Federico Sacerdoti 2010-01-14 10:57:25 EST
In my version of anaconda (see comment#21) the following edits fix this problem so that the intended order of partitions is preserved.

COMMENT OUT THE FOLLOWING SORTS
1. partitions.py:466 in Class Partitions, method addRequest(). 
2. autopart.py:926 in processPartitioning() calls requests.sortRequests() before it starts making partitions. 

Another sort in partitioning.py:75 does not need to be commented out.
Comment 25 George R. Goffe 2010-01-14 14:19:28 EST
Federico,

You are the MAN!

Is the software you changed available for testing by any chance?

GOOD WORK!

Regards,

George...
Comment 26 Federico Sacerdoti 2010-01-14 15:18:17 EST
Thanks. Re available, not easily, however using RedHat's nice product.img structure patching anaconda is simple. Make a directory like squashfs_product/, somewhere, put copies of the files from comment#24 in it (at the top level), make the edits, then create a sqashfs disk image using the command below, put it on your kickstart server so an installing host gets it, and done.

mksquashfs squashfs_product/* product.img -keep-as-directory

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