01.03.2017 01:05, Lennart Sorensen пишет: > On Tue, Feb 28, 2017 at 09:50:27PM +0300, Andrei Borzenkov wrote: >> 28.02.2017 21:31, Lennart Sorensen пишет: >>> On Tue, Feb 28, 2017 at 08:13:53PM +0300, Andrei Borzenkov wrote: >>>> Sorry? vda7 is 256M, how can you suddenly pretend it is 2G? >>>> >>>> 10:~ # fdisk -l /dev/vda >>>> Disk /dev/vda: 5 GiB, 5368709120 bytes, 10485760 sectors >>>> Units: sectors of 1 * 512 = 512 bytes >>>> Sector size (logical/physical): 512 bytes / 512 bytes >>>> I/O size (minimum/optimal): 512 bytes / 512 bytes >>>> Disklabel type: dos >>>> Disk identifier: 0x882b18da >>>> >>>> Device Boot Start End Sectors Size Id Type >>>> /dev/vda1 2048 2099199 2097152 1G 83 Linux >>>> /dev/vda2 2099200 6293503 4194304 2G a6 OpenBSD >>>> /dev/vda3 6293504 10485759 4192256 2G 5 Extended >>>> /dev/vda5 6295552 6819839 524288 256M 83 Linux >>>> /dev/vda6 6821888 7346175 524288 256M 83 Linux >>>> 10:~ # fdisk -l /dev/vda2 >>>> Disk /dev/vda2: 2 GiB, 2147483648 bytes, 4194304 sectors >>>> Geometry: 16 heads, 63 sectors/track, 10402 cylinders >>>> Units: sectors of 1 * 512 = 512 bytes >>>> Sector size (logical/physical): 512 bytes / 512 bytes >>>> I/O size (minimum/optimal): 512 bytes / 512 bytes >>>> Disklabel type: bsd >>>> >>>> Slice Start End Sectors Size Type Fsize Bsize Cpg >>>> a 2099200 2623488 524289 256M boot 0 0 0 >>>> b 2099200 2623488 524289 256M unused 0 0 0 >>>> c 2099200 6293503 4194304 2G unused 0 0 0 >>>> d 0 10485215 10485216 5G unused 0 0 0 >>>> >>>> Partition table entries are not in disk order. >>> >>> Well that does look mostly sane for an ancient BSD version. >>> >> >> In case I was not clear. >> >> BSD partition a is represented in Linux as /dev/vda7. grub-probe -t >> compatibility_hints -d /dev/vda7 returns hd0,msdos2 which is obviously >> wrong, because it refers to 2GB area on disk while partition /dev/vda7 >> is just 256M. I would expect either hd0,msdos2,openbsd1 or nothing >> depending on whether such nested partition is supported. > > Oh now I see what you mean. Hmm, that is an interesting problem. > > It seems FFS and UFS reserve either 1 or 8KB at the start for bootblock, > which I suppose would save the disklabel from being overwritten if using > one of those filesystems.
Solaris usually does not have issues with slice containing label as the first block. Native tools (UFS, ZFS, SVM) and non-native (Veritas) all preserve it. So I never considered it something unusual. _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
