LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (http://www.linuxquestions.org/questions/slackware-14/)
-   -   LVM2 root partitions not mounting at boot - HELP! (http://www.linuxquestions.org/questions/slackware-14/lvm2-root-partitions-not-mounting-at-boot-help-4175439898/)

muahahaha9001 12-03-2012 11:38 PM

LVM2 root partitions not mounting at boot - HELP!
 
I have a new install of Slackware 14.0 on my laptop. The bootloader is GRUB2 on a separate flash drive. Most of the directories in / including the root directory itself (/) are LVM2 logical volumes. When I was chrooted into the laptop's hard drive, I was able to create an initrd for booting using the mkinitrd_command_generator.sh script.

As it stands, the laptop can only be fully booted if I manually mount the LVM2 partitions during the booting process. What happens is the normal booting process halts saying something about /sbin/init missing and opens a shell for me to fix it before the booting process continues. I eventually discovered that all the LVM2 partitions weren't mounted under the /mnt directory like they were supposed to be. What I did was mount all the partitions as if I was going to do a chroot from the Slackware Live DVD, then exit the shell for the boot process to continue. The laptop booted just fine but it sure was a hassle activating and then mounting all those partitions.

How do I fix this? I'm new at this and am unsure of where to look.

In my grub.cfg there are a few insmod entries and during the boot process I see something explicit in the output for each insmod except for the lvm insmod. Despite that, one of the messages I see before the mid-boot shell appears says that there are 12 active lvm volumes. Strange.

Any advice would be greatly appreciated!

jpollard 12-04-2012 09:16 AM

Not sure this will work, but since your mount did work I think this should:

When you make the initrd, add "-r /dev/<your root device>".

I had to do this when creating a VM running slackware - Until I added the drivers (the virtual io stuff) and "-r /dev/vda3" it too would stop until I manually mounted the root filesystem and exited.

muahahaha9001 12-04-2012 11:08 AM

Thanks but the mkinitrd_command_generator.sh script generated a command which included the -r flag and the root device path already. Nice try though.

I went through the logs and found some of the messages I was seeing during boot. I could post them if it could help anyone.

At this point I'm contemplating writing a script to act as a band-aid for the situation. Basically, when the boot process stops and drops into the shell, I'll have it execute a bash script that will automatically activate the logical volume partition, do all the proper mounting for me, and then exit the shell. It isn't perfect, but it should save me the trouble I'm experiencing now. At this point there are still some things I need to learn about initrd and shell scripting before I could write such a script. The shell environment of initrd has no /etc/profile and I'm not even sure if initrd can be written to with persistence.

With a script like that, it still wouldn't change the fact that somehow, something seems to be misconfigured.

Richard Cranium 12-05-2012 09:26 AM

When you did the original chroot, did you run...
Code:

mount -B /dev /mnt/dev
mount -B /sys /mnt/sys
mount -B /proc /mnt/proc

...prior to chrooting and running mkinitrd_command_generator.sh?

I'm running grub2 with my root partition on an LVM2 logical volume on the machine that I'm using to type this.

muahahaha9001 12-05-2012 01:56 PM

Hi Richard Cranium. Thanks for the reply. Yes, I did make sure to mount those things. It was a frustrating having nothing work until I realized those three things were necessary for a proper chroot. Without using them, I wouldn't have been able to boot the system out of initrd in the first place.

Here is how I fixed the problem: First I used a guide on Ubuntu's wiki to decompress, edit, and recompress /boot/initrd.gz. I was able to make the proper edits to initrd when I found that the initrd had it's own /init script that did the mounting of the root file system. I modified that to mount my other partitions ( /sbin, /bin, /etc, /var, /usr, /lib, /opt, /home, ... ) in addition to mounting my root partition. After compressing the temporary initrd directory I had made for doing the edits, I realized that the file I ended up with was much larger than the original initrd.gz. I had thought there might have been a difference in how the two initrd.gz files had been compressed and was worried that the compression differences would cause a problem. Luckily they did not. Now the boot process goes straight to the login prompt and there is no interruption that drops to an initrd shell anymore. So I'm happy. My new slackware laptop rocks for the most part.

The solution isn't perfect. I'm not entirely sure how exactly these partitions should be mounted because I was seeing some error messages about needing partitions to be mounted read-only in order to do filesystem checks at start up and that there had been a number of aborted filesystem checks for certain partitions. Either I'll find a way to stop the filesystem checks from being attempted or I'll find the right way to mount these filesystems from initrd's init script. My Slackware 14.0 install was a 'full' install so there are probably a lot of unnecessary things happening at start up.

GazL 12-05-2012 02:30 PM

Quote:

Originally Posted by muahahaha9001 (Post 4843393)
HI modified that to mount my other partitions ( /sbin, /bin, /etc, /var, /usr, /lib, /opt, /home, ... ) in addition to mounting my root partition..

/bin, /sbin, /lib and /etc shouldn't be separate partitions. They belong in the rootfs. I'm not surprised you had problems.

T3slider 12-05-2012 02:30 PM

Do you really have /sbin, /bin, /etc, and /lib on separate partitions? This would be completely unsupported in Slackware as far as I know.../usr, /home, /var, /tmp, /opt and /boot are fine living on their own partitions, but I think every Linux guide anywhere would recommend keeping /etc, /sbin, /bin, and /lib (and /lib64) on the root (/) partition. The init scripts are located in /etc, and they are required for properly setting up the system (and they may use utilities from /sbin and /bin, which may use libraries from /lib). Therefore, all four directories *must* be mounted in order for the system to boot. If you don't want to reinstall, the only way to get it to boot is to hack the initrd, which you have done; but I see very little utility in such a setup...

[edit] Too late I see. [/edit]

muahahaha9001 12-05-2012 07:37 PM

Quote:

but I see very little utility in such a setup...
Probably. This was my first time using Slackware which is the most barebones distro I've had the chance to try. I was curious about the kind of space each one of these directories would consume and what the optimal amount of space would be for each of them. The quota program might have been another option to keep track of how much space was consumed but I've always liked the features that come with LVM2.

Just curious, how would you more expereinced guys determine the best partition size for the root file system and other partitions?

Anyone care to guess what options the mount command needs in initrd to mount these partitions in a way that allows the start up filesystem check to happen?

jpollard 12-06-2012 06:19 AM

"Best" is relative to what you are doing. They can be quite small. The best way to find out is to create your target system and measure it.

One "best" is the initrd itself...

GazL 12-06-2012 07:04 AM

The whole point of LVM is to allow you to dynamically manage storage space as and when you need it. Only allocate what you estimate you're likely to need in the short-term and then leave the rest of the volume group as freespace. Should you need to increase any of the logical volumes at a later date you will find it relatively trivial and non-destructive. Don't try and run things too tight though, always allocate enough to cater for a reasonable amount of growth.


All times are GMT -5. The time now is 10:59 PM.