From: lsorense@csclub.uwaterloo.ca (Lennart Sorensen)
To: The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: grub-probe for nested BSD partition on Linux
Date: Tue, 28 Feb 2017 17:05:34 -0500 [thread overview]
Message-ID: <20170228220534.GB31496@csclub.uwaterloo.ca> (raw)
In-Reply-To: <15e78e1d-9d62-5598-dcf9-dca40f85c633@gmail.com>
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
next prev parent reply other threads:[~2017-02-28 22:05 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-14 18:00 [PATCH 1/1] add --partuuid to probe Steve Kenton
2017-02-14 19:12 ` Andrei Borzenkov
2017-02-14 19:39 ` Steve Kenton
2017-02-15 3:36 ` Nick Vinson
2017-02-15 10:56 ` Vladimir 'phcoder' Serbinenko
2017-02-15 16:26 ` Andrei Borzenkov
2017-02-15 17:25 ` Vladimir 'phcoder' Serbinenko
2017-02-19 6:12 ` Andrei Borzenkov
2017-02-27 0:37 ` Vladimir 'phcoder' Serbinenko
2017-02-27 17:53 ` Andrei Borzenkov
2017-02-27 18:20 ` Vladimir 'phcoder' Serbinenko
2017-02-28 4:11 ` Andrei Borzenkov
2017-02-28 14:08 ` Vladimir 'phcoder' Serbinenko
2017-02-28 17:13 ` grub-probe for nested BSD partition on Linux (was: [PATCH 1/1] add --partuuid to probe) Andrei Borzenkov
2017-02-28 18:31 ` Lennart Sorensen
2017-02-28 18:50 ` grub-probe for nested BSD partition on Linux Andrei Borzenkov
2017-02-28 22:05 ` Lennart Sorensen [this message]
2017-03-01 3:39 ` Andrei Borzenkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170228220534.GB31496@csclub.uwaterloo.ca \
--to=lsorense@csclub.uwaterloo.ca \
--cc=grub-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).