Bug 111243 - DiskDruid messes mount points - partitions mappings when going back in installer
DiskDruid messes mount points - partitions mappings when going back in installer
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: installer (Show other bugs)
9
All Linux
medium Severity high
: ---
: ---
Assigned To: Michael Fulbright
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-12-01 05:04 EST by Aleksander Adamowski
Modified: 2007-04-18 12:59 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-04-16 17:48:45 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 Aleksander Adamowski 2003-12-01 05:04:40 EST
Description of problem:

If the user goes past DiskDruid partitioning phase up to Grub menu
editing phase, then goes back to DiskDruid to change partition scheme,
under certain circumstances the partition->mount point mappings will
get messed up.

Version-Release number of selected component (if applicable):

Redhat Linux 9 text installer

How reproducible:

Reproducible 100%, and in my case, I've lost over 1 hour during my
RHCE exam because of this (I had to manually setup RAID and move data
between filesystems after installation because they were messed up).

Steps to Reproduce:
1. Boot from RH 9 installation CD1
2. Use "linux text" installation
3. Choose "Personal Desktop" installtion type (it doesn't actually matter)
4. Partition using Disk Druid

Craete the following partitions in the following order:

256 MB mounted on /boot
1024 MB mounted on /
4096 mounted on /usr
512 swap
all remaining size mounted on /home

Disk druid will create the following mappings:

256 MB hda1 -> /boot
4096 MB hda2 -> /usr
1024 MB hda3 -> /
all remaining hda4 -> Extended partition

and then on the extended partition:

512 MB hda5 -> swap
all remaining hda6 -> /home

5. Go further, choose GRUB boot loader
6. Move further through boot loader configuration up to the list of
bootloader entries.
7. Now imagine this: you can see that the root device is /dev/hda3:

Default   Boot label      Device
*         Red Hat Linux   /dev/hda3

Suppose that you want to place it on a lower partition. You do the
following:

8. Go back to disk druid
9. Edit hda3 (mapped to /boot)
10. Turn on the option "Force to be a primary partition" and confirm
11. Observe how the mapping has chanbged to this:

256 MB hda1 -> /boot
1024 MB hda2 -> /
4096 MB hda3 -> /usr
all remaining hda4 -> Extended partition

and then on the extended partition:

512 MB hda5 -> swap
all remaining hda6 -> /home

Particularly, note that "/usr" has still 4096MB in size and "/" has
still 1024MB.

12. Go further through bootloader configuration, without changing
anything. Notice that GRUB's root device is still incorrectly at an
old setting of "/dev/hda3"! Don't change that, though, and go further.

13. Place GRUB in MBR (/dev/hda)
14. Use whatever Network, Firewall, Language, Timezone, setting you like.
15. Provide root user's password
16. Accept the default packages selection, it doesn't matter.
17. Begin installation
18. Wait for the formatting filesystems phase to end
19. Use Alt-F2 to switch to the terminal console
20. Issue "df -h" to check filesystem mappings and sizes.

Actual results:

"/usr" and "/" filesystems are switched and don't correspond to what
Disk Druid was showing:

"/" is still on hda3
"/usr" is still on hda2

but:

"/" on hda3 has the size meant for "/usr", 4096MB!
"/usr" on hda2 has the size meant for "/", 1024MB!

In this case the installation will fail due to lack of space for
packages. In my case, on RHCE exam, the situation was worse because
usr was switched with another filesystem which was big enough, so the
install proceeded, but afterwards the sizes were wrong

Expected results:

1. The filesystems are created according to the table shown by Disk
Druid insteller page
2. Grub configurator detects relocation of the root filesystem and
reflects those changes on the last "Grub configuration" installer page.

Additional info:

none
Comment 1 Jeremy Katz 2003-12-01 15:58:19 EST
Does this still happen with Fedora Core 1?  I seem to remember fixing
it there...
Comment 2 Aleksander Adamowski 2003-12-02 09:10:34 EST
Nope, I've just tested with Fedora Core 1 installer.

Fedora installer does exactly the same thing:

Initially places filesystems in order "/boot", "/usr", "/";
 
When I go to GRUB boot menu editor (where I see root device on hda3),
then go back to disk druid and force "/" to be a primary partition,
the order changes to "/boot", "/", "/usr".

But on the GRUB menu editor root is still visible as hda3, not hda2.

When I go further and start package installation, I can see that the
filesystems were mounted in old order (hda1 -> "/boot", hda2 ->
"/usr", hda3 -> "/"), and the sizes use the new order (hda1 -> 256,
hda2 -> 1024, hda3 ->  4096).

So in short the problem is: Disk Druid has reordered size
specifications, but not mount points after I had clicked "Force
primary partition".

Which leaves me with filesystems having different sizes and order than
I've specified in Disk Druid.

Comment 3 Aleksander Adamowski 2003-12-02 09:11:21 EST
BTW, I've passed the exam anyway :)

But the score was only 88%...
Comment 4 Jeremy Katz 2003-12-16 19:15:20 EST
Fixed in CVS

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