Bug#378344: closed by maximilian attems <maks@sternwelten.at> (Re: Bug#378344: initramfs-tools: Should be able to force root device for update-initramfs)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
reopen 378344
thank you
Hello, Maximilian,
thanks for addressing my bug report. Your council does not help me all that
much, though. I do not feel my concerns have been addressed.
I try to repair this situation by answering some of your arguments, and
also by explaining my concern more clearly.
> the initramfs will just boot without any root bootarg,
> beware that an root bootarg overides this hardcoding.
> (initrd-tools compat + repair capability)
So far, so good, yes.
The problem I was experiencing: The initramfs will not be able to mount the
desired LVM root unless LVM software is contained in that initramfs. And
that software will not be contained in that initramfs, if the initramfs
building-process had not understood that root is on LVM. And finally, there
is no easy, well-documented way to force the initramfs building tools to
use a particular root file system (and the software it deems neccessary to
boot from it), or even a particular name for the current root file system
(if that helps the building tools to discern where the file system lives).
In particular, switching from non-LVM root to LVM root by simply providing
arguments to the boot process through grub does *not* work. (Not that much
compat+repair capability, really.)
> once the bootloader points to the lvm2 root dev aka /dev/mapper/vgX-root
> the box will happily boot from that, provided you have lvm2 installed
> there. no need to regenerate the initrd.
My experience is different. No happy boot.
For me, it was not possible for /dev/mapper/vgX-root to even exist during
the boot process, unless the initramfs itself already contains LVM
software. At a minimum, vgchange needs to be present to activate vgX.
But there is no easy way to force it to be there. That is the problem I'm
trying to describe.
Or if there is such an easy way, I have not found the documentation in the
manual pages.
> if there was previously _no_ lvm2 installed you need to update it
> update-initramfs -u
Again, my experience is different.
When I newly install LVM2, my root at that point clearly is not under
LVM2-control yet.
In my experience, that fact is reason enough for "update-initramfs -u" to
*not* copy LVM software to the initramfs. LVM software will not be picked
up just because it is available, but only if the build scripts are
convinced that the root file system actually lives on LVM.
It becomes a chicken and egg problem. I cannot switch to a LVM2 root
because I cannot boot into such a root, as long as the initramfs does not
contain LVM2. And on the other hand, the initramfs will never pick up LVM2,
unless I have already managed to boot into the LVM2 root.
> this will go away soonest as lvm2 will get the hooks and regenerate
> latest initramfs on install with relevant lvm2 boot scripts.
Good news! But, for one, I would prefer my bug reports to be left open,
util the bugs are actually fixed. And, secondly, I'm a bit sceptic. The
regeneration process itself will still need to be changed from how it
currently operates.
Here is my concerned spelled out, I hope, more clearly:
I consider the problem solved, if there is a documented way to move a
system from an old setup, e.g., "root on /dev/hda5", to a new setup "root
on some LVM".
For a specific example, I may have bought and installed this shiny big new
/dev/hdb, I may want to move my entire system to an LVM vg that lives on
/dev/hdb, and then remove my old /dev/hda and give it to my daughter to
play with. How do I do this?
More general, I may want to play with any odd file system container that
the initramfs-scripts support, and set up a dual boot for that purpose.
This is not really a "root on LVM" issue, but a more general "move from
root on A to root on B" issue. What is the general recipe? How do I do that?
My suggested "I want this particular root" - option would solve all those
problems, for LVM and any other file system containers the
initramfs-generating scripts happen to support.
"If you can mount it now, you can boot from it next time."
Regards,
and thank you for providing fine software and services,
Andreas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFEy7EVnWrlKaIH40ARAvYCAJ91ALJ/BS7BcuFa33vN+amDEHcf9gCghi46
+ITVPYPGdDCtdb8nGmETyJ8=
=gtSx
-----END PGP SIGNATURE-----
Reply to: