> Sent: Wednesday, November 06, 2019 at 3:30 AM
> From: "Christopher Gregory via blfs-support"
> <[email protected]>
> To: [email protected]
> Cc: "Christopher Gregory" <[email protected]>
> Subject: Re: [blfs-support] Best approach for lvm2
>
>
>
> > Sent: Wednesday, November 06, 2019 at 2:54 AM
> > From: "Pierre Labastie via blfs-support"
> > <[email protected]>
> > To: [email protected]
> > Cc: "Pierre Labastie" <[email protected]>
> > Subject: Re: [blfs-support] Best approach for lvm2
> >
> > Le 05/11/2019 à 06:00, Christopher Gregory via blfs-support a écrit :
> > >
> > >
> > >> Sent: Sunday, October 27, 2019 at 3:20 AM
> > >> From: "Pierre Labastie via blfs-support"
> > >> <[email protected]>
> > >> To: [email protected]
> > >> Cc: "Pierre Labastie" <[email protected]>
> > >> Subject: Re: [blfs-support] Best approach for lvm2
> > >>
> > >> On 26/10/2019 14:46, Christopher Gregory via blfs-support wrote:
> > >>> Hello,
> > >>>
> > >>> I am about to install another version of lfs/blfs on a new ssd hard
> > >>> drive, and I am wanting to move all my drives to using lvm2. What I
> > >>> need to know is the best approach for this. I understand that it needs
> > >>> to happen at the partitioning stage of installing lfs.
> > >>>
> > >>> I was wondering if I used a distro such as fedora from a live dvd if I
> > >>> would be able to achieve this on the new hard drive and then be able to
> > >>> use jhalf as normal to install lfs. I was hoping to avoid having to
> > >>> have a seperate /boot and having to use an initramfs image if at all
> > >>> possible, but do not know if this would be achieveable or not.
> > >>>
> > >>> I am wanting to continue using guid partitions as well. I have not
> > >>> seen antyhing on the lists that show that anyone has been able to
> > >>> install lfs on an lvm2 controlled drive.
> > >>>
> > >>
> > >> Maybe I've not communicated much on it, by I have done that :) here is
> > >> the
> > >> partition layout (you can have something simpler, but I need Windows [1]
> > >> for
> > >> my job). Note that there is nothing special with dos partitioning, and
> > >> certainly gpt is OK:
> > >>
> > >> Device Boot Start End Sectors Size Id Type
> > >> /dev/sda1 * 2048 2101247 2099200 1G 7 HPFS/NTFS/exFAT
> > >> /dev/sda2 2101248 197413747 195312500 93.1G 7 HPFS/NTFS/exFAT
> > >> /dev/sda3 197414910 620937215 423522306 202G 5 Extended
> > >> /dev/sda4 620937216 625131519 4194304 2G b W95 FAT32
> > >> /dev/sda5 197414912 620937215 423522304 202G 8e Linux LVM
> > >>
> > >> Now, the lvm layout is:
> > >> /dev/mapper/vg-debian64: 37.26 GiB
> > >> /dev/mapper/vg-swap: 7.46 GiB
> > >> /dev/mapper/vg-home: 37.26 GiB
> > >> /dev/mapper/vg-lfs: 60 GiB
> > >>
> > >> I first installed debian on /dev/mapper/vg-debian64, mounting
> > >> /dev/mapper/vg-home on /home. Actually, I used the partitioning tool
> > >> coming
> > >> with the debian installer to shrink the NTFS partition and create the lvm
> > >> setup. I installed grub onto the disk. Grub can perfectly well boot from
> > >> an
> > >> lvm partition.
> > >>
> > >> From debian, I mounted /dev/vg/lfs on /mnt/lfs, and installed lfs on it.
> > >> Then
> > >> I made an initramfs. The reason why it _is_ needed (no way without it,
> > >> unless
> > >> you have the root filesystem on a regular partition) is because the
> > >> kernel
> > >> does not know about lvm, so it needs some help to be able to mount an
> > >> lvm root
> > >> partition. The initramfs in the book works well for lvm.
> > >>
> > >> I created /boot/grub/grub.cfg on /dev/vg/lfs with
> > >>
> > >> # Begin /boot/grub/grub.cfg
> > >> set default=0
> > >> set timeout=5
> > >>
> > >> insmod ext2
> > >> insmod lvm
> > >> set root='lvm/vg/lfs'
> > >>
> > >> menuentry "GNU/Linux, Linux 5.3.6-lfs-SVN-20191017" {
> > >> linux /boot/vmlinuz-5.3.6-lfs-SVN-20191017 root=/dev/vg/lfs ro
> > >> quiet
> > >> initrd /boot/microcode.img /boot/initrd.img-no-kmods
> > >> }
> > >> ...
> > >>
> > >> Then I ran update-grub on debian. There is a small problem here:
> > >> update-grub
> > >> only copies the first initrd, so I had to manually add the second to
> > >> /boot/grub.gfg on /dev/vg/debian. Actually, It'd be better to merge both
> > >> initramfs.
> > >>
> > >> And that's it.
> > >>
> > >> Pierre
> > >> [1] I am not sure why Windows is using two small partitions + one big,
> > >> but the
> > >> computer came with that, and I just shrank the big partition to make
> > >> room for
> > >> linux.
> > >> --
> > >> http://lists.linuxfromscratch.org/listinfo/blfs-support
> > >> FAQ: http://www.linuxfromscratch.org/blfs/faq.html
> > >> Unsubscribe: See the above information page
> > >>
> > >
> > > Hello Pierre,
> > >
> > > I have finally got round to attempting this, and have spent a couple of
> > > days now trying to get it to work.
> > >
> > > I used Fedora 31 (as I am working with a developer to package his
> > > software in rpm format) to create the lvm and the volumes. This went
> > > well. I then used jhalfs to build the lfs system, and I got a completed
> > > install. I then went ahead and added the entries to grub, and then the
> > > true nightmare began. No matter what I put in the grub.cfg file it just
> > > refuses to find the kernel. I have generated the initrd.img-no-kmods
> > > using the script in the book. Using this script, it complains that there
> > > is a missing operand after tmp/filename/lib but proceeds and completes
> > > the image.
> > >
> > > I have no idea where you got the root=/dev/vg line from.
> > >
> > > With my installation, I have rootvg in /dev with the following: (this is
> > > on fedora 31)
> > >
> > > lrwxrwxrwx. 1 root root 7 Nov 5 17:17 home -> ../dm-4
> > > lrwxrwxrwx. 1 root root 7 Nov 5 17:17 opt -> ../dm-6
> > > lrwxrwxrwx. 1 root root 7 Nov 5 17:17 root -> ../dm-7
> > > lrwxrwxrwx. 1 root root 7 Nov 5 17:17 swap -> ../dm-3
> > > lrwxrwxrwx. 1 root root 7 Nov 5 17:17 tmp -> ../dm-5
> > >
> > >
> > > root [ /dev/rootvg ]# vgdisplay
> > > --- Volume group ---
> > > VG Name fedora_localhost-live
> > > System ID
> > > Format lvm2
> > > Metadata Areas 1
> > > Metadata Sequence No 5
> > > VG Access read/write
> > > VG Status resizable
> > > MAX LV 0
> > > Cur LV 3
> > > Open LV 3
> > > Max PV 0
> > > Cur PV 1
> > > Act PV 1
> > > VG Size <464.76 GiB
> > > PE Size 4.00 MiB
> > > Total PE 118978
> > > Alloc PE / Size 118978 / <464.76 GiB
> > > Free PE / Size 0 / 0
> > > VG UUID VbdXPM-nzJY-gQ1I-IbpW-N2NP-Ct5G-vKYL10
> > >
> > > --- Volume group ---
> > > VG Name rootvg
> > > System ID
> > > Format lvm2
> > > Metadata Areas 1
> > > Metadata Sequence No 6
> > > VG Access read/write
> > > VG Status resizable
> > > MAX LV 0
> > > Cur LV 5
> > > Open LV 0
> > > Max PV 0
> > > Cur PV 1
> > > Act PV 1
> > > VG Size <222.59 GiB
> > > PE Size 4.00 MiB
> > > Total PE 56983
> > > Alloc PE / Size 56983 / <222.59 GiB
> > > Free PE / Size 0 / 0
> > > VG UUID 7MAzgc-XlQZ-C53H-pKF8-ReV0-NaM2-ADSQQy
> > >
> > > It does not matter if I use root=(lvm/rootvg-root) or
> > > /dev/mapper/rootvg-root or any other varient, it complains that it can
> > > not find vmlinuz-5.3.6-lfs-20191101-systemd.
> >
> > Hmm, debian's "update-grub" finds the system on the lvm volume, but I am not
> > sure fedora works exactly the same as debian for that, so you may have to
> > try
> > something else...
> >
> > Concerning what you write, I am not sure which "root=" you are talking
> > about:
> > there are two places where "root=" is used, and they do not have the same
> > syntax:
> > - in "set root=". This is a grub instruction, and it uses grub's syntax for
> > files, that is, set root=(lvm/rootvg-root) (in your case). It indicates
> > where
> > to find linux and initrd.
> > - in the "linux ..." line, where it uses linux syntax, that is, "linux
> > /boot/vmlinuz-5.3.6-lfs-20191101-systemd root=/dev/rootvg/root <other
> > options>". Note that you can replace with root=/dev/mapper/rootvg-root on
> > _this_ line, not the grub one. Both /dev/mapper/* and /dev/rootvg/* are
> > symlinks created by udev while running the initrd.
> >
> > >
> > > I have even tried using UUID= and PARTUUID= with similar results.
> >
> > UUID may work for lvm2 (not tried), PARTUUID obviously doesn't, since a
> > logical volume is not a partition.
> >
> > >
> > > I have a seperate /boot partition outside of the lvm, and a bios_grub (as
> > > I am using guid partition) this is the way that Fedora sets things up, ie
> > > with a seperate /boot. Even with updating grub on fedora, it still will
> > > not boot. I have appended /boot to both the initrd file and the linux
> > > line.
> > >
> > > After I had completed the installation of lfs, I proceeded to login to
> > > the chroot and set the password for root, then I installed lvm2 and the
> > > script to make the initramfs along with the runtime required files. This
> > > is the stage that I am at now.
> > >
> > > I am at a loss as to what is going wrong here. Fedora 31 is installed on
> > > an external usb hard drive. I have three hard drives installed in my
> > > computer, two of which are ssd drives.
> >
> > To test that the initrd is OK, you may try to have the lfs kernel and initrd
> > in the separate /boot partition (then , when it works, move those to lfs
> > volume, see below):
> > - copy vmlinuz-5.3.6-lfs-20191101-systemd and initrd.img-no-kmods to this
> > partition
> > - edit grub/grub.cfg on this partition so that there is an entry for the lfs
> > system (it may have been created by "update-grub")
> > - check that the "set root=" line for this entry (it may be global or local
> > to
> > the entry) points to this partition
> > - the linux/initrd lines should read (you may add other options):
> > linux /vmlinuz-5.3.6-lfs-20191101-systemd root=/dev/rootvg/root ro
> > initrd /initrd.img-no-kmods
> >
> > If this boots:
> > - move back vmlinuz-5.3.6-lfs-20191101-systemd and initrd.img-no-kmods to
> > /mnt/lfs/boot
> > - edit the grub/grub.cfg file on the separate boot partition so that:
> > - the set root= line points to (lvm/rootvg-root)
> > - the linux/initrd lines point to /boot/vmlinuz* and /boot/initrd*
> >
> > HTH
> >
> > Pierre
> > --
> > http://lists.linuxfromscratch.org/listinfo/blfs-support
> > FAQ: http://www.linuxfromscratch.org/blfs/faq.html
> > Unsubscribe: See the above information page
> >
>
> Hello Pierre,
>
> I have now wiped all the other drives other than the external usb which
> fedora is on, and the internal ssd that has this new version of lfs on. I
> have tried having the lfs kernel and initrd on the /boot partition of the
> fedora drive, and that does not work either. This is how fedora adds the
> entry to grub.cfg:
>
> menuentry 'Linux From Scratch (20191025-systemd) (on
> /dev/mapper/rootvg-root)' --class linuxfromscratch --class gnu-linux --class
> gnu --class os $menuentry_id_option
> 'osprober-gnulinux-simple-4155330c-5db1-4113-834f-afefb2d2570e' {
> insmod part_gpt
> insmod ext2
> set root='hd3,gpt2'
> if [ x$feature_platform_search_hint = xy ]; then
> search --no-floppy --fs-uuid --set=root --hint-bios=hd3,gpt2
> --hint-efi=hd3,gpt2 --hint-baremetal=ahci3,gpt2
> 099738b6-ac51-455f-9d60-fac5d900ba8b
> else
> search --no-floppy --fs-uuid --set=root
> 099738b6-ac51-455f-9d60-fac5d900ba8b
> fi
> linux /vmlinuz-5.3.6-lfs-20191025-systemd root=/dev/dm-7
> initrd /initrd.img-no-kmods
>
> Regards,
>
> Christopher.
> --
> http://lists.linuxfromscratch.org/listinfo/blfs-support
> FAQ: http://www.linuxfromscratch.org/blfs/faq.html
> Unsubscribe: See the above information page
>
Hello Pierre,
Having this as the grub.cfg file results in it complaining that it cannot find
vmlinuz-5.3.6-lfs-20191025-systemd (it drops me to an shell in initrd)
# Begin /boot/grub/grub.cfg
set default=0
set timeout=5
insmod lvm
insmod insmod part_gpt
insmod ext2
set root=(lvm/rootvg-root)
menuentry "GNU/Linux, Linux 5.3.6-lfs-20191025-systemd" {
linux /boot/vmlinuz-5.3.6-lfs-20191025-systemd
root=/dev/mapper/rootvg-root ro
initrd /boot/initrd.img-no-kmods
}
Regards,
Christopher.
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
