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
Steps to Reproduce:
1. genkernel --lvm2 all
2. reconfigure grub & reboot
3. lvm2 not activated before boot
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.
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 188.8.131.52-r1 (default-linux/x86/2005.0, gcc-3.3.5-20050130,
glibc-184.108.40.20641102-r1, 220.127.116.11-dwh i686)
System uname: 18.104.22.168-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]
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
CFLAGS="-O2 -pipe -fomit-frame-pointer"
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"
FEATURES="autoconfig distlocks sandbox sfperms strict"
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
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
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
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
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.