On Tue, Jan 03, 2012 at 05:36:18PM -0500, Baho Utot wrote:
> On 01/03/2012 03:44 PM, Ren? GARCIA wrote:
> > Hi,
> >
> > I am using LFS 7.0 with LVM2/ext4 for all partitions excepted /boot
> > which is a primary partition using ext4.
> > I haven't followed the Bryan Kadzban hint.
> >
> > What I needed :
> > - LVM2 2.02.88
> > - device-mapper 1.02.28
> > - dracut-013
> > - some minor modifications in LFS init scripts (to properly remount
> > /dev/pty when initramfs already did it)
> >
> > In my configuration, /usr and / are on the same partition. It make
> > things much more easy when executing the first init scripts.
> >
> > My main grub entry is :
> >
> > menuentry "LFS7.0 on LVM2" {
> > insmod ext2
> > set root=(hd0,1)
> > linux /vmlinuz root=LABEL=root-fs ro
> > initrd /initramfs.img
> > }
> >
> > /boot is on the 1st primary partition of the first disk
> > vmlinuz and initramfs.img are symbolic links to kernel and initramfs
> > files in /boot
> >
> > initramfs is generated using dracut
> >
> > While installing I've been using a second hard drive for testing LVM2.
> > All volumes are using ext4 filesystem with labels to identify them.
> >
> > I labelled my root filesystem "root-fs". As it is part of a LVM2 group,
> > the generated dracut script will enable all LVM2 groups to find it. If
> > it's not part of a LVM2 group you can still add grub the option
> > rd_LVM_VG=yourVGname to the linux line to enable a specific LVM2 group
> > when in initramfs.
> >
> > I'm sorry but I don't have a step by step hint to give you. I needed
> > many reboots to manage LFS7 to run on LVM2.
> >
> > Regards,
> > Ren?
> >
> > Le 03/01/2012 21:50, Baho Utot a ?crit :
> >> Is the lvm hint by Bryan Kadzban still viable/relavent?It works with current kernels. (Well, as of 2.6.39 anyway. That's getting less and less "current" as time passes. :-( ) I have not had time to upgrade the kernel to see if it's still working though, and upgrading udev is always a hit-or-miss proposition due to its development practices (the developers think you should upgrade your kernel before udev, and they also lump the glibc kernel headers in with that; this is pretty much impossible in any running system though). I have also not tried to upgrade cryptsetup beyond 1.0.2 or so, or LVM beyond whatever version is in the current hint. I *have* had time to add a few things to the lfs-initramfs package, though I don't remember if I released a newer tarball or not. SVN is what I'm using on my own system (rootfs on LVM on dm-crypt, so everything except RAID). In somewhat more general terms: You definitely need some kind of initramfs to put your rootfs on LVM. Whether you use a prepackaged initramfs builder like dracut (those were always either too magical or too generic for me, or both, which is why I wrote my own), or the one referred to in the hint, or one you write yourself, doesn't really matter. > >> I would like to boot LFS installed to a lvm partition. > >> > >> I have a 2 TB drive that I use and it is currently booting Arch linux on > >> lvm. > >> I would like to convert to use LFS/BLFS. I would like to get away from > >> Arch > >> now because of the bloat and the crazy split packages. Just try to build > >> the "base packages". LFS/BLFS suits me just fine and I like the way it is > >> being developed. I am going to use LFS/BLFS with Trinity. > >> > >> I will need to boot into lfs install in a lvm partition. So any advice > >> will be > >> greatly apreciated. > >> > >> I could boot LFS on a regular partition and use lvm for everything else but > >> that doesn't really fit how I want to use linux. > >> > >> Thank you for all your hard work. > >> > > I will look at dracut thanks > > I may need help with the init scripts as that is not one of my good points. That's one of the reasons I really don't like many of the premade initramfs packages: they all assume you want a /dev from the initramfs to also be used by the final system. But that means you need all the user/group resolution handling to be up and running when the initramfs runs, and (especially for a NIS/YP/whatever system) that's not really always feasible. So the one that I built explicitly works with the standard LFS bootscripts; it kills off udevd, unmounts the tmpfs, etc., after the rootfs is mounted and before it hands off control to /sbin/init. Then the standard bootscripts can do their thing: remount /dev, retrigger all the events, use the standard user/group resolution, etc., etc. (You also don't need to copy every single udev rule, or udev helper script, into the initramfs. If they're missing, nothing cares, as long as they aren't needed to find the rootfs.) I find a compartmentalized setup works a *lot* better (where the bootscripts don't depend on any particular initramfs, and the initramfs doesn't do something that the bootscripts are required to fix later, either).
pgpGBcoP3YrFm.pgp
Description: PGP signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
