Re: [DNG] Merged usr consequences [Was: Upgrade problem]
Quoting Steve Litt (sl...@troubleshooters.com): > And about the recompiling the kernel on each update if you want no > initramfs: I wonder how intentional that extreme inconvenience is. It's not _that_ inconvenient. Once you craft a suitable .config for your use-case, it's just a small wait to compile and make/install debs. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Merged usr consequences [Was: Upgrade problem]
On Wed, Jul 08, 2020 at 09:01:14PM -0700, Ian Zimmerman wrote: > On 2020-07-07 12:20, Steve Litt wrote: > > > You need certain executables, pre-mount, before a separate /usr can be > > mounted. These went in /sbin, which is on the root and always > > available. If you could mount the root partition, you could proceed. > > > > But now, if you mount /usr somewhere off the root, and simply have > > /sbin symlink to it, those executables aren't available right away. > > Imagine if you need the mount executable to mount /usr, but the mount > > executable *is* on /usr. Buried shovel. The only way around it is to > > do the mounts in initramfs. > > Of course I know all of this. And I guess strictly speaking it *is* an > answer to my question: if you had this setup and suddenly, without > notice, you got switched to a "merged" world, you'd be hosed until you > built an initramfs. > > But that is not how in fact it happens: you have plenty of notice, and > plenty of time to change to a scheme with /usr within the root > filesystem. And then you don't need an initramfs again, at least not for > the above reason. > > So maybe the real question is, in the merged world, do you have a reason > to insist on /usr being a mount point, other than tradition? I know that > people used to do rescue tasks via a single-user boot with only the > rootfs mounted, but for a long time now it is far easier to do such > things by booting into some kind of "live" system on a USB stick. One > can make the live system minimal if so inclined, and in fact the minimal > Devuan live system is just about perfect for this purpose. I had to demerge my /usr partition when the contents of my root partition became too large for space available on its partition and neighbouring partitions made it difficult to enlarge it. I expect other admins have other reasons. -- hendrik > > -- > Ian > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Merged usr consequences [Was: Upgrade problem]
On Wed, 8 Jul 2020 21:01:14 -0700 Ian Zimmerman wrote: > So maybe the real question is, in the merged world, do you have a > reason to insist on /usr being a mount point, other than tradition? Me personally? No. But there are a million different users and admins with a million different priorities, so I can see where some of them might mount /usr. Just speaking for myself, my root partition is an SSD, and it contains /usr and /lib etc. The stuff I mount is /home and some other data directories. This works out extremely well for me, giving me lightning fast /usr combined with huge data partitions. But I've talked to people who wanted their /etc to be an nfs mount, and they gave me a pretty good reason. SteveT Steve Litt May 2020 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Merged usr consequences [Was: Upgrade problem]
On Wed, 8 Jul 2020 11:49:40 +0200 Didier Kryn wrote: > The main reason for initramfs is, IMHO, for distros to provide > disk drivers and filesystems in the form of modules present in the > initramfs. They disapear after pivot-root so that only the necessary > ones remain in memory. > > If you don't want an initramfs, then the drivers and filesystems > necessary to mount your root partition must be statically linked in > the kernel. You can recompile the kernel fot that, but you'll have to > do it for every upgrade, and you will need to modify the init > sequence because Debian has put some initialisation stuff the > initramfs phase. If one wants an exotic disk setup, of course they need an initramfs. But the least that could be done is to build ext4 support statically into the kernel. I bet half the users do ext4 without LVM or encryption. I don't know how big the necessary LVM and encryption modules are, but if they're tiny, why not put them in the kernel too. Initramfs' aren't as harmless as everyone thinks. They're a black box bitch to troubleshoot. Systemd crowd is bragging that they have tools to debug initramfs. They also brag that systemd software is now *inside* the initramfs. Imagine what a world we'd have if the systemd cabal used their millions in funding to take over all the initramfs makers the way they took over udev. Initramfs is another moving part, and if you've ever looked inside one, a major moving part that does a lot more than allow disk mounting. And it's a black box. For those with exotic setups it will always be necessary, but compiling ext4 into the kernel, like we always used to, would get rid of a lot of peoples' need for initramfs. And about the recompiling the kernel on each update if you want no initramfs: I wonder how intentional that extreme inconvenience is. SteveT Steve Litt May 2020 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Merged usr consequences [Was: Upgrade problem]
On 2020-07-07 12:20, Steve Litt wrote: > You need certain executables, pre-mount, before a separate /usr can be > mounted. These went in /sbin, which is on the root and always > available. If you could mount the root partition, you could proceed. > > But now, if you mount /usr somewhere off the root, and simply have > /sbin symlink to it, those executables aren't available right away. > Imagine if you need the mount executable to mount /usr, but the mount > executable *is* on /usr. Buried shovel. The only way around it is to > do the mounts in initramfs. Of course I know all of this. And I guess strictly speaking it *is* an answer to my question: if you had this setup and suddenly, without notice, you got switched to a "merged" world, you'd be hosed until you built an initramfs. But that is not how in fact it happens: you have plenty of notice, and plenty of time to change to a scheme with /usr within the root filesystem. And then you don't need an initramfs again, at least not for the above reason. So maybe the real question is, in the merged world, do you have a reason to insist on /usr being a mount point, other than tradition? I know that people used to do rescue tasks via a single-user boot with only the rootfs mounted, but for a long time now it is far easier to do such things by booting into some kind of "live" system on a USB stick. One can make the live system minimal if so inclined, and in fact the minimal Devuan live system is just about perfect for this purpose. -- Ian ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Merged usr consequences [Was: Upgrade problem]
Le 07/07/2020 à 18:20, Steve Litt a écrit : > On Tue, 7 Jul 2020 08:41:31 -0700 > Ian Zimmerman wrote: > >> On 2020-07-07 11:26, Steve Litt wrote: >> >>> Void Linux also symlinks all the various *bin directories together, >>> even though it's a runit distro. My objection is this merge forces >>> you to have an initramfs. >> This doesn't sound right, can you explain why you need an initramfs >> with merged /usr if you didn't need it before? >> >> I have a vague recollection of discussing this topic long before, >> maybe with you; sorry if so. >> > You need certain executables, pre-mount, before a separate /usr can be > mounted. These went in /sbin, which is on the root and always > available. If you could mount the root partition, you could proceed. > > But now, if you mount /usr somewhere off the root, and simply have > /sbin symlink to it, those executables aren't available right away. > Imagine if you need the mount executable to mount /usr, but the mount > executable *is* on /usr. Buried shovel. The only way around it is to do > the mounts in initramfs. > Ah we had this discussion years ago! There's not much motivation to put binaries which were traditionnaly under /usr elsewhere than in the root partition nowadays. The main reason for initramfs is, IMHO, for distros to provide disk drivers and filesystems in the form of modules present in the initramfs. They disapear after pivot-root so that only the necessary ones remain in memory. If you don't want an initramfs, then the drivers and filesystems necessary to mount your root partition must be statically linked in the kernel. You can recompile the kernel fot that, but you'll have to do it for every upgrade, and you will need to modify the init sequence because Debian has put some initialisation stuff the initramfs phase. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Merged usr consequences [Was: Upgrade problem]
On Tue, 7 Jul 2020 08:41:31 -0700 Ian Zimmerman wrote: > On 2020-07-07 11:26, Steve Litt wrote: > > > Void Linux also symlinks all the various *bin directories together, > > even though it's a runit distro. My objection is this merge forces > > you to have an initramfs. > > This doesn't sound right, can you explain why you need an initramfs > with merged /usr if you didn't need it before? > > I have a vague recollection of discussing this topic long before, > maybe with you; sorry if so. > You need certain executables, pre-mount, before a separate /usr can be mounted. These went in /sbin, which is on the root and always available. If you could mount the root partition, you could proceed. But now, if you mount /usr somewhere off the root, and simply have /sbin symlink to it, those executables aren't available right away. Imagine if you need the mount executable to mount /usr, but the mount executable *is* on /usr. Buried shovel. The only way around it is to do the mounts in initramfs. SteveT Steve Litt May 2020 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Merged usr consequences [Was: Upgrade problem]
On 2020-07-07 11:26, Steve Litt wrote: > Void Linux also symlinks all the various *bin directories together, > even though it's a runit distro. My objection is this merge forces you > to have an initramfs. This doesn't sound right, can you explain why you need an initramfs with merged /usr if you didn't need it before? I have a vague recollection of discussing this topic long before, maybe with you; sorry if so. -- Ian ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
