Description of problem: grub2-setup crashes with signal SIGSEGV (Segmentation fault) when boot device is md device with 1.2 superblock. # mdadm --query --detail /dev/md10 /dev/md10: Version : 1.2 Raid Level : raid1 Name : abrakodabra:10 ... # /sbin/grub2-setup /dev/md10 Segmentation fault (core dumped) The problem happens because array->number field is assigned out-of-range value (more info at the end) Version-Release number of selected component (if applicable): grub2-1.99-13.fc16.x86_64 How reproducible: Steps to Reproduce: 1. make RAID1 md device with 1.2 superblock using 2 identical physical devices or partitions. mdadm --create /dev/md10 --metadata=1.2 --raid-devices=2 --level=mirror --bitmap=internal --name=10 /dev/sdc /dev/sdd 2. try to setup GRUB2 /sbin/grub2-setup /dev/md10 Actual results: Program received signal SIGSEGV, Segmentation fault. grub_util_biosdisk_is_floppy (disk=0x871450) at grub-core/kern/emu/hostdisk.c:1833 (gdb) p *disk $1 = {name = 0x871d10 "mduuid/28e5...5453", dev = 0x64b620, total_sectors = 2097128, >>>> id = 1073741825 <<<<<, partition = 0x0, read_hook = 0, data = 0x856380} Expected results: Something reasonable - either completed setup or some error message. Additional info: The problem happens because array->number field is assigned out-of-range value in grub-core/disk/raid.c:620. The following happens -------- grub-core/disk/raid.c ----- insert_array (grub_disk_t disk, struct grub_raid_array *new_array,...) ... if (array->name || p) // line 614 ... int i = array->name ? 0x40000000 : 0; // line 620 ... i++; // line 637 ... array->number = i; // line 633 grub_raid_open (const char *name, grub_disk_t disk) ... disk->id = array->number; // line 173 As the array has name array->number field gets very large value, for example, 1073741825 (0x40000001). This value later is copied to disk->id field. --------- grub-core/kern/emu/hostdisk.c ----- struct // line 131 { char *drive; char *device; } map[256]; ... grub_util_biosdisk_is_floppy (grub_disk_t disk) ... fd = open (map[disk->id].device, O_RDONLY); // line 1833 map array size is only 256 but it is accessed with index (disk->id) 1073741825. So signal SIGSEGV happens.
I get the same problem with a RAID1 with 1.0 metadata: [uckelman@hydra ~]$ sudo mdadm --query --detail /dev/md0 /dev/md0: Version : 1.0 Creation Time : Mon Jun 14 18:04:08 2010 Raid Level : raid1 Array Size : 511988 (500.07 MiB 524.28 MB) Used Dev Size : 511988 (500.07 MiB 524.28 MB) Raid Devices : 2 Total Devices : 2 Persistence : Superblock is persistent Update Time : Sun Feb 19 22:14:54 2012 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Name : localhost.localdomain:0 UUID : fc87b512:11761218:10f1025d:52a1ba96 Events : 3400 Number Major Minor RaidDevice State 0 8 18 0 active sync /dev/sdb2 1 8 2 1 active sync /dev/sda2 [uckelman@hydra ~]$ sudo /sbin/grub2-install /dev/md0 /sbin/grub2-install: line 661: 4749 Segmentation fault "$grub_setup" ${allow_floppy} ${setup_verbose} ${setup_force} --directory="${grubdir}" --device-map="${device_map}" "${install_device}"
Same here. Anyone got a fix or workaround? root@basti# /sbin/grub2-install /dev/md0 /sbin/grub2-install: line 661: 12158 Segmentation fault "$grub_setup" ${allow_floppy} ${setup_verbose} ${setup_force} --directory="${grubdir}" --device-map="${device_map}" "${install_device}" root@basti# mdadm --query --detail /dev/md0 /dev/md0: Version : 1.0 Creation Time : Mon Jun 6 17:25:06 2011 Raid Level : raid1 Array Size : 2097140 (2048.33 MiB 2147.47 MB) Used Dev Size : 2097140 (2048.33 MiB 2147.47 MB) Raid Devices : 3 Total Devices : 3 Persistence : Superblock is persistent Intent Bitmap : Internal Update Time : Sat Mar 10 11:19:44 2012 State : active Active Devices : 3 Working Devices : 3 Failed Devices : 0 Spare Devices : 0 Name : basti.digitalkingdom.org:0 (local to host basti.digitalkingdom.org) UUID : e07f5bf0:6c37368e:d110ddd4:2ba724c6 Events : 128 Number Major Minor RaidDevice State 0 8 1 0 active sync /dev/sda1 1 8 17 1 active sync /dev/sdb1 2 8 33 2 active sync /dev/sdc1
Seeing this also on grub2-1.99-13.fc16.x86_64 with mirrored disks and Version 1.2 superblocks. This will make rollout to my servers which all have md mirrored disks impossible unless there is a workaround.
Can you reproduce this on f17 with a more recent grub? It seems like I can't. grub2-setup is no longer - I assume grub2-install should be used instead.
(In reply to comment #4) > grub2-setup is no longer it has been renamed to grub2-bios-setup. Please try with grub2-2.0-0.24.beta4.fc17 which has been pushed to f17 stable.
I just tried installing F17-beta and it can't install the bootloader because grub2-probe is segfaulting. It has that version of grub2. See bug 581451 for a screenshot.
This may be caused by bug 750794.
Can you confirm if this issue is the same as bug 809111? Can it be solved by removing device.map or using the grub2 from https://bugzilla.redhat.com/show_bug.cgi?id=809111#c22 ?
This is almost surey the bug which was fixed by following upstream commit: revno: 3425 committer: Vladimir 'phcoder' Serbinenko <phcoder> branch nick: grub timestamp: Wed 2011-09-28 14:07:53 +0200 message: * grub-core/kern/emu/hostdisk.c (grub_util_biosdisk_is_floppy): Return 0 if disk isn't biosdisk.
Comment 6 claims to have seen the segfault with beta4 which do include that commit. Bug 826812 reported a crash that might have been similar ... but didn't leave enough information.
It wasn't beta4. If you look at beta4 it contains is_floppy in getroot.c and not hostdisk.c. So most likely is that the user somehow had an older version (he could have manually installed it)
(In reply to comment #11) (Yes, the original report was using 1.99 without your fix 3425. Samuel claimed in comment 6 that the saw the same with beta4 - but didn't provide any evidence.) Alexander, can you confirm that your issue has been solved with grub2 beta4 (or later)? If anybody else can reproduce something similar with f17 final then please file a new issue.
My comment was actually about grub2-probe segfaulting which was a related issue and that has since been fixed.
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.