I've got a lot of LVM2 partitions which must be checked and mounted on startup. And I compile DeviceMapper support as a module, i.e. dm-mod. This always worked on Mandrake, and my root partition is a normal one, so this setup should work. However, to make it work, I had to setup autoloading of dm-mod in /etc/modules.d. In Mandrake, instead, there is this code to make it work: if [ -f /etc/lvm/lvm.conf -a -x /sbin/lvm2 ]; then grep -q -s 'device-mapper' /proc/devices /proc/misc || modprobe dm-mod >/dev/null 2>&1 if grep -q -s 'device-mapper' /proc/devices /proc/misc; then # (do the well-known setup - /proc/devices is also checked to support 2.4 # kernels with DeviceMapper. Since users are free to do that anyway (even if # not yet supported by Gentoo), this is another correction to do to checkfs. Reproducible: Always Steps to Reproduce: 1. Setup a system with LVM2 partitions. 2. Use for it a kernel with modular dm-mod. 3. Try to boot it. Actual Results: Since dm-mod does not exist, the device nodes cannot be created and the boot fails, asking me to manually correct the error. Expected Results: Powering on a PC should make it boot, I think ;-) Portage 2.0.51-r3 (default-x86-2004.2, gcc-3.3.4, glibc-2.3.4.20040808-r1, 2.6. 9-skas3-v7 i686) ================================================================= System uname: 2.6.9-skas3-v7 i686 AMD Athlon(tm) 64 Processor 3000+ Gentoo Base System version 1.5.3 ccache version 2.3 [disabled] Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.14.90.0.8-r1 Headers: sys-kernel/linux26-headers-2.6.8.1-r1 Libtools: sys-devel/libtool-1.5.2-r5 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3. 3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config / usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/ share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon-xp -O2 -pipe" DISTDIR="/home/portage/distfiles" FEATURES="autoaddcvs distlocks sandbox sfperms strict userpriv usersandbox" GENTOO_MIRRORS="http://gentoo.mirror.sdv.fr http://mirror.switch.ch/mirror/ gentoo/ http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://www.ibiblio. org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="3dnow 3dnowex X X509 aalib acl acpi aim alsa arts artswrappersuid avi berkdb bitmap-fonts bzlib cdr crypt cscope cups dba dvb dvd dvdr dvdread encode erandom ethereal flac foomaticdb fortran ftp gd gdbm gif gphoto2 gpm gtk gtk2 iconv icq ideaimap imlib innodb irda jabber jpeg jpeg2k junit kde kerberos krb4 ldap libcaca libg++ libwww live lua lzo lzw-tiff mad maildir mbox md5sum mikmod mime mmx mmx2 mng motif mpeg mpeg4 msn mysql mythtv ncurses nls nptl oggvorbis opengl oss pam pda pdflib perl php pic png pnp ppds python qt quicktime readline real rtc samba scanner sdl session slang slp smime sse sse2 ssl svg sysvipc tcpd tetex tga tiff truetype unicode usb userlocales v4l v4l2 wifi winbind x86 xanim xine xml xml2 xmms xosd xpm xsl xv xvid xvmc yahoo zlib"
how dare we expect users to setup their own kernel modules :P that said, test this patch for me: Index: init.d/checkfs =================================================================== RCS file: /var/cvsroot/gentoo-src/rc-scripts/init.d/checkfs,v retrieving revision 1.42 diff -u -r1.42 checkfs --- init.d/checkfs 3 Oct 2004 00:37:54 -0000 1.42 +++ init.d/checkfs 13 Nov 2004 06:01:25 -0000 @@ -217,6 +217,11 @@ local mountline mount swap options pre_mount post_mount source if [ -f /etc/conf.d/cryptfs ] && [ -x /bin/cryptsetup ]; then + if [ -e /proc/modules ] && \ + grep -qs 'device-mapper' /proc/devices ; then + modprobe dm-mod &>/dev/null + fi + ebegin "Setting up dm-crypt mappings" while read mountline; do
Your patch maybe works for you, but obviously won't work when not using dm-crypt. A similar check must be added for LVM2. Also, the patch seems not functional to me. How can grep -qs 'device-mapper' /proc/devices succeed when dm-mod is absent from the kernel / not loaded? It can't. I suppose there is a missing '!'. Also, it should also search for device-mapper in /proc/misc - I remember that I needed to search both to make sure it worked both with 2.6 and 2.4 kernels. Maybe this has changed, but I think it was so with older 2.6 kernels / with 2.4 kernels... I don't remember well.
> Your patch maybe works for you, but obviously won't work when not using > dm-crypt. A similar check must be added for LVM2. i never said it worked for me, it doesnt work for me, i dont use LVM2 or dm-crypt at all ... i wrote a freehand patch to try and fix the bug since you hadnt proposed a patch that worked for you > Also, the patch seems not functional to me. How can grep -qs 'device-mapper' > /proc/devices succeed when dm-mod is absent from the kernel / not loaded? It > can't. I suppose there is a missing '!'. it is missing a '!', like i said, i have no way of testing the patch since i could care less about LVM2/dm-crypt :P try this patch again (and NO, i HAVENT tested it): Index: init.d/checkfs =================================================================== RCS file: /var/cvsroot/gentoo-src/rc-scripts/init.d/checkfs,v retrieving revision 1.42 diff -u -r1.42 checkfs --- init.d/checkfs 3 Oct 2004 00:37:54 -0000 1.42 +++ init.d/checkfs 13 Nov 2004 22:06:23 -0000 @@ -217,7 +217,12 @@ local cryptfs_status=0 local mountline mount swap options pre_mount post_mount source - if [ -f /etc/conf.d/cryptfs ] && [ -x /bin/cryptsetup ]; then + if [ -f /etc/conf.d/cryptfs ] && [ -x /bin/cryptsetup ] ; then + if [ -e /proc/modules ] && \ + ! grep -qs 'device-mapper' /proc/{devices,misc} ; then + modprobe dm-mod &>/dev/null + fi + ebegin "Setting up dm-crypt mappings" while read mountline; do
well ? does the proposed patch fix the problem or not ?
Sorry for not answering this, but I've been a bit annoyed about you not reading what I said and trying to make a fool of me. So, I decided that my only answer would have been a real patch for it - but I've been doing more important stuff, and I haven't found the time to fix it myself. When I saw your message, I realized I should have written something. I'm not a newbie - you said "how dare we expect users to setup their own kernel modules :P" but my problem is not that I'm not able to do it (I'm a kernel programmer)... the problem is that if Mandrake just works, Gentoo having problems is something that should make you scream and hurry to fix that! Most people just become snobs when anyone names Mandrake... they shouldn't let it be anyhow better than their distros (not that you every spoke against Mandrake). Now, here is what you should have read: Quoting my original message: > Steps to Reproduce: > 1. Setup a system with LVM2 partitions. Quoting my answer to the first patch: > Your patch maybe works for you, but obviously won't work when not using dm-crypt. A similar check must be added for LVM2. Now, what else must I say so that you realize I'm not using dm-crypt? If you read my message, you'll understand that the patch can't work. These are the lines to patch: if [ -z "${CDBOOT}" -a -x /sbin/vgscan ] && \ [ -d /proc/lvm -o "$(grep device-mapper /proc/misc 2>/dev/null)" ] then ebegin "Setting up the Logical Volume Manager" #still echo stderr for debugging /sbin/vgscan >/dev/null and obviously, the checks inside /proc/ must be retried *after* loading the module. /bin/cryptsetup does not even exists on my box! Normally, it happens that newbies don't read docs / messages. I'm not expecting this from distro's core maintainers. Especially, I can accept they have not enough time, but I cannot except anyone of them answering like this to a bug report!
Created attachment 45210 [details, diff] lvm2-69595.patch i wont bother answering the non-technical issues here since they're getting us nowhere try this paatch
Created attachment 45212 [details, diff] lvm2-69595.patch err last patch still had the useless 2nd hunk
Additional notice: I use baselayout 1.10.4, and cryptfs support was added in 1.11.0. The changelog, however, does not mention at all fixes to my problem... I'm going to emerge it and read the new code... don't expect it to work any better, though. I'm now going to check the patches you've attached... and thanks for answering on the technical issues. I'll briefly answer about the patches.
Ok, wow, now we are getting serious, thanks for the prompt answer. The patch appears to do what it should... I'm going to apply it now and disable the workaround I used. I'll make you know the results when I reboot (which will happen in a couple of days). ->> However, I'm going to use the first patch, not the second one. I think that the second hunk is useful... I'm not experiencing the cryptsetup problem, but it is another bug you spotted. And if I install dmcrypt without LVM2, without the second hunk, dm-crypt cannot rely on dm-mod being loaded in the previous check. And that is a perfectly meaningful setup, IMHO - dmcrypt just requires device-mapper, LVM2 is one add-on on top of devicemapper. Also, *maybe* (I thought to this just today), if EVMS2 uses devicemapper (this is correct IIRC, but I'm not sure), we must make sure that either /sbin/evms_activate loads the dm-mod module as needed or that we do it in the scripts - for that, however, I have no clue at all (I just have read something about EVMS1 and the changes in EVMS2, which is entirely userspace).
any luck with the patch ? we're looking to release another version soon ... would be nice to sneak this in :)
I've not yet tested the patch, because I've been away from my PC for a while. Since it didn't apply to 1.10.x, I updated to 1.11 and left the autoload configuration as-is. Well, it *does* not work (with udev at least)! After autoloading the modules, vgchange -a y during checkfs (I think it's during checkfs) says it cannot open /dev/mapper/control, complainining about possible "missing devicemapper support in the kernel!" It asks the root password, I enter it, and if I execute "vgchange -a y" at the prompt, it works, and when I exit the shell it finished the boot nicely without other problems! I'm going to test the patch ASAP, however I'd merge it anyway if it gives no problem to non-LVM2 users...
The new problem I've had at boot after I updated from baselayout 1.10.x to 1.11 (confirmed as of 1.11.8) seems to be some kind of problem with udev (both 040 and 050 tested)... i.e. udev does not create /dev/mapper/control. With the updated baselayout, (independently from your patch, which I think you already included in the thing) I've needed to add a patch to get the boot to proceed, to create the /dev/mapper/control device node before activating logical volumes (it is done with the script scripts/devmap_mknod.sh included in the device-mapper tarball)... 1) in the system recovery shell started by sulogin, if I rmmod and modprobe dm-mod, the device node is correctly created (after a visible pause). This command: # ls /dev/mapper/control; rmmod dm-mod; modprobe dm-mod; ls /dev/mapper/control; sleep 1; ls /dev/mapper/control gives as result that the device node exists the 1st and the 3rd time and does not the 2nd one (I think this is because udev hasn't yet had the time to create it)... However, even if I wait for the device node to appear in the boot-scripts (I've tried until 4 seconds), it does not get created... I'm attaching a couple of test-patches against 1.11.8, the first used for debugging (which uses a fixed "63" as minor number and breaks against inotify, i.e. does not work for me with 2.6.10), the second is the one which I use now. They are checkfs-create-node-v[23].patch.
Created attachment 50353 [details, diff] Debugging patch to fix my problem. Debugging patch which fixes the problem and helps diagnosing it (breaks against inotify, as explained in the comment)
Created attachment 50354 [details, diff] The patch I'm using to fix the device node problem now Production patch (with some debugging code) which fixes the problem and is safe against changes in the minor assigned to /dev/mapper/control (i.e. against inotify: the same major/minor used for /dev/mapper/control on 2.6.9 are taken on 2.6.10 with inotify enabled. cat /proc/misc confirms this fact).
Forgot to node: invariably, all the echoes in the patches says that until I don't do an explicit mknod, the device node is not created... and this even after the module is loaded. After creating the node with mknod, everything goes on well.
Upgrading to baselayout 1.11.10-r4, I saw that the support we added was removed to go back to the old code requesting the user to explicitly load the module. Meanwhile, the problem with the device node not being created has disappeared (and the only change to checkfs related with this was the removal of the patches discussed here). Have you found out what the hell was happening on that system? Also, is there any baselayout developer using LVM2 on its root (IIRC you aren't)?
The problem with it working once you logged in with your password and not through the script was a kernel timing issue. Which was addressed in bug #72746. My opinion on this one, set it up yourself. And drop the attitude, Spanky's being nice (for once) and all you're giving him is grief and refusing to test his patches. Why should he help? Or better yet, do like me and just compile the damn module in so you don't have issues. It's a CORE module for accessing partitions... compile it in!
these all need to be redone against lvm2-start.sh in the FILESDIR of lvm2
Ok, we already settled down the initial grief... and when I had time I did test his patches (don't look only at the start of the thread, but starting from comment #8. I didn't test the 1st patch because it only touched cryptfs, and for the 2nd I hadn't had the time nor had I rebooted my laptop, I reboot it once in a week often). And yes, at the end I've set up autoloading and then switched to compiling in the module. However, if you want mark it as WONTFIX, but I feel that the module autoloading has no drawbacks. Also I'm curios why it was dropped in recent releases, I think the fix was merged at some point.
yes, i would like to add some modprobe code in there which is why this bug is still open i'm not aware of any code being dropped ... at least not on purpose ;) with baselayout-1.11.12, all evms/lvm/raid/etc... code has been removed and placed into addon modules that come with the respective packages
current lvm2-start.sh modprobes dm-mod if need be re-open with a patch against /lib/rcscripts/addons/lvm2-start.sh if you need something else added
