On 08/19/2013 03:37 PM, Alecks Gates wrote: > On Mon, Aug 19, 2013 at 9:30 AM, Alon Bar-Lev <alo...@gentoo.org> wrote: >> On Mon, Aug 19, 2013 at 5:20 PM, Alecks Gates <aleck...@gmail.com> wrote: >>> On Mon, Aug 19, 2013 at 8:26 AM, Tanstaafl <tansta...@libertytrek.org> >>> wrote: >>>> On 2013-08-18 10:55 PM, Canek Peláez Valdés <can...@gmail.com> wrote: >>>>> And, putting aside systemd and getting back on topic to the council's >>>>> decision of (eventually) not supporting separated /usr without an >>>>> initramfs; have you ever stopped to consider that, perhaps, that's the >>>>> best *technical* decision? (*gasp*) >>>> >>>> That is *not* the concern here, Canek, and that should be obvious from the >>>> comments here. >>>> >>>> Repeat: the primary concern is *not* about separate /usr without initramfs. >>>> >>>> The primary concern is that systemd will eventually be shoved down our >>>> throats whether we want it or not, and using eudev or mdev or *anything* >>>> other than systemd (ie OpenRC/eudev) will. >>>> >>> *snip* >>>>> When you have almost all distributions converging on that, and even >>>>> *the OpenRC maintainer* (which is the one pushing this, BTW, not the >>>>> systemd guys) supporting that decision, don't you think that perhaps, >>>>> just*perhaps*, everybody screaming about the sky falling (which, BTW, >>>>> >>>>> they are certainly noisy, but I really don't think are that many) are >>>>> overreacting and even (*gasp* again) wrong? >>>> >>>> Again, the main issue is not about separate /usr, so please stop trying to >>>> deflect the subject... >>>> >>> Isn't that what this thread is about? "Optional /usr merge in Gentoo" >>> >>> Can someone please explain to me what's so hard and/or complicated >>> about making an initramfs? At this point in time it's extremely >>> simple for me, but I only manage relatively simple systems (although >>> I'd like that to change soon). All I do is add one extra line (for >>> example - "dracut -H --kver=3.11.0-rc6") to my kernel install >>> procedure. >>> >>> Granted, the only reason I have an initramfs is for the plymouth >>> splash screen (other systems aren't desktops) -- but from everything I >>> can see it's not too complicated otherwise. >> Yeah... it is not complicated to but Windows as well, or IBM os-390!!! >> >> You use a tool that hides the initramfs building, and you are amazed >> it is simple? > Dracut isn't *hiding* anything from me, I just don't need anything > more complicated -- who said I'm amazed? > >> The files within the initramfs generation tool are compiled using >> different tool than portage, they are not updated when distribution is >> updated, and they are not even at same version within portage tree. > Why does this matter? Are there some huge security vulnerabilities > I'm unaware of?
If you have one system to keep on top of, it's simple to make sure to update initramfs after a kernel update If you have many systems, and they are remote, it becomes trickier. A borked kernel update remotely can be easily resolved by panic=1 and having a grub failsafe boot option. It doesn't even need a kernel update. I'm a big fan of LVM, but i found that in the upgrade to sys-fs/lvm2-2.02.99-r2 my usb devices were coming up as invalid pvs on LVM start in the default runlevel, after the initramfs. No biggie locally, and only backups were on those devices. but remotely and at system updating times (silly oclock) it's easy to miss a simple thing like initrd update. worse if what is borked is relied upon -- consider a system that only boots 75% -- it doesn't fail but it doesn't start all services in the default runlevel because the initrd is not updated, or is updated incorrectly. being locked out of boxes remotely at silly oclock sucks, and we don't always have the benefit of OOB management, IPVS or DRBD to not worry about it until after sleep has relaxed the mind. this has always been one of the biggest pros of gentoo for me - where everything is a stream of data even the OS is like a slipstream. updating many gentoos however can be a big issue and I do try to keep similar boxes similar hardware because of it -- allowing me to test updates before they get rolled out, and also allows me to add in crucial use flags (dlz, openssl) when they suddenly become required; great to figure out on a test machine first and then roll out x30 rather than figure out 30times over! Because of LVM/LUKS i have used initrd for a long time but i can understand why the migration sucks - first install and testing and then maintenance thereafter. Going up to udev200 was scary enough. . . scary because of that remote system status on NIC naming! Equally we don't always have the benefit of a secondary identical monster server to test new configurations on. i almost would like to request tighter integration between portage/kernel building/initrd but i'm not convinced the ubuntu way is the correct way as that leads to customisations breaking systems, and gentoo is all about customisation, making the OS fit the hardware. > >> It may be acceptable for you... but do not expect everyone will accept >> your setup. > Don't mind me, I'm just looking for the logic. Feel free to explain it to me. > >> Regards, >> Alon >>
