All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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.