-----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----- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
