Re: [gentoo-user] Re: USE flag 'split-usr' is now global
On Wednesday, 7 August 2019 01:31:03 BST Rich Freeman wrote: > On Tue, Aug 6, 2019 at 7:41 PM Grant Taylor > > Sadly, I think people have thrust additional (IMHO) largely unnecessary > > complexity into the init process just to be able to support more exotic > > installations. I may be wrong but I thought the udev-usr-initrd complexity was deemed a necessity/ when bluetooth input and audio devices became more widespread. The fact systemd gradually mushroomed to take over the OS is another more loosely related story. > > Then, they have said "We want to be consistent in how we > > boot, so we need to use this more complex thing everywhere." To which, > > many greybeards have responded "I don't need nor want that on my simple > > server." This is the main rub of these architectural /solutions/ being pushed onto the wider community by what amounted to corporate lobbyists, for /problems/ many of us never had. > Initramfs is popular because it is way more flexible: > > 1. You can build a fully modular kernel so that you can use the same > kernel on every system but not be loading countless drivers for > hardware most systems don't use, while still being certain of being > able to boot any particular system. Unless you have no use for this. Just as many *Gentoo* users do not need their kernel image blessed by Microsoft, RHL shims and what not. > 2. You have more access to labels/uuids/etc for finding the root > filesystem so that when one of your hard drive fails the kernel > doesn't just dumbly use the next one in sequence, assuming they're > even always identified in the same order. I may be missing something here ... but I think this is not related to the use of an initrd. You probably won't even need a separate bloat-loader like grub2 for this, at least not on UEFI systems. Just add the root PARTUUID on your kernel line, inside the kernel. > 3. You can use "exotic" installations like iscsi and so on, which > seems pretty useful in an enterprise setting. > > > If you /actually/ /need/ a micro installation to make your main > > installation available, then go for it. But if you don't /actually/ > > /need/ a micro installation, well Occam's Razor / Parsimony. I have not performed sociological research to confirm this, but I'd say to those of us identifying with the above statement Gentoo is a good fit. For those in an enterprise setting, there are many other cookie-cutter corporate solutions applicable. > Except then you're tailoring your bootloader to individual systems. Yes, I don't *have* to use Gentoo on a large server farm, put a SLA in place linked to contractual payment thresholds, hack my own monitoring system and get 3 layers of insurance signed off. Tailoring my bootloader(s) is something I do in my home-office environment, including 3 servers. > Most sysadmins will prefer the Ubuntu/RHEL/etc approach where the same > kernel/bootloader/etc works everywhere, vs tailoring their boot > process to every individual host. Yes in (large) corporate deployments. Some of them on Azure too. > > > They're a really elegant solution to the problem. > > > > I wouldn't use the words "elegant" or "solution". "kludge" comes to mind. > > What could be more elegant? It minimizes the complexity of the > kernel, which is why Linus generally prohibits the kernel from having > any more advanced root mounting logic, and why pretty much every Linux > system out there uses one. I think the whole issue is a difference in use cases and where corporate money has been used to provide a narrowly focused solution to address corporate requirements, without particular attention/interest/care to what are statistically edge use cases. Such edge use cases, e.g. separate /usr, no initrd or kernel images signed by Microsoft, different choice of bootloaders, etc. have been more concentrated on Gentoo than the one-size-fits-all binary distros. RHL calls these "bespoke" deployments. Yet when changes in udev brought about the necessity of an initrd in order to keep running a separate / usr fs, I recall quite a number of gentoo user voices in this M/L alone objecting to the changes. What is an edge use case for Fedora, is/was not so much of an edge use case in Gentoo. Gentoo did not *have* to follow upstream changes, but yet again this could probably bring its ultimate stagnation/demise as devs would be spread too thin to keep developing Gentoo in a deviating path from the rest of the Linux trajectory. Having used and still using other binary distros I'm grateful Gentoo's still here, but would really prefer it did not bend itself out of shape to accommodate solutions to problems I and others do not have, or when we do we may not even use Gentoo to solve them. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: USE flag 'split-usr' is now global
On Mon, 5 Aug 2019 20:37:44 -0600, Grant Taylor wrote: > Actually, the quote in the first forum post you linked to has the > following: > > /sbin->usr/bin > /usr/sbin->bin > > That takes four directories (/bin, /sbin, /usr/bin, /usr/sbin) and > combines them into two (/sbin & /usr/bin and /bin & /usr/sbin) but it > also crosses bin & sbin as well as going opposite directions with the > links. — Yuck!!! Actually, it combines them all into one. The second link is to bin, not /bin. It's a relative link from /usr/sbin so this would put everything in /usr/bin. -- -- Neil Bothwick Exercise daily. Eat wisely. Die anyway. pgplegyUbUoHb.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: USE flag 'split-usr' is now global
On Wednesday, 7 August 2019 11:48:09 BST Neil Bothwick wrote: > On Mon, 5 Aug 2019 20:37:44 -0600, Grant Taylor wrote: > > Actually, the quote in the first forum post you linked to has the > > following: > > > > /sbin->usr/bin > > /usr/sbin->bin > > > > That takes four directories (/bin, /sbin, /usr/bin, /usr/sbin) and > > combines them into two (/sbin & /usr/bin and /bin & /usr/sbin) but it > > also crosses bin & sbin as well as going opposite directions with the > > links. — Yuck!!! > > Actually, it combines them all into one. The second link is to bin, not > /bin. It's a relative link from /usr/sbin so this would put everything in > /usr/bin. Yep! It sounds like an amazing idea! I vote we rename it $WINDOWS/ and see how fast someone can spin an image on Azure. :p -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: USE flag 'split-usr' is now global
On Wed, 07 Aug 2019 11:58:52 +0100, Mick wrote: > > Actually, it combines them all into one. The second link is to bin, > > not /bin. It's a relative link from /usr/sbin so this would put > > everything in /usr/bin. > > Yep! It sounds like an amazing idea! I vote we rename it $WINDOWS/ As opposed to splitting binaries across four directories based on arbitrary decisions made in the last century? :P -- Neil Bothwick DOS never says "EXCELLENT command or filename"... pgpyjmOi9g8f7.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: USE flag 'split-usr' is now global
On Wednesday, 7 August 2019 12:48:08 BST Neil Bothwick wrote: > On Wed, 07 Aug 2019 11:58:52 +0100, Mick wrote: > > > Actually, it combines them all into one. The second link is to bin, > > > not /bin. It's a relative link from /usr/sbin so this would put > > > everything in /usr/bin. > > > > Yep! It sounds like an amazing idea! I vote we rename it $WINDOWS/ > > As opposed to splitting binaries across four directories based on > arbitrary decisions made in the last century? :P LOL! You're missing the most important part: across different fs and partition layouts. Look, the pyramids were built before the last century, but that doesn't mean we should try to balance them upside down if they work fine as they are. Clearly different use cases have different requirements and correspondingly different optimal solutions. Can I please keep my bin/sbin directories separate and ditto for /usr and its subbies? :-) -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: USE flag 'split-usr' is now global
On 8/6/19 6:31 PM, Rich Freeman wrote: So, an initramfs doesn't actually have to do ANY of those things, though typically it does. I agree that most systems don't /need/ an initramfs / initrd to do that for them. IMHO /most/ systems should be able to do that for themselves. Nothing prevents an initramfs from booting an alternate kernel actually, though if it does it will need its own root filesystem initialized one way or another (which could be an initramfs). Agreed. Though I think that's rare enough that I chose to ignore it for the last email. Linux bootstrapping linux is basically the whole premise behind coreboot. Sure. But coreboot is not a boot loader or a typical OS. coreboot falls into the "firmware" family. Sure, but you don't need it ALL OVER YOUR FILESYSTEM. I'd be willing to bet that 75% of what's contained in an initramfs / initrd is already on the root file system. Especially if the initramfs / initrd is tweaked to the local system. Taking a quick look at the default initrd of an Ubuntu 16.04 LTS, just about everything I see in the following output exists on the system. /boot/initrd.img-4.4.0-87-generic has 1908 items in it. 129 of them aren't already on the installed system. Consisting of: 51 /scripts Probably initrd specific 61 /bin May be in /sbin /usr/bin /usr/sbin on the local system. 6 /conf Probably initrd specific 5 /etc 2 /lib 4 misc Digging further, 29 of the 61 for /bin are in /usr/bin. 12 are in /sbin. That's 88 out of 1908 files in the /boot/initrd.img-4.4.0-87-generic file that aren't already all over your file system. Some of the proposed solutions in this thread involved sticking stuff in /bin and so on. An initramfs is nicely bundled up in a single file. So, you're saving 88 files (out of 1908) and storing 1820 additional copies of files that exist in a container that's not easy to work with. Why‽ Absolutely true, which means it won't interfere with the main system, as opposed to sticking it in /bin or somewhere where it might. How do the files that are needed for the system to operate, being placed where they need to be, interfere with the main system? Such as? Allow me to rephrase / clarify slightly. There have been many things that I've wanted to do in the past 20 yeras that the initramfs / initrd from the vendor did not support or was not flexible enough to do. · Not support root in LVM. · Not support root on LUKS. · Not support iSCSI disks. · Not support root on multi-path. · Not supporting the file system (tools). · Not support the RAID that (tools). · Not support ZFS. · Not support root on NFS. These are just the some of the things that I've wanted to do over the years that the initramfs / initrd as provided by the distro did not support. I have routinely found initramfs / initrd limiting. It is a linux userspace. It can literally do anything. Yes, /conceptually/ it's Linux (userspace) can do anything that Linux can do. /Practically/ it can only do the things that the distro envisioned support for and included in their initramfs / initrd management system. You don't need to use dracut (et al) to have an initramfs. (See above.) In fact, you could create your super root filesystem that does all the fancy stuff you claim you can't do with an initramfs, Sure. I did. (Time and time again) it was the machine's root file system doing exactly what I wanted it to do. then create a cpio archive of that root filesystem, and now you have an initramfs which does the job. Why would I want to copy / permute something that's already working to add as an additional layer, which I don't need, complicating the overall process‽ Sure, but only if the kernel can find that disk without any userspace code. There's a reason I said "if". The extremely large majority of the systems that I've administered over the last 20 years could do that. What if that disk is on the other side of an ssh tunnel? That would be a case where you would actually /need/ an initramfs / initrd. I'd like to hear tell of someone actually using a root disk that is accessed through an ssh tunnel. Short of that, I'm going to consider it a hypothetical. If you know the commands to do something, why would you have to wait for somebody else to implement them? Because I have hundreds of machines that need to be supported by junior admins and sticking within the confines of what the distro vendor supports is a good idea. Or more simply, sticking within distro vendor's support period. Actually, for most of these the initramfs is the starting root filesystem (just about all linux server installs use one). Remember, an initramfs / initrd is (or gets extracted to) a directory structure. Just about all of the servers and workstations (mid five digits worth) that I've administered over the years end up with a SCSI (SATA / SAS) disk off of a controller with the driver in kernel
