Bug 561976 - MasterBootRecord clobbered despite unchecked "Install bootloader to /dev/sd..."
MasterBootRecord clobbered despite unchecked "Install bootloader to /dev/sd..."
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: parted (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Hans de Goede
Fedora Extras Quality Assurance
:
: 566453 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-02-04 16:34 EST by John Reiser
Modified: 2010-02-19 19:17 EST (History)
4 users (show)

See Also:
Fixed In Version: parted-2.1-5.fc13
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-02-18 09:42:38 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 John Reiser 2010-02-04 16:34:09 EST
Description of problem: During install from DVD, the MasterBootRecord of the first BIOS disk was replaced by a "blank" MBR despite un-checking the box "Install bootloader to /dev/sd..." in the GRUB dialog screen.


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

How reproducible: every time


Steps to Reproduce:
1. compose install .iso from rawhide of 2009-02-04 (Thurs.) and burn to DVD
2. boot DVD for install; Basic disks, Custom layout, choose exiting partition for root and Format to ext4, do not choose a partition for /boot.
3. Uncheck the box "Install boot loader to /dev/sd..." on the boot loader dialog screen.
  
Actual results: MasterBootRecord on first BIOS drive is overwritten with "blank" MBR which does not contain full booting code.
# od -Ax -tx4 sdb.mbr
000000 1000b8fa 00bcd08e 0000b8b0 c08ed88e
000010 7c00befb b90600bf a4f30200 000621ea
000020 07bebe00 0b750438 8110c683 7507fefe
000030 b416ebf3 bb01b002 80b27c00 8b01748a
000040 13cd024c 007c00ea 00feeb00 00000000
000050 00000000 00000000 00000000 00000000
* 
0001b0 00000000 00000000 00073931 01800000
0001c0 fe830001 003f323f 80340000 0000000c
0001d0 fe073301 8073ffff 5e1a000c 00000780
0001e0 00000000 00000000 00000000 fe000000
0001f0 fe05ffff de8dffff 6aea078c aa550b9f
000200


Expected results: No change to MBR.


Additional info:
Comment 1 John Reiser 2010-02-04 16:59:25 EST
The damage is done immediately after clicking Next on the "Install boot loader to /dev/sd..." dialog, even though the checkbox has been un-checked.
Comment 2 Hans de Goede 2010-02-05 02:54:10 EST
(In reply to comment #1)
> The damage is done immediately after clicking Next on the "Install boot loader
> to /dev/sd..." dialog, even though the checkbox has been un-checked.    

Are you sure ? That is rather weird, we don't do any bootloader setup until after the packages have been installed / upgraded.
Comment 3 John Reiser 2010-02-05 12:13:54 EST
Here's the proof.  In this example /dev/sdb is the first fixed drive; /dev/sda is an empty ATA Zip-100.
-----
320   open("/dev/sdb", O_RDWR)          = 22
320   lseek(22, 512, SEEK_SET)          = 512
320   read(22, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
320   lseek(22, 0, SEEK_SET)            = 0
320   write(22, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 9728) = 9728
320   lseek(22, 164696545792, SEEK_SET) = 164696545792
320   write(22, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 9728) = 9728
320   ioctl(22, BLKFLSBUF, 0x1)         = 0
320   lseek(22, 0, SEEK_SET)            = 0
320   read(22, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
320   gettimeofday({1265359604, 954521}, NULL) = 0
320   lseek(22, 64856332800, SEEK_SET)  = 64856332800
320   read(22, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
320   lseek(22, 65942069760, SEEK_SET)  = 65942069760
320   read(22, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
320   lseek(22, 87426501120, SEEK_SET)  = 87426501120
320   read(22, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
320   lseek(22, 108910775808, SEEK_SET) = 108910775808
320   read(22, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
320   lseek(22, 108910775808, SEEK_SET) = 108910775808
320   write(22, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
320   lseek(22, 87426501120, SEEK_SET)  = 87426501120
320   write(22, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
320   lseek(22, 65942069760, SEEK_SET)  = 65942069760
320   write(22, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
320   lseek(22, 64856332800, SEEK_SET)  = 64856332800
320   write(22, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
320   lseek(22, 0, SEEK_SET)            = 0
320   write(22, "\372\270\0\20\216\320\274\0\260\270\0\0\216\330\216\300\373\276\0|\277\0\6\271\0\2\363\244\352!\6\0"..., 512) = 512
320   fsync(22)                         = 0
320   ioctl(22, BLKFLSBUF, 0x1)         = 0
320   fsync(22)                         = 0
320   close(22)                         = 0
-----

Detailed methodology:  Prepare and insert a removable drive with filesystem and available space, such as USB2.0 flash memory.  Boot the installer DVD.  Proceed to the graphical splash screen, then switch to VT2.  Do "ps ax" and identify the process number of the installer.  There will be two 'ananconda' processes.  Pick the process with a couple CPU seconds ("320" in my case); the other will be 0:00.  Make a new directory and mount the removable filesystem, then chdir to the removable filesystem.  Invoke
   strace -p PID -f -o strace.out  2>/dev/null &
Then switch back to VT6 and continue with install.  When the boot loader dialog appears, then uncheck the box for "Install bootloader to /dev/sd..." and click Next.  Wait until the graphical dialog for choosing install type (Graphical internet, Office and productivity, Software development, Web server, Minimal) appears.  Switch back to VT2, and examine the 'strace.out' file using an editor such as 'vi'.  In my case the file of strace output had grown to about 14MB.  Search backwards from the end for 'open("/dev/sdb",' [or whatever drive is the boot drive.]  Note that it is open O_RDWR for both reading and writing, and note that the following 35 lines or so overwrite the MBR.  Specifically:
-----
320   lseek(22, 0, SEEK_SET)            = 0
320   write(22, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 9728) = 9728
   [snip]
320   lseek(22, 0, SEEK_SET)            = 0
320   write(22, "\372\270\0\20\216\320\274\0\260\270\0\0\216\330\216\300\373\276\0|\277\0\6\271\0\2\363\244\352!\6\0"..., 512) = 512
-----
Also note that 9728 bytes are written at offset 0, and at the end of the drive (in my case, offset 164696545792 for a 164GB drive)  Also note that four 512-byte blocks in the "middle" of the drive are zeroed before the MBR is written with final content "\372\270\0\20\216\320\274\0..."  All this despite un-checking the box for "Install bootloader ..."
Comment 4 John Reiser 2010-02-05 13:32:08 EST
It looks like the damage is done even earlier.  The strace log shows:

-----line 108775
320   <... clone resumed> child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fa901a419d0) = 907
    [snip uninteresting dup+close+chdir+chroot]
907   execve("/bin/udevadm", ["udevadm", "settle", "--timeout=300"], [/* 22 vars */] <unfinished ...>
-----

-----line 110978
320   write(14, "03:46:44,884 DEBUG storage:     "..., 97) = 97
320   sendto(16, "<143>storage:             DiskLa"..., 83, 0, NULL, 0) = 83
320   open("/dev/sdb", O_RDWR)          = 22    **** the clobberage begins
-----

-----line 111211
320   clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fa901a419d0) = 914
   [snip searching of $PATH for mke2fs]
914   execve("/usr/sbin/mke2fs", ["mke2fs", "-t", "ext4", "/dev/sdb7"], [/* 21 vars */]) = 0
-----

where those are the nearest clone() which precede and follow the overwriting.
/dev/sdb7 is the pre-existing partition that was chosen for root, to be re-formatted as ext4.  So the MBR has been clobbered before the root is formatted.
Comment 5 Hans de Goede 2010-02-15 15:57:51 EST
Hi,

Is the disk in question using a gpt partition table ?
Comment 6 John Reiser 2010-02-15 16:57:16 EST
No, it has a MSDOS partition table.
Comment 7 Hans de Goede 2010-02-16 05:56:39 EST
Hmm,

So it seems that for some reason libparted's ped_disk_clobber function ends up being called. Which should not happen when we are not writing a fresh disklabel to the disk.

You are re-using existing partitions right, so no fresh partition table should get written, correct ?

Can you reproduce this? And if so could you please collect the logs from under /tmp and attach them here ?

Thanks,

Hans
Comment 8 Hans de Goede 2010-02-18 09:42:38 EST
Hi John,

I've figured out what is going on (long story). This is caused by an obscure parted bug. Thanks for the straces and your persistence, the underlying issue might very well explain some other bugs to.

parted-2.1-5 which fixes this, is on its way to rawhide and the F-13 repo, I've managed to reproduce this issue myself and I can confirm this parted build fixes it. So I'm going to close this bug.

Once more thanks!

Regards,

Hans
Comment 9 Hans de Goede 2010-02-18 09:46:46 EST
*** Bug 566453 has been marked as a duplicate of this bug. ***
Comment 10 Fedora Update System 2010-02-18 10:16:29 EST
parted-2.1-5.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/parted-2.1-5.fc13
Comment 11 Guenni 2010-02-18 13:57:07 EST
(In reply to comment #9)
> *** Bug 566453 has been marked as a duplicate of this bug. ***    

Hi Hans,

the only difference to my case seems to be that the partition table had to be written before the installation of the packets starts. The partition destinned for the Fedora installation was not assigend before and it has been a fresh/new 
disk.

Regards
  wbroesel
Comment 12 Fedora Update System 2010-02-19 19:17:30 EST
parted-2.1-5.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

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