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:
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.
(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.
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 ..."
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.
Hi, Is the disk in question using a gpt partition table ?
No, it has a MSDOS partition table.
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
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
*** Bug 566453 has been marked as a duplicate of this bug. ***
parted-2.1-5.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/parted-2.1-5.fc13
(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
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.