On Fri, Apr 07, 2017 at 04:27:40PM +0200, Peter Krempa wrote: > On Fri, Apr 07, 2017 at 09:52:09 -0400, John Ferlan wrote: > > https://bugzilla.redhat.com/show_bug.cgi?id=1439132 > > > > During 'matrix' testing of all possible combinations I found that if > > device is formated with "gpt" first, then an attempt is made to format > > using "mac", a startup will fail. By adding a clearing of the first > > 2048 bytes of the device (similar to the logical pool code), the issue > > is resolved. > > I'm not a fan of this and neither thing this is robust enough: > > The problem here is that apparently the "mac" table fits into the first > block on the disk. Since the GPT disklabel is stored at LBA address 1 > it is not overwritten at all. Thus it's apparent that the detection tool > then prefers GPT over a older disklabel. > > The GPT disklabel has also a secondary copy at the last LBA of the disk. > > As for robustness: SECTOR_SIZE is defined as 512 in our code, thus this > code nukes 2k of data. For devices with 4k sectors which are already > available this won't help at all, since LBA 0 will still contain the > protective MBR, and the 3,5k left of LBA 0 will be unused. GPT disklabel > still will start at LBA 1. Personally I'd forget about sectors and just nuke 1 MB of data at start and end of the device. The time for 2k vs 1 MB is negligible. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
