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. The documentation does seem to say to always leave a gap before the first slice/partition in all cases. > > Slice a is the rootfs for BSD > > > > Slice b should traditionally be swap, but appears to be unused here, > > and for some reason uses the same part of the disk as slice a, which > > does look odd. Maybe since the type is unknown, it doesn't matter. > > > > Slice c is the whole partition containing the slices (vda2) > > > > Slice d is the whole disk (vda), which apparently hasn't been used in > > BSD for a couple of decades now, if wikipedia can be trusted. > > > > So if linux only bothers to count the partition with a type that isn't > > unused, then it probably makes sense. That appears to be what the > > partition parsing code does. > > > > The start being the same as the start of vda2 does seem odd given it > > appears that you are supposed to leave space at the start (1 track > > recommended, or 64 sectors), and it appears the disklabel is at sector > > 1 (0 being the first), so it doesn't seem like having your filesystem > > start there would be safe unless the filesystem has reserved space at > > the start for such things. > > > > I just pressed 'b' in Linux fdisk and only change two partition sizes. I > have no idea how fdisk choses partition start. Could be a bug in fdisk. I think fdisk's default is probably wrong in this case. Certainly if you create a slice and then decide to mkfs.ext2 on it, your disklabel is gone if you don't make the start offset a bit higher. -- Len Sorensen _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
