[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Install to LVM PVs
From: |
Dryden Personalis |
Subject: |
Re: [PATCH] Install to LVM PVs |
Date: |
Mon, 09 May 2016 02:10:49 +0200 |
User-agent: |
Roundcube Webmail/1.1.5 |
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.
- Re: [PATCH] Install to LVM PVs, (continued)
- Re: [PATCH] Install to LVM PVs, Dryden Personalis, 2016/05/08
- Re: [PATCH] Install to LVM PVs, Andrei Borzenkov, 2016/05/09
- Re: [PATCH] Install to LVM PVs, Dryden Personalis, 2016/05/09
- Re: [PATCH] Install to LVM PVs, Dryden Personalis, 2016/05/09
- Re: [PATCH] Install to LVM PVs, Dryden Personalis, 2016/05/09
- Re: [PATCH] Install to LVM PVs, Dryden Personalis, 2016/05/09
- Re: [PATCH] Install to LVM PVs, Dryden Personalis, 2016/05/17
Re: [PATCH] Install to LVM PVs, Andrei Borzenkov, 2016/05/08