Bug 225551 - bootrecord always written to MBR, when dmraid is installed
bootrecord always written to MBR, when dmraid is installed
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
8
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Joel Andres Granados
:
Depends On:
Blocks: 236452
  Show dependency treegraph
 
Reported: 2007-01-31 05:09 EST by Winfrid Tschiedel
Modified: 2009-08-25 08:04 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-07 11:41:22 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)
requested anaconda-ks.cfg from fedora 8 (1.86 KB, text/plain)
2008-02-14 10:11 EST, Winfrid Tschiedel
no flags Details
requested anaconda-ks.cfg from rhel 5.1 (2.73 KB, text/plain)
2008-02-15 09:33 EST, Winfrid Tschiedel
no flags Details
anaconda-ks fromfedora 8 ( fresh install ) (2.08 KB, text/plain)
2008-02-15 11:09 EST, Winfrid Tschiedel
no flags Details
anaconda-ks fromfedora 8 ( fresh install ) (2.08 KB, text/plain)
2008-02-15 11:10 EST, Winfrid Tschiedel
no flags Details

  None (edit)
Description Winfrid Tschiedel 2007-01-31 05:09:36 EST
Description of problem:

Even if during installation write bootrecord to boot-section is selected,
an existing MBR is overwritten.

Version-Release number of selected component (if applicable):
fedora core6 installation dvd


How reproducible:
Always, same error was also seen on rhel 5.


Steps to Reproduce:
1. Install fedora core 6 on a system with SATA Raid.
2. Install a second fedora core 6 on the same system and select
   write bootrecord to bootsection.
3. reboot
  
Actual results:
 
   The second fedora installation will be bootet.


Expected results:

   Boot of the first fedora Installation.
    To get access to 2. installation, you should
    only insert 3 lines in /boot/grub/menu.lst of the 1. installation

title Fedora (2. Installation)
    root (hd0,x)
    chainloader +1 


Additional info:
    similar problems occur on openSUSE 10.2
Comment 1 Petr Rockai 2007-03-14 04:38:55 EDT
Looks more like anaconda issue to me than dmraid.
Comment 2 Winfrid Tschiedel 2008-02-14 09:42:51 EST
This bug still exists on Fedora 8 -
Fedora 9 Alpha I could not test, because I could install the first release of 
Fedora 9, I get a backtrace in the installer but I am not able to save this 
information. 

This error exists also on rhel 5.1 !
Comment 3 Joel Andres Granados 2008-02-14 09:50:38 EST
There is a ks file produces by anaconda that you can retrieve from your system.
 It is located in /root/anaconda-ks.cfg.  the files for both systems would help.
thx.
Comment 4 Joel Andres Granados 2008-02-14 10:08:01 EST
I really dont think that this is relsated to raid.  Here are my tests and the
results:

Setup:  Have two scsi drives, x86_64 arch

1. installed f8 in one drive, chose the erase everything and installed anacondas
default setup in one of the drives.  Created a boot partition that is used for
booting.
2. installed another f8 system in the other drive, but this time I took care of
setting up the second system to boot from the /boot partition on the other disk.

Both installations succeeded.   The grub.conf cont overwriten by the grub
backage (I assume).  The information of the previous probrama is in the
grub.conf.rpmsave file.  
Are you seeing the same?

Comment 5 Winfrid Tschiedel 2008-02-14 10:11:41 EST
Created attachment 294914 [details]
requested anaconda-ks.cfg from fedora 8

if file for rhel 5.1 is also needed I have make a new installation,
because the system where I observed the problem is not anymore available.

Winfrid
Comment 6 Joel Andres Granados 2008-02-14 10:28:05 EST
(In reply to comment #5)
> Created an attachment (id=294914) [edit]
> requested anaconda-ks.cfg from fedora 8
> 
> if file for rhel 5.1 is also needed I have make a new installation,
^^^^^^^^
this would be very helpfull. :)
Q1: do you have two disks or are you installing in two different partitions?
Q2: Are you doing a kickstart install or normal graphical one?
Q3: In your original test did you use the /boot partition to boot?


Comment 7 Winfrid Tschiedel 2008-02-14 10:35:01 EST
(In reply to comment #4)
> I really dont think that this is relsated to raid.  Here are my tests and the
> results:
> Setup:  Have two scsi drives, x86_64 arch
> 1. installed f8 in one drive, chose the erase everything and installed 
anacondas
> default setup in one of the drives.  Created a boot partition that is used 
for
> booting.
> 2. installed another f8 system in the other drive, but this time I took care 
of
> setting up the second system to boot from the /boot partition on the other 
disk.
> Both installations succeeded.   The grub.conf cont overwriten by the grub
> backage (I assume).  The information of the previous probrama is in the
> grub.conf.rpmsave file.  
> Are you seeing the same?

My operation is a little bit different - 
if I have a new system, then I start this way.

Install first OS to /boot + /

After the first installation has finished, I copy the boot-partition to 
the root-partition and do all changes in the new boot-partition in order 
to be able to boot this system from the root partition.
This means I have to create a boot record for this root partition, after this
I adjust /etc/fstab and the new "/boot/grub/menu.lst". 

After this I change grub/menu.lst on the old boot partition and do chain 
loading of all installed linux distributions.

After this install all other distributions in seperate partition and write 
the boot-record to the partition. As long as I was using non raid devices only
in some rare cases the mbr was overwritten ( no bootrecord in the partition )-
this happens mostly for beta releases. 
In case of raid devices ( dmraid ) always a mbr is created
( in case of rhel/fedora without warning ), in case of openSUSE, you get a 
warning, which tells you, that the br is written to default location.



Comment 8 Winfrid Tschiedel 2008-02-14 10:47:48 EST
(In reply to comment #6)
> (In reply to comment #5)
> > Created an attachment (id=294914) [edit] [edit]
> > requested anaconda-ks.cfg from fedora 8
> > 
> > if file for rhel 5.1 is also needed I have make a new installation,
> ^^^^^^^^
> this would be very helpfull. :)
> Q1: do you have two disks or are you installing in two different partitions?
> Q2: Are you doing a kickstart install or normal graphical one?
> Q3: In your original test did you use the /boot partition to boot?

I think I answered some of your questions in the meantime, but here is 
the direct answer to your questions:

Q1 : different partitions - but see my remark
Q2 : graphical installation
Q3 : only for the first system I have a seperate boot partition, 
     but this is just used for the installation, all other systems are 
     installed into one partition.

Remark : Currently I have a second problem with dmraid and fedora 8 -
     My system has a Promise  PDC20319 Controller (FastTrak S150 TX4) (rev 02).
     In this system I have to define every disk as a RAID device, otherwise 
     I am not able to boot from this device. So I have in my system 
     2 RAID0 ( with just 1 disk ). In case of fedora and 2 disks 
     anaconda (?) loops, so I never get to the disk partitioning.

Comment 9 Joel Andres Granados 2008-02-14 11:20:31 EST
(In reply to comment #7)
> My operation is a little bit different - 
....
> I adjust /etc/fstab and the new "/boot/grub/menu.lst". 

I see, did this work in previous versions of fedora/rhel?
Comment 10 Joel Andres Granados 2008-02-14 12:46:34 EST
Ok, I tried to mirror what you are trying to do and came up with a solution. 
I'm assuming that you are using the extended bootloader screan and telling
anaconda to put the bootloader in the current disk (refering to the second
install, the one you don't want to have a bootloader). If you do this your
actually telling anaconda to put the bootloader there.
What you should do to get the behavior you want is to select the "not install
bootloader" on the second install.  In this way you install a system that is not
bootable.
To make the system bootable you take the initrd.img and vmlinuz from /boot and
put it in the /boot directory from the first system you installed.  You also
must change the grub.conf to reflect the changes.  If you get everything right
the second system will be included in the grub list and will be bootable :)
Comment 11 Winfrid Tschiedel 2008-02-15 09:33:27 EST
Created attachment 295008 [details]
requested anaconda-ks.cfg from rhel 5.1

+ output from raid -r :

/dev/sda: pdc, "pdc_cjgdhdfafh", stripe, ok, 156118928 sectors, data@ 0
Comment 12 Winfrid Tschiedel 2008-02-15 11:09:58 EST
Created attachment 295019 [details]
anaconda-ks fromfedora 8 ( fresh install )

Today I installed my fedora 8 into another partition ( on disk 1 ) -
previous installation was on disk 2 ( install on 2 disk, disk 1 offline ).

requested output from dmraid -r :

/dev/sda: pdc, "pdc_bjfeeibeeb", stripe, ok, 312368928 sectors, data@ 0
/dev/sdb: pdc, "pdc_cjgdhdfafh", stripe, ok, 156118928 sectors, data@ 0
Comment 13 Winfrid Tschiedel 2008-02-15 11:10:00 EST
Created attachment 295020 [details]
anaconda-ks fromfedora 8 ( fresh install )

Today I installed my fedora 8 into another partition ( on disk 1 ) -
previous installation was on disk 2 ( install on 2 disk, disk 1 offline ).

requested output from dmraid -r :

/dev/sda: pdc, "pdc_bjfeeibeeb", stripe, ok, 312368928 sectors, data@ 0
/dev/sdb: pdc, "pdc_cjgdhdfafh", stripe, ok, 156118928 sectors, data@ 0
Comment 14 Winfrid Tschiedel 2008-02-18 04:22:01 EST
Please have also a look at issue 164550 on 
enterprise.redhat.com/issue-tracker

Comment 15 Anders 2008-02-18 05:33:38 EST
IT#164550 and the original problem described in this Bug is not the same. Please
treat as two separate issues.

/Anders
Comment 16 Joel Andres Granados 2008-04-07 11:41:22 EDT
This was solved in booty.  bug number (#236452)

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