Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Lennart Poettering on opentmpfiles: it's just baaaad
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4, 5, 6, 7  Next  
Reply to topic    Gentoo Forums Forum Index Gentoo Chat
View previous topic :: View next topic  
Author Message
Tony0945
Advocate
Advocate


Joined: 25 Jul 2006
Posts: 4111
Location: Illinois, USA

PostPosted: Wed Dec 11, 2019 1:06 am    Post subject: Reply with quote

pjp wrote:
But this is waaaay off topic, so I'll leave it at that.

Last last word. Yes, you are correct, that was a marketing pitch that they made.
Back to top
View user's profile Send private message
CasperVector
Apprentice
Apprentice


Joined: 03 Apr 2012
Posts: 155

PostPosted: Wed Dec 11, 2019 1:12 am    Post subject: Reply with quote

pjp wrote:
Other "complete" solutions exist, so that makes s6 questionable outside of academic pursuits.

The core SLOC of slew is ~500 (including ~150 for core service definitions), which can serve quite a few distros (even Ubuntu) with few tweaks.
I consider s6/s6-rc/slew as one of those "complete" solutions, so it minus ~500 lines of code can be considered quite close to complete.
This is fairly similar to TeX vs LaTeX: that TeX is not "complete" for ordinary users does not make it questionable outside of academic pursuits.
_________________
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C


Last edited by CasperVector on Wed Dec 11, 2019 1:31 am; edited 3 times in total
Back to top
View user's profile Send private message
technotorpedo
n00b
n00b


Joined: 10 Dec 2019
Posts: 30

PostPosted: Wed Dec 11, 2019 1:18 am    Post subject: Reply with quote

Another thanks, believe ChromeOS originally started life based on Gentoo's portage. To whatever extent Gentoo like. Though needless to say, yes google knows and/or hires people who know gnu/Nix or just about anything else, like the bk's of their hands, including Gentoo or how to compile from source etc etc etc. Though folks aren't going to know that, unless they bother researching and learning. Are not going to know/care what's based on this-that, what's even out there with no effort, without learning. Sheesh at a time when information is so readily available at whoever wants it finger tips(interwebz/databases, entire library of friggin Congress), can swear people are getting dumber than ever. Have mucho respect and admiration for Linus Torvald, outwardly he appears to be very much my type of person. No time for bs, forget politically correct, show me the hardcore data or shut up and stop wasting my time etc. He's quoted as saying he's somewhat surprised many geeks survived infancy, saying such things as, they should've starved, being too stupid to find their mothers teat, BIG +1 LT, big +1 man !!! :D

Also Google Inc and Redhat have contributed more to the actual progress and maintenance of gnu/Linux and so much else tech-oriented, than the entire general userbase combined. Fixing bugs the minority of users competent or cool enough notifying upstream of is just one tiny aspect of open source. Also another of the benefits of the open source development model. Plenty of free testing and some amount of contribs back up which benefit x-project. Google controls/owns HUGE datacenters and actual parts of the internets "backbone". Are more gnu/Linux installs by far on Google Inc controlled servers and systems, than there are personal gnu/Linux likely by far. Gawds only know how much of their backend infrastructure depends on gnu/Linux and open source. So yeah, they want to cut their own throats messing it up and miss out on those 10's of billions they earn every yr right ? Google or Redhat could've long since shut the door and kept all the improvements, developments and fixes they've developed, all the TONS of expensive manhours they've paid for working on various open source too. It's not in their best interests, RHEL = CentOS, Google Inc ChromeOS/chrome-browser, ChromiumOS, chromium browser etc etc. Again ... catch a clue peeps.

This was foreseen, was actually a part of the "grand plan" by many people. This platform would be nowhere near as far along as it is had it been otherwise. That's cold, hard FACT, not subject to interpretation, not a matter of opinion. You either understand it or don't, PERIOD.

Thanks for any intelligent and rational Gentoor's who responded to this. Know there's plenty of awesome, highly aware types to be found in this community anyway. All the folks with this hair-brained nonsense though. "If there's a mountain, under a rock, you'll find one hand clapping, thus it might be Wednesday" and other oddies pertaining to fact based technical subjects. Please STFU or at least give me some of whatever you're smoking. Errrrr maybe, what is it ? :D Sheesh this forum could use an ignore feature. Yeah I know .... sometimes annoy myself and consider putting me on ignore though. In other words, blahblahblah, you (nobody in particular) are an ignorant troll and have much to learn, yada yada, if a tree falls in the forest, blahblah.

Ok movie time will come back and troll later. Yeah no worries, am just a know it all troll. Nopers will never even scratch the surface of what all there is to know, not about tech and gnu/Linux, not about a gazillion other things but at least I'm willing to admit it and accept the fact of knowing somewhat what I don't know. Thus I keep trying to LEARN.
Back to top
View user's profile Send private message
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 18556

PostPosted: Wed Dec 11, 2019 6:43 am    Post subject: Reply with quote

CasperVector wrote:
pjp wrote:
Other "complete" solutions exist, so that makes s6 questionable outside of academic pursuits.

The core SLOC of slew is ~500 (including ~150 for core service definitions), which can serve quite a few distros (even Ubuntu) with few tweaks.
I consider s6/s6-rc/slew as one of those "complete" solutions, so it minus ~500 lines of code can be considered quite close to complete.
This is fairly similar to TeX vs LaTeX: that TeX is not "complete" for ordinary users does not make it questionable outside of academic pursuits.
OK, that's too funny to not point this out (from wikipedia): "TeX is popular in academia, especially in mathematics, computer science, economics, engineering, linguistics, physics, statistics, and quantitative psychology."

"Academic" was the best word I could think of at the time. More accurately, s6 being only half of a solution makes it impractical for many who do not have the time, ability, or interest to create and maintain the other half of the software needed to complete the whole. I thought academic was accurate enough to convey that. It was not my intention to convey any negative criticism.
_________________
Your lips move, but I can't hear what you're saying.
Back to top
View user's profile Send private message
CasperVector
Apprentice
Apprentice


Joined: 03 Apr 2012
Posts: 155

PostPosted: Wed Dec 11, 2019 7:25 am    Post subject: Reply with quote

pjp wrote:
"Academic" was the best word I could think of at the time. [...] I thought academic was accurate enough to convey that. It was not my intention to convey any negative criticism.

Oh, when I said "TeX is not 'complete' for ordinary users" I also meant "LaTeX is 'complete' for ordinary users" in comparison. YMMV, but you also get my idea :)

Quote:
More accurately, s6 being only half of a solution makes it impractical for many who do not have the time, ability, or interest to create and maintain the other half of the software needed to complete the whole.

I understand that you are not trying to discredit s6, but pointing out the incompleteness of s6/s6-rc for ordinary users which is a real problem.
I will attempt to give a slew-based example that can be used almost out of the box in Gentoo when preparing the post a few days later.
Due to the current lack of request for package support (which I sincerely welcome you to submit!) in slew, the example will be small like this.
However, I hope it can show how small "the other half" actually is: if we judge from simple SLOC, that "half" will definitely be less than 1%.
_________________
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C
Back to top
View user's profile Send private message
AJM
Tux's lil' helper
Tux's lil' helper


Joined: 25 Sep 2002
Posts: 140
Location: Aberdeen, Scotland

PostPosted: Wed Dec 11, 2019 12:33 pm    Post subject: Reply with quote

technotorpedo wrote:
Google Inc ChromeOS/chrome-browser, ChromiumOS, chromium browser etc etc. Again ... catch a clue peeps.


Ah yes, remind me again which init system the gurus at Google (who know tech inside out like the back of their hands or whatever it was you said) chose for ChromeOS... Perhaps you should email them and let them know they've made a mistake and haven't noticed that there's a technically far superior option available from Red Hat?
Back to top
View user's profile Send private message
technotorpedo
n00b
n00b


Joined: 10 Dec 2019
Posts: 30

PostPosted: Fri Dec 13, 2019 12:55 am    Post subject: Reply with quote

Perhaps you should reread what else was said and/or develop greater reading comprehension or common sense. Errrr, that's just not the way it is, either someone has and does develop common sense or they don't and anyone whose lived for any length of time knows the phrase "common sense" is a cruel-ironic play on words, it's not common at all. Google Inc will take/leave what tools they please. If that Corp wants a brand-new written from scratch init or anything else (by some of the worlds top techies.) They'll cut the check and whichever person is overseeing that thing will report on the progress involved. Though why go through all that when there's plenty of options already freely available for use or modification to be appropriate to their uses-wants etc.

Who said they were using the wrong init ? They're very much aware of what they're using and why. Though unlike many they actually are doing something/anything, rather than impotently whining and crying, thus those lamers are accomplishing nothing at all in regards the matter, shrugs. Which actually I don't want to bother speculating on this nonsense or possible Google Inc motivations further. This thread is/was a total waste of time, pointless from the get-go. I could be doing something/anything (picking my nose)and it'd be much more productive use of my time.
Back to top
View user's profile Send private message
Tony0945
Advocate
Advocate


Joined: 25 Jul 2006
Posts: 4111
Location: Illinois, USA

PostPosted: Fri Dec 13, 2019 3:57 am    Post subject: Reply with quote

It's time to stop listening to this foul-mouthed troll.
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


Joined: 21 May 2004
Posts: 5847
Location: Removed by Neddy

PostPosted: Sat Dec 28, 2019 5:13 pm    Post subject: Reply with quote

Anon-E-moose wrote:
Latest, Naib

Code:
The eight options they're voting on:

    Choice 1: F: Focus on systemd

    Choice 2: B: Systemd but we support exploring alternatives

    Choice 3: A: Support for multiple init systems is Important

    Choice 4: D: Support non-systemd systems, without blocking progress

    Choice 5: H: Support portability, without blocking progress

    Choice 6: E: Support for multiple init systems is Required

    Choice 7: G: Support portability and multiple implementations

    Choice 8: Further Discussion


Votes are in. Choice 2: B: Systemd but we support exploring alternatives

https://vote.debian.org/~secretary/gr_initsystems/results.txt
_________________
The best argument against democracy is a five-minute conversation with the average voter
Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king
Back to top
View user's profile Send private message
mike155
Advocate
Advocate


Joined: 17 Sep 2010
Posts: 2411
Location: Frankfurt, Germany

PostPosted: Sat Dec 28, 2019 5:20 pm    Post subject: Reply with quote

Naib wrote:
Votes are in. Choice 2: B: Systemd but we support exploring alternatives

I'm glad they didn't vote for '8 - Further Discussion'. :)
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 46272
Location: 56N 3W

PostPosted: Sat Dec 28, 2019 5:22 pm    Post subject: Reply with quote

Naib,

"support" ???
That means "He Haw" to use a local term.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 4866
Location: Dallas area

PostPosted: Sat Dec 28, 2019 5:47 pm    Post subject: Reply with quote

Naib wrote:
Votes are in. Choice 2: B: Systemd but we support exploring alternatives


Not surprised, but if they supported looking at alternatives, then the whole poll thing wouldn't have happened. :lol:
_________________
PRIME x570-pro, 3700x, RX 550 - 5.8 zen kernel
Acer E5-575 (laptop), i3-7100u - i965 - 5.5 zen kernel
---both---
gcc 9.3.0, profile 17.1 (no-pie & modified) amd64-no-multilib, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
GDH-gentoo
Guru
Guru


Joined: 20 Jul 2019
Posts: 482
Location: South America

PostPosted: Sat Dec 28, 2019 7:16 pm    Post subject: Reply with quote

Naib wrote:
Votes are in. Choice 2: B: Systemd but we support exploring alternatives

https://vote.debian.org/~secretary/gr_initsystems/results.txt

Narrowly winning over "F: Focus on systemd", because there were more Debian developers that ranked B over F than those who ranked F over B. 22 more out of 425 votes, to be precise.

I guess this in practice means the continuation of Debian's status quo, including turning bugs into fights.
Back to top
View user's profile Send private message
saellaven
Guru
Guru


Joined: 23 Jul 2006
Posts: 569

PostPosted: Sat Dec 28, 2019 10:37 pm    Post subject: Reply with quote

B is essentially the same as F, given that maintainers don't have to accept patches that allow compatibility with other init systems. It's a "nice" way of really voting F, since, if choice isn't explicitly supported (option E, or at least A), nobody is going to bother supporting more than they want to.

It's the same politics game we've seen over here in Gentoo, revolving our group of the same type of people that have intentionally hamstrung other options with the intent of making them as limited and broken as systemd is (see: the crippling of openrc since 0.12.4 or 0.17 depending on your point of view, trying to force initramfs, etc).
_________________
Ryzen 3700X, Asus Prime X570-Pro, 32 GB DDR4 3200, GeForce 1050 Ti
openrc-0.17, ~vanilla-sources, ~nvidia-drivers, gcc-9.3.0
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6380

PostPosted: Sun Dec 29, 2019 12:20 pm    Post subject: Reply with quote

saellaven wrote:
It's a "nice" way of really voting F, since, if choice isn't explicitly supported (option E, or at least A), nobody is going to bother supporting more than they want to.

The difference is that with B maintainers are free to support alternatives if they want to. The reason for the vote was that some developers wanted to forbid this to some maintainers.
Back to top
View user's profile Send private message
Amity88
Apprentice
Apprentice


Joined: 03 Jul 2010
Posts: 246
Location: Third planet from the Sun

PostPosted: Sun Dec 29, 2019 5:11 pm    Post subject: Reply with quote

saellaven wrote:
in Gentoo, revolving our group of the same type of people that have intentionally hamstrung other options with the intent of making them as limited and broken as systemd is (see: the crippling of openrc since 0.12.4 or 0.17 depending on your point of view, trying to force initramfs, etc).


Forgive my ignorance but how was openrc crippled? I'm currently on 0.41 but haven't run into any issues (yet). Should I downgrade to < 0.12
_________________
Ant P. wrote:
The enterprise distros sell their binaries. Canonical sells their users.


Also... Be ignorant... Be happy! :)
Back to top
View user's profile Send private message
Zucca
Veteran
Veteran


Joined: 14 Jun 2007
Posts: 1804
Location: KUUSANKOSKI, Finland

PostPosted: Sun Dec 29, 2019 8:40 pm    Post subject: Reply with quote

Amity88 wrote:
Forgive my ignorance but how was openrc crippled? I'm currently on 0.41 but haven't run into any issues (yet). Should I downgrade to < 0.12
This seems to be quite a common theme around here. I'd like to know too. :?:
_________________
..: Zucca :..

Code:
ERROR: '--failure' is not an option. Aborting...
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


Joined: 21 May 2004
Posts: 5847
Location: Removed by Neddy

PostPosted: Sun Dec 29, 2019 8:46 pm    Post subject: Reply with quote

There were some questionable decisions which appeared to take influence from systemd (rather than solving an actual problem). The need for an initramfs to manage /usr on a separate partition appeared to be the last straw for many as this was a feature that has existed since year dot but because systemd painted themselves into a corner (due to some of the worst system architecting seen...) it was accepted this regression.for some reason it also impacted OpenRC ....

Stupid ass functional regression, stupid ass architecting, stupid ass arrogance that just pushed forward with it.
_________________
The best argument against democracy is a five-minute conversation with the average voter
Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 6714

PostPosted: Sun Dec 29, 2019 9:56 pm    Post subject: Reply with quote

Basically every init-related package in Gentoo was invisibly taken over by one person some years back, who cannot possibly be using all of them enough to understand how they were designed to be used (see the attempt to create an abandonware chimera that emulates systemd by cramming s6-svc support haphazardly into openrc init.d scripts). Newer versions of OpenRC aren't even a Gentoo-led project any more, let alone Gentoo-hosted.

If you want a long-term survival plan, I recommend the S6 work others are doing. Just don't use the sys-apps/s6 from the main tree for it.
Back to top
View user's profile Send private message
GDH-gentoo
Guru
Guru


Joined: 20 Jul 2019
Posts: 482
Location: South America

PostPosted: Sun Dec 29, 2019 10:04 pm    Post subject: Reply with quote

Naib wrote:
The need for an initramfs to manage /usr on a separate partition [...] for some reason it also impacted OpenRC
I keep reading this, and if it means that OpenRC does not support booting a system with /usr on a separate filesystem and without an initramfs, then it is not true, at least for current stable branch OpenRC, as long as there is an implementation of md5sum in the rootfs.

It is true that separate /usr with no initramfs is not a supported setup on Gentoo. Which doesn't necessarily mean that it won't work, only that whoever wants this setup is on his/her own. It is true that depending on which packages are installed, it might not work indeed. One common packaging error that causes this being udev rules that call executables in /usr [1]. But OpenRC itself can (almost) deal with it just fine. How do I know? Because I have such a system (/usr is an LVM2 logical volume), and OpenRC is able to boot it.

Regarding the md5sum thing: /lib/rc/sh/init.sh, a script that is called by the openrc program when entering the sysinit runlevel, uses it to test for a corner case in some container scenarios, apparently, and GNU Coreutils' md5sum is in /usr/bin. Simple solution? Make an md5sum symbolic link to /bin/busybox in /lib/rc/bin. Without the symlink, an error message will be shown ("md5sum is missing, which suggests /usr is not mounted" and other messages), but the system will still boot.

[1] The correct packaging would be installing the executable in /lib/udev and putting a symlink to in /usr/bin, /usr/libexec, or whatever. Programs specified by names in assignments to RUN (as opposed to absolute pathnames) are searched in /lib/udev.
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


Joined: 21 May 2004
Posts: 5847
Location: Removed by Neddy

PostPosted: Sun Dec 29, 2019 10:43 pm    Post subject: Reply with quote

GDH-gentoo wrote:
Naib wrote:
The need for an initramfs to manage /usr on a separate partition [...] for some reason it also impacted OpenRC
I keep reading this, and if it means that OpenRC does not support booting a system with /usr on a separate filesystem and without an initramfs, then it is not true, at least for current stable branch OpenRC, as long as there is an implementation of md5sum in the rootfs.
The issue is actually udev. so if you use udev (or even eudev) then you will need to have an initramfs because aspects of udev are stored in /usr/ (herpderp... key booting lib/binaries on paths that historically might not be present). udev is a systemd project.

it doesn't' matter which init system you use (systemd, OpenRC, r6, busybox...) *IF* at any point an init service requires something from a path that isn't mounted you will not be able to launch that service.
_________________
The best argument against democracy is a five-minute conversation with the average voter
Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king
Back to top
View user's profile Send private message
saellaven
Guru
Guru


Joined: 23 Jul 2006
Posts: 569

PostPosted: Sun Dec 29, 2019 10:50 pm    Post subject: Reply with quote

GDH-gentoo wrote:
Naib wrote:
The need for an initramfs to manage /usr on a separate partition [...] for some reason it also impacted OpenRC
I keep reading this, and if it means that OpenRC does not support booting a system with /usr on a separate filesystem and without an initramfs, then it is not true, at least for current stable branch OpenRC, as long as there is an implementation of md5sum in the rootfs.

It is true that separate /usr with no initramfs is not a supported setup on Gentoo. Which doesn't necessarily mean that it won't work, only that whoever wants this setup is on his/her own. It is true that depending on which packages are installed, it might not work indeed. One common packaging error that causes this being udev rules that call executables in /usr [1]. But OpenRC itself can (almost) deal with it just fine. How do I know? Because I have such a system (/usr is an LVM2 logical volume), and OpenRC is able to boot it.


WilliamH abused his positions as the self-declared maintainer of all the gentoo init systems, as well as his positions on the Gentoo Council, to force a decision, similar to the debian init system vote this month, to officially bastardize support for a separate /usr without initramfs. He lied to the rest of the Council, and, in good faith, they did no due diligence and accepted his recommendation, all while there existed a patch developed by SteveL and well tested by a lot of other people to explicitly support a separate /usr without an initramfs (and it was a rather trivial patch). WilliamH knew about the patch, refused to accept it into openrc, didn't disclose the existence to the rest of the Council, and got a political decision allowing openrc to be crippled to the level of systemd.

It was never about making openrc or systemd more robust, it was always about limiting the functionality of openrc so it wouldn't be definitively better than systemd.

That it just happens to work still is a fluke, not anything intentional. Whatever intention there is behind it, largely stems from a handful of us here on the forums that pushed back after that Council decision and the changes made in the wake of it to openrc. I, myself, locked into openrc-0.17 because I don't trust the competency or motivations of the maintainer going forward and consider it a damaged package. Others stayed at 0.12.4.

Why does lm-sensors depend on openrc-0.36 or newer when my 0.17 works fine, unmodified? Because of the politics of trying to force people into something they don't want, which ties back into WilliamH and his crusade to cripple openrc to make sure it never gets ahead of systemd in functionality. What do all the systemd proponents say about competition? Write something better... and how does that happen when things are intentionally hamstrung to not make systemd look inferior?

And that is why option B of the Debian vote is really a vote for option A. If you don't explicitly support other init systems, if a package maintainer is free to reject patches supporting other init systems (just a simple bash script to start a program), then, in effect you're really voting for option A.

Quote:

Regarding the md5sum thing: /lib/rc/sh/init.sh, a script that is called by the openrc program when entering the sysinit runlevel, uses it to test for a corner case in some container scenarios, apparently, and GNU Coreutils' md5sum is in /usr/bin. Simple solution? Make an md5sum symbolic link to /bin/busybox in /lib/rc/bin. Without the symlink, an error message will be shown ("md5sum is missing, which suggests /usr is not mounted" and other messages), but the system will still boot.

[1] The correct packaging would be installing the executable in /lib/udev and putting a symlink to in /usr/bin, /usr/libexec, or whatever. Programs specified by names in assignments to RUN (as opposed to absolute pathnames) are searched in /lib/udev.


and all of that stems from LP and his FDo friends throwing crap all over the system instead of respecting the LFS design to begin with... They never understood the principles of UNIX and, at least initially probably through ignorance, are determined to cripple Linux the same way that Windows is crippled, and, ultimately for the same reason. Windows is to Microsoft what systemd, FDo, and friends are to Red Hat's revenue stream.
_________________
Ryzen 3700X, Asus Prime X570-Pro, 32 GB DDR4 3200, GeForce 1050 Ti
openrc-0.17, ~vanilla-sources, ~nvidia-drivers, gcc-9.3.0
Back to top
View user's profile Send private message
saellaven
Guru
Guru


Joined: 23 Jul 2006
Posts: 569

PostPosted: Sun Dec 29, 2019 10:51 pm    Post subject: Reply with quote

Naib wrote:
GDH-gentoo wrote:
Naib wrote:
The need for an initramfs to manage /usr on a separate partition [...] for some reason it also impacted OpenRC
I keep reading this, and if it means that OpenRC does not support booting a system with /usr on a separate filesystem and without an initramfs, then it is not true, at least for current stable branch OpenRC, as long as there is an implementation of md5sum in the rootfs.
The issue is actually udev. so if you use udev (or even eudev) then you will need to have an initramfs because aspects of udev are stored in /usr/ (herpderp... key booting lib/binaries on paths that historically might not be present). udev is a systemd project.

it doesn't' matter which init system you use (systemd, OpenRC, r6, busybox...) *IF* at any point an init service requires something from a path that isn't mounted you will not be able to launch that service.


udev/eudev still works under separate /usr with SteveL's openrc patches that WilliamH intentionally ignored.
_________________
Ryzen 3700X, Asus Prime X570-Pro, 32 GB DDR4 3200, GeForce 1050 Ti
openrc-0.17, ~vanilla-sources, ~nvidia-drivers, gcc-9.3.0
Back to top
View user's profile Send private message
GDH-gentoo
Guru
Guru


Joined: 20 Jul 2019
Posts: 482
Location: South America

PostPosted: Sun Dec 29, 2019 11:19 pm    Post subject: Reply with quote

Naib wrote:
GDH-gentoo wrote:
Naib wrote:
The need for an initramfs to manage /usr on a separate partition [...] for some reason it also impacted OpenRC
I keep reading this, and if it means that OpenRC does not support booting a system with /usr on a separate filesystem and without an initramfs, then it is not true, at least for current stable branch OpenRC, as long as there is an implementation of md5sum in the rootfs.
The issue is actually udev. so if you use udev (or even eudev) then you will need to have an initramfs because aspects of udev are stored in /usr/ [...]
(I think I posted about this before)

Not true either, at least for current stable branch eudev. udevd is in /sbin, udevadm is in /bin, the shared libudev is in /lib or /lib64, the rules themselves are in /lib/udev/rules.d, and the ones installed by the eudev package itself either call udev builtins or programs in /lib/udev. How do I know it works? Because I have a system with eudev, separate /usr and no initramfs, and it boots with both sysvinit + OpenRC and s6 + s6-rc + s6-linux init.

Naib wrote:
it doesn't' matter which init system you use (systemd, OpenRC, r6, busybox...) *IF* at any point an init service requires something from a path that isn't mounted you will not be able to launch that service.
This (poor packaging practices) is the real issue, but the offenders would be the corresponding packages, not OpenRC or eudev.
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


Joined: 21 May 2004
Posts: 5847
Location: Removed by Neddy

PostPosted: Sun Dec 29, 2019 11:22 pm    Post subject: Reply with quote

saellaven wrote:
Naib wrote:
GDH-gentoo wrote:
Naib wrote:
The need for an initramfs to manage /usr on a separate partition [...] for some reason it also impacted OpenRC
I keep reading this, and if it means that OpenRC does not support booting a system with /usr on a separate filesystem and without an initramfs, then it is not true, at least for current stable branch OpenRC, as long as there is an implementation of md5sum in the rootfs.
The issue is actually udev. so if you use udev (or even eudev) then you will need to have an initramfs because aspects of udev are stored in /usr/ (herpderp... key booting lib/binaries on paths that historically might not be present). udev is a systemd project.

it doesn't' matter which init system you use (systemd, OpenRC, r6, busybox...) *IF* at any point an init service requires something from a path that isn't mounted you will not be able to launch that service.


udev/eudev still works under separate /usr with SteveL's openrc patches that WilliamH intentionally ignored.


udev/eudev can works IF patched. Slight difference. Politics aside for a moment. eudev shadows udev and is meant to be just an unbundled version of udev to mitigate the threat from Pottering. There are a number of things eudev could do to fix aspects of udev but they don't simply to keep this path open.
Such a patch should be posted to upstream systemd (has it? I doubt it as people would rather moan than do something). Now another option could be an experimental USE flag for eudev where it applies such a patch, but who would then maintain that patch as udev code changes?

now politics certainly has been an influence but the end-game we are unfortunately unaware of
_________________
The best argument against democracy is a five-minute conversation with the average voter
Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo Chat All times are GMT
Goto page Previous  1, 2, 3, 4, 5, 6, 7  Next
Page 6 of 7

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum