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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.