On 06/09/2019 18:18, Pierre Labastie via blfs-dev wrote: > On 06/09/2019 17:25, Douglas R. Reno via blfs-dev wrote: >> >> >> On Fri, Sep 6, 2019, 10:09 AM Bruce Dubbs via blfs-dev >> <[email protected] >> <mailto:[email protected]>> wrote: >> >> On 9/6/19 8:36 AM, Pierre Labastie via blfs-dev wrote: >> > Hi, >> > >> > I have a laptop, which came with an OS from Microsoft on it, and where >> I >> have >> > installed Debian . >> > >> > Because I wanted to preserve the Microsoft OS, debian created only one >> lvm >> > physical volume for installing itself, with 2 logical volumes, one for >> swap >> > and the other for itself. I later shrunk the debian logical volume to >> create a >> > third one for installing lfs. Now I have a working lfs, thanks to the >> "About >> > initramfs" page, with lxde. But I am stuck to swap on lvm. >> > >> > Suspend to disk seems to work well, but I cannot resume from the disk >> image, >> > because the kernel cannot resume from an lvm volume, and initramfs >> lacks >> that >> > possibility. So I plan to add the missing bits to init.in >> <http://init.in>. >> > >> > Now my question is: do you think it is interesting to add this >> possibility >> > into the book? Note that I do not anticipate it to be a big addition... >> >> I really don't think it should go into the book. LVM is really not a >> great choice for partitions when you only have one disk drive anyway. >> Actually I don't think LVM is ever a good partition type for /. >> >> -- Bruce >> >> >> I have a different opinion here based on prior experience >> >> When I used OpenSUSE regularly, it defaulted on using BTRFS and LVM2 >> irregardless of your partitioning scheme already in place. If you change the >> partition table too much ahead or behind the Windows partition, Windows will >> attempt to readd the HDD (and this happens more on 10 than it does any other >> version) and will lose track of the UUID of the C drive/partition, due to the >> design of its kernel. I've encountered this before, and you either have to >> reinstall the OS or find some obscure Registry key and get the new UUID of >> what it thinks the C drive is in order to set it correctly. Debian 10 Buster >> sort of has this same scheme, set it up as LVM2 no matter what the size. To >> be >> fair, Fedora does that, sets it to btrfs, *and* encrypts your root partition >> by default and /home. I have no clue what Ubuntu, RHEL, Void, Arch, Gentoo, >> or >> CentOS do though, haven't used those in a long time. >> >> I think it should be added because these kinds of situations are becoming >> more >> common (and sometimes difficult to override). The last time I used OpenSUSE >> Tumbleweed (2017-ish?), it gave me a very difficult time when I tried to >> change it, even going as far as to ask me if I was sure 4 or 5 times. Most >> people (at least my age) would let it go at that point. >> >> What needs to be changed exactly?
Actually, our initramfs does not allow resuming from disk at all (nothing to do with lvm): if for whatever reason (using raid, using UUID/LABEL, using encryption), this initramfs is used, then any resume= on the kernel command line is ignored... So I really think that this initramfs should acknowledge resume= on the kernel command line, and use it (possibly also accounting for the "noresume" switch). Note that resuming from disk is more interesting for laptops: systemd (or elogind) allows configuring for saving the state of the machine and halting, in case of low battery. And retrieveing the saved state needs being able to resume from disk... In any case, whan using elogind, /lib/elogind should be copied to the initramfs, so the page needs to be changed anyway... Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
