Older versions of genkernel build initrd's that work great with root on lvm2. 'genkernel --lvm2 all'. 3.2.7 is different: it does not attempt to activate lvm2 before mounting root unless the option 'dolvm2' is given on the kernel's command line. Reproducible: Always Steps to Reproduce: 1. genkernel --lvm2 all 2. reconfigure grub & reboot 3. lvm2 not activated before boot Actual Results: root was not mounted because its lvm2 volume had not been set up. Workaround: shell, 'vgchange -ay', exit shell, specify lvm2 boot device. Workaround 2: add 'dolvm2' to kernel command line. Expected Results: lvm2 should have been activated before root as implied by 'genkernel --lvm2', preserving the old default behavior. I think the fix is to add USE_LVM2_NORMAL=1 to etc/initrd.defaults in the initramfs, either always or more probably only if --lvm2 is specified. Portage 2.0.51.22-r1 (default-linux/x86/2005.0, gcc-3.3.5-20050130, glibc-2.3.4.20041102-r1, 2.6.12.3-dwh i686) ================================================================= System uname: 2.6.12.3-dwh i686 mobile AMD Athlon(tm) XP-M (LV) 2200+ Gentoo Base System version 1.6.12 distcc 2.16 i386-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] dev-lang/python: 2.3.5 sys-apps/sandbox: 1.2.8 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r7 sys-devel/libtool: 1.5.16 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i386-pc-linux-gnu" CFLAGS="-O2 -pipe -fomit-frame-pointer" CHOST="i386-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" LANG="en_US.utf8" LC_ALL="en_US.utf8" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage /usr/local/zugaina-portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X accessibility alsa apache2 apm avi berkdb bitmap-fonts bonobo c++ cdr cle266 crypt cscope cups curl dvd dvdr emboss encode fam ffmpeg flac foomaticdb fortran gd gdbm gif glut gnome gphoto2 gpm gstreamer gtk gtk2 gtkhtml guile hal imlib innodb insecure-drivers ipv6 jack java jikes joystick jp2 jpeg jpeg2k junit kde lcms ldap libg++ libwww live mad mikmod mmx motif mozilla mp3 mpeg mysql mythtv ncurses nls nptl ogg oggvorbis opengl oss pam pdflib perl png postgres python qt quicktime readline sdl slang speex spell sse ssl svga tcltk tcpd tiff truetype truetype-fonts type1-fonts unichrome unicode vorbis xine xml xml2 xmms xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LDFLAGS, LINGUAS
genkernel's initrd and gentoo's boot process in general is sophisticated and amazing. I miss it in other distributions. any chance of a --vim or --tetris option for a more sophisticated initramfs? ;-)
IMHO this is a feature, not a bug.
This is a feature. This was set this way so that people can choose which way to startup their system. This way if they have an initramfs with lvm and evms in it they wont fight with each other and you can boot a system either way giving a more feature filled initramfs. This was mainly done for livecd support as we had numerous bug reports stating that lvm and evms didnt work together, but some people want differing volume managers.
Yes, but the fix violates the principle "First do no harm." Instead of requiring knowledgable people who make livecd's and are already interested in a cure to add a new option to their genkernel invocations, it causes people like me to spend weeks and multiple bug reports wondering why there is new behavior from the same previously fruitful processs. Livecd maintaners in turn also do the same thing with different results. In my case, the most efficient way to discover the presence of the new option was to unpack the initramfs and read its source code. Would you accept a patch that attempts evms or lvm2 automatically if the initramfs was only configured with one volume manager? A warning message perhaps? Is there a better way to keep abreast of this kind of important change to gentoo?
We do not want any auto-detection of any volume management. We have created new documentation on the new features and changes of genkernel, but have been too busy working on the release to get it all submitted to the handbook. Anyway, we're just going to make genkernel give output saying that the option requires command line options added.
See it is impossible for me to read the documentation for every new release of every gentoo package to see whether it will break my system. If it already has broken my system then I have a broken system. I have no need for it to auto detect my volume manager. I just need to be able to tell it which volume manager I have when I build my own initramfs. Until recently this was called "genkernel --lvm2 all". Do these 'my volume manager doesn't work' bug reports originate from people who ran genkernel themselves? What was genkernel doing for evms & lvm users before 2005.0? It is very easy to unpack the initramfs, at least it is very easy to unpack the components. The initramfs is astonishingly n concatenated gzipped cpios -- they are gzipped first, then concatenated. Go find the major components of your initramfs in /usr/share/genkernel/pkg/$ARCH/cpio . 'gunzip < cpiofile | cpio -i' extracts them. This method is sufficient to see what's going on in there. genkernel builds these cpios so editing the cpio and repacking it would be an inefficient means to having a different initramfs. The old initrd method was a gzipped filesystem. You can edit those by gunzipping them then mounting them loopback. The new method makes it much simpler to build initramfs without root permissions and with modular pieces of the boot process.
(In reply to comment #6) > See it is impossible for me to read the documentation for every new release of > every gentoo package to see whether it will break my system. If it already has > broken my system then I have a broken system. I have no need for it to auto > detect my volume manager. I just need to be able to tell it which volume manager > I have when I build my own initramfs. Until recently this was called "genkernel > --lvm2 all". Except genkernel didn't break your system. At least, not without you taking action to make it do so. It isn't our fault that you went with a piece of software that had a minor version bump, which means it is significantly divergent from previous versions enough to warrant that rather than a point release, without checking to see if something you're depending on might be broken. > > Do these 'my volume manager doesn't work' bug reports originate from people who > ran genkernel themselves? What was genkernel doing for evms & lvm users before > 2005.0? It was broken before. Period. If you used both, it didn't work. The 2005.0 CD didn't even have evms enabled because of this and there have been numerouns bugs filed due to the problems of automatically enabling volume management. The original intention of the volume management flags in genkernel was to add support for them, not to enable them. The fact that this was not the case was a *bug* itself. I'm sorry that you have relied on buggy behavior that was not intended. The behavior has changed to what was intended originally. > It is very easy to unpack the initramfs, at least it is very easy to unpack the > components. The initramfs is astonishingly n concatenated gzipped cpios -- they > are gzipped first, then concatenated. Go find the major components of your > initramfs in /usr/share/genkernel/pkg/$ARCH/cpio . 'gunzip < cpiofile | cpio -i' > extracts them. This method is sufficient to see what's going on in there. > genkernel builds these cpios so editing the cpio and repacking it would be an > inefficient means to having a different initramfs. I know how the process works, but I really don't have a *clue* what you're going on about here for. If you want to enable lvm2, you need to add "dolvm2" to your bootloader. We cannot do this automatically due to conflicts, mentioned above. We also don't care to add any detection routines for this, as it is simply easier and more consistent to tell people to always add do$blah to their bootloader for $blah support. Anyway, this entire thing is because of changes to resolve a bug. The bug was the unintended auto-starting of volume management. This is essentially a request to reverse that decision, which is something we are not willing to do.
