I have become interested in applying an old patch from someone who had
modified Grub (2) to enable booting directly from PVs (LVM PVs).
So I downloaded the source package using deb-src and apt-get source
grub2
Then I change the patch to agree wit the newer version. I mentioned it
on the Grub2 mailing list. Initially people were responsive, at least
one person was.
Maybe I took them too much time, but that person hasn't responded for a
while, neither in private, so I do not really know what is going on with
him, and it seems other people are delegating it to him.
However I would like to find out how I can at least solidify my changes
for myself, since I intend to use the patch on a new installation of my
own.
(Next step would be to modify LUKS to allow the same thing on a LUKS
container without partitions).
I have read some of the Ubuntu packaging guide.
Most importantly:
- It seems the only commands I need are edit-patch, then apply my diff,
exit the edit-patch shell,
- run "bzr builddeb -- -S -us -uc", then run "pbuilder-dist <release>
build ../<package>_<version>.dsc" to actually build the binary package.
Personally for me I just want a quick way to apply my patch to newer
versions as they may come out, so that I need not do so much work if I
pick this up again later.
Currently I am just building on my local system using Grub makefiles and
all. But I cannot build on my main system (it runs off USB2 :P) so I
have been "making" on a real harddisk (actually SSD).
The patch is not really ready yet for primetime, although it works fine,
I cannot test it on partitions (grub won't install on any partitions)
and there is one small caveat in that it probably doesn't check for all
anomalies that may arise, such as remaining "garbage" from previous PVs
that were created before the current one in the same space, as well as a
bootloaderarea size that is too small (it requires pvcreate
--bootloaderareasize 2048s, or pvcreate --bootloaderareasize 1M. To give
grub space to install in the PV (embedding)).
All the same it works perfectly for its intended purpose, which is to
install in a PV without partitions. At the same time it will probably
install in any other PV that has the required bootloaderarea, such as
those residing in partitions (although it doesn't work for me, but
neither does standard grub2) (in that sense that I cannot install to
partitions AT ALL on this system) -- and its behaviour with respect to
anything and everything else, is not changed.
Basically the patch just allows a bootable system in a 'root disk' (such
as /dev/sda) in which a PV was created (using --bootloaderareasize) that
will keep the bootsector intact (first 512-byte sector) (the PV header
is always installed, apparently, in the 2nd sector). Which means, that,
effectively, you can run:
dd if=/dev/zero of=/dev/sda bs=1M count=4 # just wiping in case
something remains from a previous install, not really necessary
pvcreate /dev/sda --bootloaderareasize 1M
grub-install /dev/sda
And depending on the grub configuration, you will now have a system that
will boot just fine. It does not need a volume group to be present in
the PV. Obviously you would normally have a complete system. I haven't
actually tested that yet, but it would make no difference. In a real
system:
pvcreate /dev/sda --bootloaderareasize 1M
vgcreate linux /dev/sda
lvcreate .....
lvcreate .....
mkfs.ext2 ....
mkfs.ext3 ....
# install the system
# install grub in /dev/sda
# done.
And this system will simply boot, have no partitions (msdos, gpt, ...)
but only a single PV, that contains a VG, that contains LVs.
Impossible, at this point, to use LUKS with, because LUKS appears to
overwrite the bootsector, and may not have that "embed" area yet.
Unless of course you would create LUKS inside an LV inside this PV.
So the only model that currently exists for this is:
/dev/sda == PV
---> VG "linux" (or "ubuntu", or "whatever")
---> /dev/linux/boot
---> /dev/linux/root
---> /dev/linux/home
---> /dev/linux/crypt (contains LUKS header/container)
Additional volumes can then exist inside an additional LVM inside that
LUKS container.
Not recommended for anyone novice, but under normal circumstances the
initrd would probably try to open that container if specified in
crypttab, and you could put root and home volumes in it, if desired.
In that case you'd have an additional LVM saying:
/dev/sda == PV
---> VG "linux"
---> /dev/linux/boot
---> /dev/linux/crypt
create vg "crypt" inside of that
---> /dev/crypt/root
---> /dev/crypt/home
All kinds of options.
Anyway, that is the state of the system.
=====================================================
My question would be:
- Is this a smart way of keeping local changes? The benefit is having an
actual .deb that I can actually install when used on my own systems
- I would have a way to easily regenerate source packages as well as
binary packages.
The downside is that it creates a new version that replaces the default
grub, whereas with normal build scripts, it gets installed in
/usr/local.
Would love to hear your feedback.
Regards.
--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
