All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dryden Personalis <list@xenhideout.nl>
To: Grub devel <grub-devel@gnu.org>
Subject: Re: [PATCH] Install to LVM PVs
Date: Mon, 09 May 2016 02:10:49 +0200	[thread overview]
Message-ID: <affaae46e979909eac0ef9614fadf0f4@dds.nl> (raw)
In-Reply-To: <bbd10e2a012e6ad571caabbc90f1098b@dds.nl>

Andrei Borzenkov schreef op 08-05-2016 11:23:

> PV label may be in the first sector. In this case label will be
> overwritten later by boot image. This needs additional check.

Pardon my last mail.

ON OLD PV SIGNATURES
--------------------

If you have an old PV that had a boatloaderarea, then wiping and or 
recreating the PV doesn't actually clear or reset or reformat that thing 
so as to fail.

It is not necessary to have a VG in order to install grub to a PV.

However, if the VG code is not called (both grub_lvm_detect and 
grub_diskfilter_get_pv_from_disk) then the code will not know how big 
the bootloaderarea is going to be (or whether you have one) -- you still 
don't need a VG, you just need to call that function the way this patch 
is.

Having or not having a VG in the PV makes no difference as to the 
results of any operation.

My code currently pretends that having a PV header is enough, and it 
works out just fine. I have not exhaustively tested what happens if you 
create a VG after (successfully booting) but I doubt it is going to give 
issues.

So the most important thing for this checking code currently is that the 
PV is actually created on a clean disk, ie a simple:

dd if=/dev/zero of=/dev/sda bs=1M count=20

Will ensure correct behaviour.

So it is possible to create a PV without a bootloaderarea on top of an 
older PV that did have one, and the code will see the data structures of 
the old one, but the real PV and its VGs will be based on the new one 
(you can see the difference in that you lose an extent if you create or 
remove an area of 4M).

So the code is not entirely correct in that sense (And I do not 
understand it yet at all) but in most cases it functions correctly.


LOCATION OF SANITY CHECKING
---------------------------

Presently what I am doing is to let the code in setup.c only check the 
basics, if a PV header is present, fine, let's get on with it. The 
embedding code (in lvm.c) then checks whether everything is alright.

The annoying part is that if (and only if) you have placed your PV 
header in the first sector (the way we needed to prevent cq. check) it 
can mean that some info message is going to be output multiple times. 
Each time the checking function is called, it will see the header 
sitting in the first sector, and output some message.

Apart from that the error resolution is pretty outstanding currently.

So I propose to:

- not need any VG
- is_lvm will return true if only a header is present
- sanity checking is not done much in setup.c unless it is a call to 
lvm.c


If you really have zero sector PV header, currently the "info" message 
will be output at least twice, and possibly trice:

- in lvm_detect
- in lvm_embed
- in any checking function called from setup.c

I have put a parameter to get_lvh that supresses the verbosity if zero.

You will see.

At this point the whole VG initialisation system for embedding is only 
apparently needed to check the actual bootloaderarea.


CURRENT RESULTS:
----------------

First off, booting works fine from a non-partition setup. I assume there 
is no difference installing to a disk with a partition table and no LVM.

Personally I cannot get Grub to install on /dev/sda1:

error: cannot find a GRUB drive for /dev/sdal.  Check your device.map.


Presently, this is the output if you try to install on a first-sector PV 
without VG:

info: Scanning for lvm devices on disk hostdisk//dev/sda.
info: couldn't find ID
info: LVM signature in first sector.
warning: installing inside LVM PV, but its header is sitting in the 
first sector; cannot install there.
error: embedding is not possible, but this is required for LVM and RAID 
install.

Upon creating a volume group, LVM will actually restore the PV header to 
the 2nd sector, if you've botched it.

A zero sector (first sector) PV is just not reality.

They are not recognized.


Installing on a PV without bootloaderarea will result in:

info: Scanning for lvm devices on disk hostdisk//dev/sda.
info: Found array linux.
info: Inserting hostdisk//dev/sda (+0,976773168) into linux (lvm)
info: drive = 1.
info: the size of hostdisk//dev/sda is 976773168.
info: Scanning for DISKFILTER devices on disk hostdisk//dev/sda.
warning: you have chosen to install inside an LVM PV, but it doesn't 
have a bootloader area (check pvcreate --bootloaderareasize).
error: embedding is not possible, but this is required for LVM and RAID 
install.

When a VG is present.

I don't think it actually checks for the SIZE of the bootloaderarea but 
that could easily be added I think.

When you do the same without a VG:

info: Scanning for lvm devices on disk hostdisk//dev/sda.
info: couldn't find ID
warning: you have chosen to install inside an LVM PV, but it doesn't 
have a bootloader area (check pvcreate --bootloaderareasize).
error: embedding is not possible, but this is required for LVM and RAID 
install.


  reply	other threads:[~2016-05-09  0:11 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-08  4:53 [PATCH] Install to LVM PVs Dryden Personalis
2016-05-08  6:05 ` Andrei Borzenkov
2016-05-08  8:47   ` Andrei Borzenkov
2016-05-08 13:10     ` Dryden Personalis
2016-05-08 17:16     ` Dryden Personalis
2016-05-08 17:40       ` Dryden Personalis
2016-05-08 13:01   ` Dryden Personalis
2016-05-09  6:07     ` Andrei Borzenkov
2016-05-09  8:41       ` Dryden Personalis
2016-05-09 16:10       ` Dryden Personalis
2016-05-09 16:18         ` Dryden Personalis
2016-05-09 17:56           ` Dryden Personalis
2016-05-17 18:01       ` Dryden Personalis
2016-05-08  9:23 ` Andrei Borzenkov
2016-05-08 13:09   ` Dryden Personalis
2016-05-09  0:10   ` Xen
2016-05-09  0:10     ` Dryden Personalis [this message]
  -- strict thread matches above, loose matches on Subject: below --
2013-09-25 12:39 Gabriel de Perthuis
2013-09-26  8:53 ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-09-27 10:39   ` Gabriel de Perthuis
2013-09-27 10:39     ` Gabriel de Perthuis
2013-09-27 12:48     ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-09-27 13:56       ` Gabriel de Perthuis
2013-09-27 13:56         ` Gabriel de Perthuis
2013-09-27 14:27       ` Andrey Borzenkov
2015-02-15 10:47       ` 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=affaae46e979909eac0ef9614fadf0f4@dds.nl \
    --to=list@xenhideout.nl \
    --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.