Re: Re: support for merged /usr in Debian
On Sun, Jan 10, 2016 at 10:56:21AM +0100, Eric Valette wrote: > Your example comparing systemd debate vs abortion debate is definitively > insane snip > ...(at least here in France). Russ specifically said "in US politics". His analogy was very clearly bracketed to the situation in the US, *not* in France. Ipso Facto, you have misunderstood his analogy. -- Jonathan Dowland Please do not CC me, I am subscribed to the list.
Re: Re: support for merged /usr in Debian
Russ Allbery writes: For one specific example, it's become quite clear over the past year that systemd has achieved the same status as abortion debates in US politics. Not only is it clear that we will *never* stop arguing about systemd, opposition to or support of systemd has turned into a tribal identity marker for at least some people. Your example comparing systemd debate vs abortion debate is definitively insane : abortion is a philosophical debate that mainly roots whether you believe or not in god, which is not something that can be argued on its technical merits, or the fundamental compatibility problem it causes. The only point were your comparison makes sense is that communication by both opponent and proponent could have been better and less hostile (at least here in France). Part of what ian said (copied below for ref), that has not been done with systemd is definitively the root cause of all the systemd debate I think that people who want to change Debian should take care to: - Communicate respectfully; - Ensure technical interoperability between different approaches and different tools; - Carefully plan necessary transitions; - Approach change in a consensual manner; - Particularly, avoid hostile acts like publicly declaring other people's code or configurations dead or unsupported. I have been criticizing systemd introduction in this newgroup/mailing lists because, at the beginning, it did break nearly all my systems, whereas it should not had: 1) when you find /proc/config.gz and you know that some feature are required for systemd, you could check before installing it and avoid removing sysv init system even if mots pelple do use distribution kernel (without /proc/config.gz you can write program that will check features via system calls). 2) as it started to depend on libraries located in /usr, it did break on my system with no initrd, and different / and /usr and it did break my system at least 5 or six times before stabilizing. I suggested to add a script to make sure sysdemd binary does not link with /usr located libraries to detect this before crashing people installations, So this are clear example were simple technique could have been used to avoid breaking installed systems. It does cost a bit more effort but would have generated far less heated debate and meybe even les work at the end. Now I do see benefits of systemd (boot faster) but the lack of easiness to define user modifiable parts (/etc/defaut/pkg) and things that are better left as the maintainer wants is still complicated and if you need to directly change default /lib/systemd/system/pkg.service its overridden during upgrade... I have nas machines running debian without screen, video output, that have been installed via network and do not have easy way to repartition, not access to bootlodaer to install a different initrd, nor to repair other than soldering a serial line, so saying you should merge / and /usr or it may break and you will be on your own makes me less than happy. I thinks you can understand that. I'll say it again: enthusiasm is fragile. If we slap down excited people every time they make intemperate comments out of enthusiasm, we lose SO MUCH energy. And I don't think we can afford to lose that much energy from the project. Agreed. But making transition smooth, may not cost that much and could preserve motivated people against hostile reactions if their changes breaks people habits/systems. So having a policy like Ian did propose for making fundamental changes may at the end avoid loosing energy.. --eric
Re: Re: support for merged /usr in Debian
On Sun, Jan 10, 2016 at 10:56:21AM +0100, Eric Valette wrote: > Russ Allbery writes: > > >For one specific example, it's become quite clear over the past year that > >systemd has achieved the same status as abortion debates in US politics. > >Not only is it clear that we will *never* stop arguing about systemd, > >opposition to or support of systemd has turned into a tribal identity > >marker for at least some people. > > Your example comparing systemd debate vs abortion debate is definitively > insane : abortion is a philosophical debate that mainly roots whether you Unbelievable!! What part don't you understand? He says it's "achieved the same status", even I, understood at least that much. -- "If you're not careful, the newspapers will have you hating the people who are being oppressed, and loving the people who are doing the oppressing." --- Malcolm X
Re: Re: support for merged /usr in Debian
I agree, one is about a person's right to not be forced to have something that they aren't able to support and will cause their life difficulty, the other is about abortion > Your example comparing systemd debate vs abortion debate is definitively insane : abortion is a philosophical debate that mainly roots whether you believe or not in god, which is not something that can be argued on its technical merits, or the fundamental compatibility problem it causes. The only point were your comparison makes sense is that communication by both opponent and proponent could have been better and less hostile (at least here in France). >
Re: Re: Re: support for merged /usr in Debian
On Sun, Jan 10, 2016 at 10:56:21AM +0100, Eric Valette wrote: Russ Allbery writes: >For one specific example, it's become quite clear over the past year that >systemd has achieved the same status as abortion debates in US politics. >Not only is it clear that we will *never* stop arguing about systemd, >opposition to or support of systemd has turned into a tribal identity >marker for at least some people. Your example comparing systemd debate vs abortion debate is definitively insane : abortion is a philosophical debate that mainly roots whether you Unbelievable!! What part don't you understand? He says it's "achieved the same status", even I, understood at least that much. "Achieved the same status" BUT for totally different fundamental reasons so the reasoning is totally void. The analogy by itself, I let him the responsibility of comparing technical decisions to a matter of life or death -- eric
Re: Re: support for merged /usr in Debian
On Sun, Jan 03, 2016 at 11:55:08PM +0100, Eric Valette wrote: > Red hat is mainly for servers nowadays with paying support. As with many Red Hat features, it was first trialled and proven in Fedora, which is very much used on Desktops: https://fedoraproject.org/wiki/Features/UsrMove
Re: Re: support for merged /usr in Debian
Remember that / and /usr don't have to reside on the same partition with the usrmerge proposal: they only have to be both available post-initramfs. The initramfs already takes care to mount /usr (for the systemd case as initscripts needs updates for sysvinit as was said elsewhere). So no repartitioning should be required on upgrades. As explained elsewhere in this thread, using initramfs is still not mandatory in debian and I personally have more managed debian system installed without it than with it. And the fact that /usr break may require user interaction is not really handled by initramfs and may cause dangling sysmlink in / -- eric
Re: Re: support for merged /usr in Debian
Remember that / and /usr don't have to reside on the same partition with the usrmerge proposal: they only have to be both available post-initramfs. The initramfs already takes care to mount /usr (for the systemd case as initscripts needs updates for sysvinit as was said elsewhere). So no repartitioning should be required on upgrades. As explained elsewhere in this thread, using initramfs is still not mandatory in debian and I personally have more managed debian system installed without it than with it. And the fact that /usr break may require user interaction is not really handled by initramfsand may cause dangling sysmlink in / -- eric
Re: Re: support for merged /usr in Debian
On Sun, 2016-01-03 at 21:34 +0100, Eric Valette wrote: > > > > This is not true: you just need to use an initramfs. > > > Ok, so it should warn that this setup will soon require to use an > > > initramfs. > > It is the Debian default, there is no need to do this. > > Being debian installer default does not mean any debian users > 1) really has any benefit of using it as explained, > 2) nor use it after initial installation, An initramfs is mandatory if using the standard kernel packages, as I think most people do. > Others have expressed better than I did that initramfs by itself is evil > and just does what / was supposed to do originally: [...] 'Evil', really? Sure, it takes more time to load and more time to run. The implementation isn't exactly pretty. But many systems do require it because the kernel doesn't have the code to set up every different kind of device that the root filesystem might live on. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Re: Re: support for merged /usr in Debian
I'm confused why you think anything will break. There would obviously be symlinks, so anything that's currently in /bin will continue to work if invoked with an absolute /bin path. I consider linking across file system a very bad practice because if /usr gets errors all the symlinks may be broken until it is repaired. Currently / is 600 MB on my system /usr being over 12 GB nad merging will just make it bigger. So there are more chances to break /usr and it takes more time to repair it. Aditionaly remount ro on error is hardly set in fstab and fs_passno is usually 2 not 1... With what you propose, any /usr fs bug will end up inserting a CD or USB key for repair... For sure it is not the case at the moment! Just as another reality check: I believe Red Hat has already done this. Lots of people use Red Hat and derivatives, and there doesn't seem to have been that much breakage. Red hat is mainly for servers nowadays with paying support. So I wonder if you are really doing meaningful comparison. Likewise Systemd was used by various distrib before debian, and it did break a lot at the beginning when upgrading existing debian installs, most init script are still unconverted and they cannot really accommodate the /etc/defaut/pkg configurable options... -- eric
Re: Re: support for merged /usr in Debian
>This is not true: you just need to use an initramfs. Ok, so it should warn that this setup will soon require to use an initramfs. It is the Debian default, there is no need to do this. Being debian installer default does not mean any debian users 1) really has any benefit of using it as explained, 2) nor use it after initial installation, Others have expressed better than I did that initramfs by itself is evil and just does what / was supposed to do originally: 1) because of binary firmware blob mainly allthough as explained this can be solved by putting the blob in kernel itself or using modules if things can be started late enough 2) because systemd requires many things that are traditionally located in /usr I for sure hate to have things twice on a system and make sure they are kept coherent by black magic (and using busybox rather than original utilities makes it even more evil...) Same for your proposal : nothing really sound except systemd wants it... Again, this is not related to systemd. I am not interested in continuing this discussion with people who are not understanding the basic facts. Sure. And I'm not interested to discuss with someone that feels so superior to normal human either and does not answer various points that have been detailed in this thread. I'm still 100% against your proposal. -- eric
Re: Re: support for merged /usr in Debian
Note that mounting /usr early, something we *already do*, is separate from actually merging /usr with /bin and /lib. Once you mount /usr early, it's rather less important whether you actually merge the file systems. While it does let you do some interesting things, I see it as more of a cleanup. Thanks for summarizing things so clearly : the root of the problem is indeed to mount /usr early enough at init time. Then : 1) initramfs can be seen as a well known solution that I personally dislike as explained elsewhere in this thread. But I do agree upon the ROI of using such a mechanism provided it is not imposed, 2) no separate partition for / and /usr being another one. I will probably end up changing the way I install new debian system to this one now that even SSD disks are so huge compared to system requirements, 3) merged /usr proposal being a kind of UFO... But could you elaborate a bit on "mounting /usr early, something we *already do*" if you do not implicitly refer to initramfs solution. I understand that for complex fs setup (lvm/raid/mounted networked fs...) this may require to much work to be done realistically at first install (like the solutions above by the way), but for most common cases (two ext4fs on a same disk, or separate disk but same drivers sets), I do not get what really prevents to mount /usr really early and propose that as a viable alternative to the mess (3) we have been proposed. --eric
Re: Re: support for merged /usr in Debian
What is the "upgrade path" for an older system that has /usr split off? Will it just stop being bootable after upgrading? It just needs to use an initramfs. A standalone /usr without an initramfs IS ALREADY NOT SUPPORTED by systemd. This is not relevant for merged /usr. What is the "upgrade path" for an older system that has /usr split off? Will it just stop being bootable after upgrading? It just needs to use an initramfs. A standalone /usr without an initramfs IS ALREADY NOT SUPPORTED by systemd. This is not relevant for merged /usr. It is not supported *BUT* just works as expected on more than 20 machines I have access to, especially now that the debian systemd maintainers make sure systemd do not depend on libraries installed in /usr... Systemd shall make linux boot easier, faster, secure, not render things impossible because it does not know how to handle it because it wants to do too much. For years (actually 20), I've been installing Linux on various machine using various distro to end up using exclusively debian because, I was able to tune the system as I want and not because other have decided I MUST do it in whatever way. For machines I really manage, I have a separate /usr, no initrd and self build kernel: 1) Why should I build modules when I always load them and hardware almost never changes. Its slower to start, does not bring any benefit, 2) I can even add binary blob in the kernel nowadays, so I do not need an initrd at all and the packages needed to build them are not even installed 3) There is not always places to copy / in /usr 4) My grub setup does not enable initrd, nor UUID for rot file system because without initrd you just can't, 5) I have machine with a byte of bad memory, and specific grub setup. I do not think you will ever be able to guess the correct grub config 6) I have machine that do network boots, and do not mount /usr the usual way,... The debian installer should first loudly warn that having a separated / and /usr may break things in the future but not forbid it. With that in place, new debian installations that have no good reason for different filesystem for / and /usr will be installed the preferred new way. Old folks that have been doing this for years on hundred of machines will eventually learn new tricks. People that are using this setup for reasons will still be able to do so. So please, do not make that kind of proposition that you will never be able to transition gracefully... -- eric
Re: Re: support for merged /usr in Debian
On Sun, Jan 03, 2016 at 11:40:34AM +0100, Eric Valette wrote: > The debian installer should first loudly warn that having a separated / and > /usr may break things in the future ITYM "already breaks things" -- WBR, wRAR signature.asc Description: PGP signature
Re: Re: support for merged /usr in Debian
The debian installer should first loudly warn that having a separated / and /usr may break things in the future but not forbid it. With that in place, This is not true: you just need to use an initramfs. Ok, so it should warn that this setup will soon require to use an initramfs. I just pointed out that this implies a slower boot and consumes times nearly at each package install (plus initrd tools seldom guess right everything that should be in the initrd to function). "I have always done this in a different way" is not a valid use case, sorry. Same for your proposal : nothing really sound except systemd wants it... And again, this is not related to supporting a merged /usr scheme. I think I gave you other reasons for not using an initrd that you have not answered (other did also in the discussion) and other gave you reasons to have /usr separated and not mounted at boot time that you have not answered either. -- eric
