[opensuse-factory] / v. /usr: What do we want?
Hi, it is my understanding that openSUSE will no longer boot without /usr being around. A long time ago I hence opened https://bugzilla.suse.com/show_bug.cgi?id=1029961, with all the apps that I could find as subtickets. The suggestion was move all apps to /usr, and symlink /bin and /sbin, a step performed by Fedora a while ago. So far I can see: - Pro arguments: - We can consolidate the root directories with their peers in /usr - People have a hard time telling which binary is where - The only real argument for providing an environment without /usr being potentially available is now invalid due to systemd living in /usr, and being required as early as the rootfs. - Couter arguments: - RPM cannot (or could not) deal with symlink. It was Fedora had issues due to that (but now if/how it was ultimately resolved) - "I like things the way they are" As you can see from the maintainer response in the some of the subtickets, there was not much love for giving up the root locations. So I was about to close this ticket. However, the current state is completely arbitrary, and other people noticed and asked me to ask for direction and opinion here. How should we proceed? Cheers, Daniel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Jul 23, 2019 at 8:03 AM Daniel Molkentin <dmolkentin@suse.de> wrote:
Hi,
it is my understanding that openSUSE will no longer boot without /usr being around. A long time ago I hence opened https://bugzilla.suse.com/show_bug.cgi?id=1029961, with all the apps that I could find as subtickets. The suggestion was move all apps to /usr, and symlink /bin and /sbin, a step performed by Fedora a while ago.
So far I can see:
- Pro arguments:
- We can consolidate the root directories with their peers in /usr
- People have a hard time telling which binary is where
- The only real argument for providing an environment without /usr being potentially available is now invalid due to systemd living in /usr, and being required as early as the rootfs.
- Couter arguments:
- RPM cannot (or could not) deal with symlink. It was Fedora had issues due to that (but now if/how it was ultimately resolved)
- "I like things the way they are"
As you can see from the maintainer response in the some of the subtickets, there was not much love for giving up the root locations. So I was about to close this ticket.
However, the current state is completely arbitrary, and other people noticed and asked me to ask for direction and opinion here. How should we proceed?
I'd like to see us complete UsrMerge properly. The way things currently are lead to weird problems depending on what kind of rootfs is being made, and at least at work, it makes testing code on openSUSE a nightmare. There's a specific patch that was applied to "hack" a special case into rpm to allow / -> /usr transitions (which I'm in the process of rebasing for OpenMandriva already, since they're going to be undergoing UsrMerge soon). We'd have to keep the patch in SUSE's rpm until all versions of SLE that don't have UsrMerge done are EOL. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 23.07.19 um 14:11 schrieb Neal Gompa:
We'd have to keep the patch in SUSE's rpm
Forever.
until all versions of SLE that don't have UsrMerge done are EOL.
Especially after a version is EOL (For SLES15 that's after 2031) you might want to be able to update... But that does not have to be a problem, or is the patch so ugly that nobody can estimate the side effects it will have? -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Jul 23, 2019 at 1:29 PM Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:
Am 23.07.19 um 14:11 schrieb Neal Gompa:
We'd have to keep the patch in SUSE's rpm
Forever.
until all versions of SLE that don't have UsrMerge done are EOL.
Especially after a version is EOL (For SLES15 that's after 2031) you might want to be able to update...
But that does not have to be a problem, or is the patch so ugly that nobody can estimate the side effects it will have?
Nah, it's a simple and predictable patch. It was shipped in Fedora for many years, and is present in RHEL 7's rpm as well. It's just a matter of me having time to push it somewhere. :) -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 7/23/19 8:01 PM, Neal Gompa wrote:
On Tue, Jul 23, 2019 at 1:29 PM Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:
Am 23.07.19 um 14:11 schrieb Neal Gompa:
We'd have to keep the patch in SUSE's rpm Forever.
until all versions of SLE that don't have UsrMerge done are EOL. Especially after a version is EOL (For SLES15 that's after 2031) you might want to be able to update...
But that does not have to be a problem, or is the patch so ugly that nobody can estimate the side effects it will have? Nah, it's a simple and predictable patch. It was shipped in Fedora for many years, and is present in RHEL 7's rpm as well.
It's just a matter of me having time to push it somewhere. :)
So how do we continue? The patch is one thing, getting the maintainers consent another. Cheers, Daniel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Jul 26, Daniel Molkentin wrote:
So how do we continue? The patch is one thing, getting the maintainers consent another.
Start with providing the infrastructure, that we can do this. Means e.g. the RPM patch. Then take some packages and adjust them. There are not that much left on a standard install. And in some point of time, it's only a small step with a big change. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 7/26/19, Thorsten Kukuk <kukuk@suse.de> wrote:
On Fri, Jul 26, Daniel Molkentin wrote:
So how do we continue? The patch is one thing, getting the maintainers consent another.
Start with providing the infrastructure, that we can do this. Means e.g. the RPM patch. Then take some packages and adjust them. There are not that much left on a standard install. And in some point of time, it's only a small step with a big change.
Well, the SR is sent, we'll see how that goes: https://build.opensuse.org/request/show/718856 -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 7/26/19 7:44 PM, Daniel Molkentin wrote:
On 7/23/19 8:01 PM, Neal Gompa wrote:
On Tue, Jul 23, 2019 at 1:29 PM Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:
Am 23.07.19 um 14:11 schrieb Neal Gompa:
We'd have to keep the patch in SUSE's rpm Forever.
until all versions of SLE that don't have UsrMerge done are EOL. Especially after a version is EOL (For SLES15 that's after 2031) you might want to be able to update...
But that does not have to be a problem, or is the patch so ugly that nobody can estimate the side effects it will have? Nah, it's a simple and predictable patch. It was shipped in Fedora for many years, and is present in RHEL 7's rpm as well.
It's just a matter of me having time to push it somewhere. :)
So how do we continue? The patch is one thing, getting the maintainers consent another.
If it seems to be the general consensus of the project that this is how we want to proceed (which it seems to be because I haven't seen much disagreement), you can raise any issues you have with maintainers such as not accepting SR's to the board if you can't get resolution, that's exactly what we are for. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2019/07/23 05:03, Daniel Molkentin wrote:
Hi,
it is my understanding that openSUSE will no longer boot without /usr being around. A long time ago I hence opened https://bugzilla.suse.com/show_bug.cgi?id=1029961, with all the apps that I could find as subtickets. The suggestion was move all apps to /usr, and symlink /bin and /sbin, a step performed by Fedora a while ago.
So far I can see:
- Pro arguments:
- We can consolidate the root directories with their peers in /usr
---- Why not just mount /usr/bin on /bin and /usr/lib64 on /lib64? It works in cygwin...well they do it in reverse -- they have everything in root, and mount it in /usr so nothing broke, but still. Make a static 'mount' that lives in the root file system so you can mount the /usr dirs immediately. That's pretty much what I've done when the normal mount didn't work because it required libs in /usr.
- People have a hard time telling which binary is where
Use 'whence', or 'type -P'.
- The only real argument for providing an environment without /usr being potentially available is now invalid due to systemd living in /usr, and being required as early as the rootfs.
---- Unless you don't use systemd... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Jul 26, 2019 at 8:58 PM L A Walsh <suse@tlinx.org> wrote:
On 2019/07/23 05:03, Daniel Molkentin wrote:
Hi,
it is my understanding that openSUSE will no longer boot without /usr being around. A long time ago I hence opened https://bugzilla.suse.com/show_bug.cgi?id=1029961, with all the apps that I could find as subtickets. The suggestion was move all apps to /usr, and symlink /bin and /sbin, a step performed by Fedora a while ago.
So far I can see:
- Pro arguments:
- We can consolidate the root directories with their peers in /usr
---- Why not just mount /usr/bin on /bin and /usr/lib64 on /lib64?
It works in cygwin...well they do it in reverse -- they have everything in root, and mount it in /usr so nothing broke, but still. Make a static 'mount' that lives in the root file system so you can mount the /usr dirs immediately. That's pretty much what I've done when the normal mount didn't work because it required libs in /usr.
It works in Cygwin because there's an implicit root directory already below. And the reverse case is *really* hard to support properly in initramfs, especially for shared root filesystems (a la thin-boot systems), which is why moving things into /usr is preferred. Moreover, Linux wasn't even first to it. Other *nix OSes did it for similar reasons. It was agreed long ago to do this for this reason and many others, but it just lost steam as time went on, so SUSE distributions have been in a half-completed state for years. Finishing it is *not* difficult. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Samstag, 27. Juli 2019, 04:06:55 CEST schrieb Neal Gompa:
It was agreed long ago to do this for this reason and many others, but it just lost steam as time went on, so SUSE distributions have been in a half-completed state for years. Finishing it is *not* difficult.
I agree in general, but the devil is in the detail ;-) As you probably know, AppArmor checks permissions _after_ resolving symlinks, so you'll need to change rules for /bin/foo to /usr/bin/foo or better (to cover both paths) /{usr/,}bin/foo. I've already done that for the profiles I'm aware of (see boo#1132350), but I can't promise that I found all packages shipping AppArmor profiles. One thing that still needs a change is the docker AppArmor profile, which is - to make things more funny - hardcoded into template.go and (AFAIK) gets piped into apparmor_parser directly from there: https://github.com/docker/docker-ce/blob/master/components/engine/ contrib/apparmor/template.go All the /bin/, /sbin/ and /lib/ paths need to be adjusted for usrMerge. AFAIK podman also hides its profile in its source code, but I don't know in which file exactly. Regards, Christian Boltz -- if you need a helping hand, you will find one at the end of your arm. [Donald Tusk, https://twitter.com/eucopresident/status/996731038062862336] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 7/27/19 10:28 AM, L A Walsh wrote:
On 2019/07/23 05:03, Daniel Molkentin wrote:
Hi,
it is my understanding that openSUSE will no longer boot without /usr being around. A long time ago I hence opened https://bugzilla.suse.com/show_bug.cgi?id=1029961, with all the apps that I could find as subtickets. The suggestion was move all apps to /usr, and symlink /bin and /sbin, a step performed by Fedora a while ago.
So far I can see:
- Pro arguments:
- We can consolidate the root directories with their peers in /usr
- People have a hard time telling which binary is where
Use 'whence', or 'type -P'.
- The only real argument for providing an environment without /usr being potentially available is now invalid due to systemd living in /usr, and being required as early as the rootfs.
---- Unless you don't use systemd...
If your not using systemd, your not using an openSUSE system and its not really relevant to this discussion. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2019/07/27 22:36, Simon Lees wrote:
If your not using systemd, your not using an openSUSE system and its not really relevant to this discussion.
And if you are not using gvim, are you an openSUSE system? Of the over 10k packages, which are synonymous with openSUSE?
From what you are saying systemd is synonymous with openSUSE.
Is there a choice on desktops, or is one synonymous? How about boot loaders? is grub the only allowed boot loader, or is lilo allowed? Are you saying that if systemd has a method for doing 'X', then doing it any other way doesn't belong in opensuse? It seems like this might be a good opportunity to eliminate many packages, like why is opensuse still shipping any cron or atd packages? I wonder how many packages could be eliminated by going down the list and removing anything that systemd handles. I.e. from what you are saying, if someone is using cron to schedule tasks, then they aren't using an opensuse system? You are the one that claims systemd is a determiner of whether or not a system is an openSUSE system. If that's the case, then why are various alternatives shipping? This isn't a hypothetical question. SUSE is shipping various alternatives to systemd. So why? Any chance of making it more modular, so you could use the good parts but not necessarily everything? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Aug 2, 2019 at 11:36 PM L A Walsh <suse@tlinx.org> wrote:
On 2019/07/27 22:36, Simon Lees wrote:
If your not using systemd, your not using an openSUSE system and its not really relevant to this discussion.
And if you are not using gvim, are you an openSUSE system?
Of the over 10k packages, which are synonymous with openSUSE?
From what you are saying systemd is synonymous with openSUSE.
Is there a choice on desktops, or is one synonymous?
How about boot loaders? is grub the only allowed boot loader, or is lilo allowed?
Are you saying that if systemd has a method for doing 'X', then doing it any other way doesn't belong in opensuse?
It seems like this might be a good opportunity to eliminate many packages, like
why is opensuse still shipping any cron or atd packages?
I wonder how many packages could be eliminated by going down the list and removing anything that systemd handles.
I.e. from what you are saying, if someone is using cron to schedule tasks, then they aren't using an opensuse system?
You are the one that claims systemd is a determiner of whether or not a system is an openSUSE system. If that's the case, then why are various alternatives shipping?
This isn't a hypothetical question.
SUSE is shipping various alternatives to systemd. So why?
Ignoring the fact that SUSE != openSUSE, this is not true. SUSE is *not* shipping alternatives to systemd. That's the point. The only scenario in which you don't have systemd is if you're making a single application/service OCI container. In *every other scenario*, you are using systemd. openSUSE may have things that *look* like alternatives to systemd, but they're not intended to work that way. The one and only service manager for SUSE distributions is systemd. Our sysvinit package does not ship sysvinit, only some of the auxiliary tools useful for LSB script compatibility. To my knowledge, there are no alternatives being shipped in *any* SUSE distribution, product, or service. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 8/3/19 9:50 AM, Neal Gompa wrote:
The only scenario in which you don't have systemd is if you're making a single application/service OCI container.
Yes. But exactly this use-case is defeated by continuously adding dependency on systemd running in almost every package (e.g. replacing CRON with systemd-timer). Ciao, Michael.
On Sat, Aug 3, 2019 at 5:33 AM Michael Ströder <michael@stroeder.com> wrote:
On 8/3/19 9:50 AM, Neal Gompa wrote:
The only scenario in which you don't have systemd is if you're making a single application/service OCI container.
Yes.
But exactly this use-case is defeated by continuously adding dependency on systemd running in almost every package (e.g. replacing CRON with systemd-timer).
Well, a runtime dependency on systemd isn't necessarily required for packages shipping systemd units (including timers). They're just files... And in a container, service units and timers aren't really useful (same goes for sysv scripts and cron jobs). If we used %systemd_ordering instead of %systemd_requires, then containers won't be forced to include systemd if it's unneeded. It'd be even easier to drop that dependency in packages if the upstream systemd macros and triggers were actually used in the SUSE systemd package (*sighs*). But, that's a whole other can of worms... :( -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, Aug 03, Michael Ströder wrote:
On 8/3/19 9:50 AM, Neal Gompa wrote:
The only scenario in which you don't have systemd is if you're making a single application/service OCI container.
Yes.
But exactly this use-case is defeated by continuously adding dependency on systemd running in almost every package (e.g. replacing CRON with systemd-timer).
No, if your package pulls in systemd while it is only optional for this package, the dependencies of this package are broken. We have enough packages, which provide systemd units and works fine on Tumbleweed, but also works fine in a container without pulling in systemd. And it doesn't matter if your package uses systemd-timer or cron: you don't have cron in a container, too. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2019/08/03 00:50, Neal Gompa wrote:
Ignoring the fact that SUSE != openSUSE,
ya, true enough, though that make it sound like the answers for the two are different. Is SUSE shipping alternatives for service control that openSUSE is not? If that's the case, why would they provide an alternative where openSUSE has not?
[open]SUSE is shipping various alternatives to [various parts of] systemd. So why?
this is not true.
As a scheduler of tasks, it _is_ true, but you clarify more down below, you are talking service manager, but I was referring to all the other areas it has replaced...
SUSE is *not* shipping alternatives to systemd. That's the point. The only scenario in which you don't have systemd is if you're making a single application/service OCI container. In *every other scenario*, you are using systemd.
openSUSE may have things that *look* like alternatives to systemd, but they're not intended to work that way. The one and only service manager for SUSE distributions is systemd.
==== Service manager. Does that include logging as provided by syslog/ng-syslog/rsyslog? Does it include boot-load functions (grub/lilo,etc?) I'm trying to narrow down what it is required for being "OpenSUSE", vs. where it is allowed to use an alternative. For example, if the startup process was in ROM, and turned control over to systemd after the system's hardware and locally required resources were activated: is hardware initialization part of systemd? Or could control be passed to systemd after some custom hw-initialization?
Our sysvinit package does not ship sysvinit, only some of the auxiliary tools useful for LSB script compatibility. To my knowledge, there are no alternatives being shipped in *any* SUSE distribution, product, or service.
Any SUSE, or openSUSE?
真実はいつも一つ！/ Always, there's only one truth!
Yes, and if you would recognize it a being my truth, things would be so much simpler! :-) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 8/4/19 12:20 PM, L A Walsh wrote:
On 2019/08/03 00:50, Neal Gompa wrote:
Ignoring the fact that SUSE != openSUSE,
ya, true enough, though that make it sound like the answers for the two are different. Is SUSE shipping alternatives for service control that openSUSE is not? If that's the case, why would they provide an alternative where openSUSE has not?
Other then in the SLE 11 SP4 LTSS, SUSE does not ship an init system other then systemd, due to SUSE's "Factory First" policy if they did you'd also find it in tumbleweed. This excludes certain things like some limited containers that don't really have any init system. Beyond that In SLE 15, openSUSE Leap and Tumbleweed, almost all configuration files that other init systems could use to start applications / daemons such as sysvinit scripts have been removed from packages. Further to that no one has put in any effort to making it possible to use an init system other then systemd in openSUSE (Several years back a small group started some work on this and quickly decided it would take more effort then they had time to put in so they stopped). so as a result of that it is safe for developers / packagers / anyone else to assume that systemd is the only init system available on openSUSE and relevant to this discussion that by the time PID 1 is started /usr will be part of the filesystem. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2019/08/04 02:46, Simon Lees wrote:
Further to that no one has put in any effort to making it possible to use an init system other then systemd in openSUSE (Several years back a small group started some work on this and quickly decided it would take more effort then they had time to put in so they stopped).
so as a result of that it is safe for developers / packagers / anyone else to assume that systemd is the only init system available on openSUSE and relevant to this discussion that by the time PID 1 is started /usr will be part of the filesystem.
I find that mounting /usr/{bin,lib,lib64,sbin} on /{...}, is relatively trivial** on my setup. FWIW, I mount /usr in the 1st boot script to maximize compatibility after that. **--just because it is trival doesn't mean I would want to do it as it brings a cost. Rather than having a lightweight "miniboot"/rescue in root, I'd have a 65G partition at over 70% usage. Given how often I need to restore a file due to some self-inflicted shot in the foot, a restore would take significantly longer, if I had the disk space for it. Whether I'm doing development or not, it's still true that I'm an engineer and scientist that experiments and sometimes needs to clean up a mess. AFAIK, systemd doesn't allow you to bring up your system to full running, for example, from an emergency boot. To Be clear -- there are several good features in systemd that I like. I've said so for years, but I didn't like the way it was designed to be monolithic such that you have to accept it being pid 1 and its process control to get anything else. I work on scripts to support undoing port-damage and my system. Most things are in the 'need to write code' phase, though I haven't fully thought through my 'init' replacement, as I need to provide a way to capture dead pids so I can provide them to a subscriber that might need them. Just like linux allows multiple schedulers, and multiple security models, I can't see how resource control might not also be a place for multiple models. It also seems a bit myopic to not provide a way for different monitors to have access to the list of dead pids caught by pid 1. As for merging things. Have you thought of using a base of binaries in /bin that supports a miniroot, and then mounting /usr/bin via the overlay-fs, though you could mount /bin on /usr/bin and then mount the rest of usr/bin from another dir as an overlay over the original /usr/bin that contained boot+repair binaries). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sun, Aug 4, 2019 at 7:46 AM L A Walsh <suse@tlinx.org> wrote:
On 2019/08/04 02:46, Simon Lees wrote:
Further to that no one has put in any effort to making it possible to use an init system other then systemd in openSUSE (Several years back a small group started some work on this and quickly decided it would take more effort then they had time to put in so they stopped).
so as a result of that it is safe for developers / packagers / anyone else to assume that systemd is the only init system available on openSUSE and relevant to this discussion that by the time PID 1 is started /usr will be part of the filesystem.
I find that mounting /usr/{bin,lib,lib64,sbin} on /{...}, is relatively trivial** on my setup.
FWIW, I mount /usr in the 1st boot script to maximize compatibility after that.
**--just because it is trival doesn't mean I would want to do it as it brings a cost. Rather than having a lightweight "miniboot"/rescue in root, I'd have a 65G partition at over 70% usage. Given how often I need to restore a file due to some self-inflicted shot in the foot, a restore would take significantly longer, if I had the disk space for it.
Whether I'm doing development or not, it's still true that I'm an engineer and scientist that experiments and sometimes needs to clean up a mess. AFAIK, systemd doesn't allow you to bring up your system to full running, for example, from an emergency boot.
That's not true. In an emergency boot scenario (particularly early boot failures), you have the opportunity to fix the issue and then have systemd attempt to continue to normal boot without restarting. If that's not working in SUSE distributions, then there's a problem. I've used that in the past on CentOS and Fedora, so I know the facility exists.
To Be clear -- there are several good features in systemd that I like. I've said so for years, but I didn't like the way it was designed to be monolithic such that you have to accept it being pid 1 and its process control to get anything else.
Actually, most of the supplementary services provided by the systemd project don't require systemd running as pid 1. systemd requires the journal, but I don't think any service requires systemd. Certainly nspawn and udev can be used without systemd as pid 1.
I work on scripts to support undoing port-damage and my system. Most things are in the 'need to write code' phase, though I haven't fully thought through my 'init' replacement, as I need to provide a way to capture dead pids so I can provide them to a subscriber that might need them.
Just like linux allows multiple schedulers, and multiple security models, I can't see how resource control might not also be a place for multiple models.
It also seems a bit myopic to not provide a way for different monitors to have access to the list of dead pids caught by pid 1.
As for merging things. Have you thought of using a base of binaries in /bin that supports a miniroot, and then mounting /usr/bin via the overlay-fs, though you could mount /bin on /usr/bin and then mount the rest of usr/bin from another dir as an overlay over the original /usr/bin that contained boot+repair binaries).
The need for this is obviated by our usage of initramfs for early boot, which is a more flexible mechanism that serves this purpose already. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2019/08/04 05:11, Neal Gompa wrote:
The need for this is obviated by our usage of initramfs for early boot, which is a more flexible mechanism that serves this purpose already.
Even though systemd devs recommended booting from disk to increase speed? Where's that option in Suse's roadmap? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sun, Aug 4, 2019 at 10:55 AM L A Walsh <suse@tlinx.org> wrote:
On 2019/08/04 05:11, Neal Gompa wrote:
The need for this is obviated by our usage of initramfs for early boot, which is a more flexible mechanism that serves this purpose already.
Even though systemd devs recommended booting from disk to increase speed? Where's that option in Suse's roadmap?
That's a recommendation I've never heard from them for general purpose systems. I fully expect us to never have that option out of the box, but there are tools to make it so that *can* work. They do, however, recommend moving towards Bootloader Spec. However, there's a number of hurdles in the way for doing so in SUSE distributions. The primary hurdle is the lack of bls support in SUSE's grub2 package. There are some other issues related to YaST, snapper, etc. too. Perhaps someday soon it'll be in openSUSE... -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On nie, sie 4, 2019 at 5:30 PM, Neal Gompa <ngompa13@gmail.com> wrote:
On Sun, Aug 4, 2019 at 10:55 AM L A Walsh <suse@tlinx.org> wrote:
On 2019/08/04 05:11, Neal Gompa wrote:
The need for this is obviated by our usage of initramfs for early boot, which is a more flexible mechanism that serves this purpose already.
Even though systemd devs recommended booting from disk to increase speed? Where's that option in Suse's roadmap?
That's a recommendation I've never heard from them for general purpose systems.
I fully expect us to never have that option out of the box, but there are tools to make it so that *can* work.
They do, however, recommend moving towards Bootloader Spec.
However, there's a number of hurdles in the way for doing so in SUSE distributions. The primary hurdle is the lack of bls support in SUSE's grub2 package. There are some other issues related to YaST, snapper, etc. too. Perhaps someday soon it'll be in openSUSE...
Besides, some of the limitations that come with the spec (although aren't present in grub implementation in Fedora/RHEL) are the lack of subdirectories for boot entries as well as the lack of ability of booting linuz/initrd from non-boot partitions. openSUSE by default has boot partition set to /boot/efi, and keeps the kernel and initrd in /boot, which prevents bls compatible software (namely systemd-boot) from working. This happens due to systemd-boot not mounting anything but the boot partition, while GRUB just mounts everything as it exists, slowing down the boot process, but allowing booting from each and every one of the devices present in the system. Why does openSUSE have boot partition mounted to /boot/efi? Snapshots. We can't have kernel and initrd in snapshots if the boot partition is FAT-like, so the /boot is mounted as a btrfs submodule, while /boot/efi is a FAT-like partition which can be used by EFI. A way to make systemd-boot work with existing structure would be to copy current initrd and linuz to /boot/efi on every new kernel install alongside a new bls entry file. It would finally justify the recommended size of the partition and make a giant mess of the filesystem stucture. A good question here is if we need kernels covered under snapshots, the older kernels along with initrd assigned to them are already accessible from GRUB either way. LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sun, Aug 04, Stasiek Michalski wrote:
A way to make systemd-boot work with existing structure would be to copy current initrd and linuz to /boot/efi on every new kernel install
We had this in the past. Don't ask me how many customers we had no longer able to update the kernel, as /boot/efi did run out of disk space.
A good question here is if we need kernels covered under snapshots, the older kernels along with initrd assigned to them are already accessible from GRUB either way.
Yes, we need them. But what we don't need is keeping the latest kernels installed in parallel ... Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2019/08/04 09:13, Stasiek Michalski wrote:
Besides, some of the limitations that come with the spec (although aren't present in grub implementation in Fedora/RHEL)
Why not? Should we be using that version?
are the lack of subdirectories for boot entries as well as the lack of ability of booting linuz/initrd from non-boot partitions. openSUSE by default has boot partition set to /boot/efi, and keeps the kernel and initrd in /boot, which prevents bls compatible software
"bls-compatible?"
(namely systemd-boot) from working. This happens due to systemd-boot not mounting anything but the boot partition, while GRUB just mounts everything as it exists, slowing down the boot process, but allowing booting from each and every one of the devices present in the system.
For speed, would it be impossible to only load the kernel you want to boot from using lilo? I use lilo and go from boot to multi-user prompt in about 20-25s. I'm not using an SSD, but a 3-disk RAID 5 for boot (HW RAID).
Why does openSUSE have boot partition mounted to /boot/efi? Snapshots. We can't have kernel and initrd in snapshots if the boot partition is FAT-like, so the /boot is mounted as a btrfs submodule, while /boot/efi is a FAT-like partition which can be used by EFI.
--- Nothing supports snapshot except btrfs? FWIW, I can probably backup and restore my boot partition in less time than it would take someone to restore a snapshot (boot is only 206M used), root 3.2G and /usr 12G), though I certainly don't have snapshot granularity. from kernel unpack + hardware probe to mount of root: 6.2s /boot -> mount of root is 6.204s; init stars at 6.25s init @ 6.25s /usr mounted @ 6.88s module loading from disk network cards init xfs mount of 48TB storage (192TB as RAID10)12.98-13.42s then 6s for the server services to come up to multi-user login prompt.
A way to make systemd-boot work with existing structure would be to copy current initrd and linuz to /boot/efi on every new kernel install alongside a new bls entry file. It would finally justify the recommended size of the partition and make a giant mess of the filesystem stucture.
A good question here is if we need kernels covered under snapshots, the older kernels along with initrd assigned to them are already accessible from GRUB either way.
LCP [Stasiek] https://lcp.world
--- Without initrd, your kernels could be alot smaller. I seemto remember going through a disk analysis sometime back on the opensuse list, and kernel+initrd took about 20M more/version. My kernels run about 6.9m in 4.17 and 7.5m in 5.2.4. with my lib/modules taking from 21M->29M for 4.17->5.24, but I modularize just about every possible kernel option that I might want to try. With, I think wicked, it could be adapted to build a bootable kernel for customers that wanted it (no ramdisk required). 'sgi' and other unix vendors did that for their customers 20 years ago -- provided a script to make a direct-bootable kernel without a bunch of extra HW options, so I'm pretty sure it would be doable today.
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 8/5/19 5:58 AM, L A Walsh wrote:
On 2019/08/04 09:13, Stasiek Michalski wrote:
Besides, some of the limitations that come with the spec (although aren't present in grub implementation in Fedora/RHEL)
Why not? Should we be using that version?
are the lack of subdirectories for boot entries as well as the lack of ability of booting linuz/initrd from non-boot partitions. openSUSE by default has boot partition set to /boot/efi, and keeps the kernel and initrd in /boot, which prevents bls compatible software
"bls-compatible?"
(namely systemd-boot) from working. This happens due to systemd-boot not mounting anything but the boot partition, while GRUB just mounts everything as it exists, slowing down the boot process, but allowing booting from each and every one of the devices present in the system.
For speed, would it be impossible to only load the kernel you want to boot from using lilo? I use lilo and go from boot to multi-user prompt in about 20-25s. I'm not using an SSD, but a 3-disk RAID 5 for boot (HW RAID).
Why does openSUSE have boot partition mounted to /boot/efi? Snapshots. We can't have kernel and initrd in snapshots if the boot partition is FAT-like, so the /boot is mounted as a btrfs submodule, while /boot/efi is a FAT-like partition which can be used by EFI.
--- Nothing supports snapshot except btrfs? FWIW, I can probably backup and restore my boot partition in less time than it would take someone to restore a snapshot (boot is only 206M used), root 3.2G and /usr 12G), though I certainly don't have snapshot granularity.
I somewhat doubt that, given restoring a snapshot is as simple as selecting an item in grub, booting running a single command then rebooting for good measure. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 8/4/19 9:16 PM, L A Walsh wrote:
On 2019/08/04 02:46, Simon Lees wrote:
Further to that no one has put in any effort to making it possible to use an init system other then systemd in openSUSE (Several years back a small group started some work on this and quickly decided it would take more effort then they had time to put in so they stopped).
so as a result of that it is safe for developers / packagers / anyone else to assume that systemd is the only init system available on openSUSE and relevant to this discussion that by the time PID 1 is started /usr will be part of the filesystem.
I find that mounting /usr/{bin,lib,lib64,sbin} on /{...}, is relatively trivial** on my setup.
FWIW, I mount /usr in the 1st boot script to maximize compatibility after that.
**--just because it is trival doesn't mean I would want to do it as it brings a cost. Rather than having a lightweight "miniboot"/rescue in root, I'd have a 65G partition at over 70% usage. Given how often I need to restore a file due to some self-inflicted shot in the foot, a restore would take significantly longer, if I had the disk space for it.
Whether I'm doing development or not, it's still true that I'm an engineer and scientist that experiments and sometimes needs to clean up a mess. AFAIK, systemd doesn't allow you to bring up your system to full running, for example, from an emergency boot.
To Be clear -- there are several good features in systemd that I like. I've said so for years, but I didn't like the way it was designed to be monolithic such that you have to accept it being pid 1 and its process control to get anything else.
I work on scripts to support undoing port-damage and my system. Most things are in the 'need to write code' phase, though I haven't fully thought through my 'init' replacement, as I need to provide a way to capture dead pids so I can provide them to a subscriber that might need them.
Just like linux allows multiple schedulers, and multiple security models, I can't see how resource control might not also be a place for multiple models.
It also seems a bit myopic to not provide a way for different monitors to have access to the list of dead pids caught by pid 1.
As for merging things. Have you thought of using a base of binaries in /bin that supports a miniroot, and then mounting /usr/bin via the overlay-fs, though you could mount /bin on /usr/bin and then mount the rest of usr/bin from another dir as an overlay over the original /usr/bin that contained boot+repair binaries).
I'm not saying that many of these things aren't possible or easy but openSUSE is a place where nothing will happen unless someone decides to do it, and currently no one is deciding to put the effort into maintaining and supporting anything other then systemd on openSUSE. Honestly whatever your doing in your personal setup is irrelevant here unless you wish to start packaging and supporting it for openSUSE. This is the openSUSE development list where the people working on openSUSE discuss the future development of openSUSE. So far I can't see where any of the points you raise are relevant to this discussion. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2019/08/04 02:46, Simon Lees wrote:
Further to that no one has put in any effort to making it possible to use an init system other then systemd in openSUSE (Several years back a small group started some work on this and quickly decided it would take more effort then they had time to put in so they stopped).
so as a result of that it is safe for developers / packagers / anyone else to assume that systemd is the only init system available on openSUSE and relevant to this discussion that by the time PID 1 is started /usr will be part of the filesystem.
I find that mounting /usr/{bin,lib,lib64,sbin} on /{...}, is relatively trivial** on my setup. FWIW, I mount /usr in the 1st boot script to maximize compatibility after that. **--just because it is trival doesn't mean I would want to do it as it brings a cost. Rather than having a lightweight "miniboot"/rescue in root, I'd have a 65G partition at over 70% usage. Given how often I need to restore a file due to some self-inflicted shot in the foot, a restore would take significantly longer, if I had the disk space for it. Whether I'm doing development or not, it's still true that I'm an engineer and scientist that experiments and sometimes needs to clean up a mess. AFAIK, systemd doesn't allow you to bring up your system to full running, for example, from an emergency boot. To Be clear -- there are several good features in systemd that I like. I've said so for years, but I didn't like the way it was designed to be monolithic such that you have to accept it being pid 1 and its process control to get anything else. I work on scripts to support undoing port-damage and my system. Most things are in the 'need to write code' phase, though I haven't fully thought through my 'init' replacement, as I need to provide a way to capture dead pids so I can provide them to a subscriber that might need them. Just like linux allows multiple schedulers, and multiple security models, I can't see how resource control might not also be a place for multiple models. It also seems a bit myopic to not provide a way for different monitors to have access to the list of dead pids caught by pid 1. As for merging things. Have you thought of using a base of binaries in /bin that supports a miniroot, and then mounting /usr/bin via the overlay-fs, though you could mount /bin on /usr/bin and then mount the rest of usr/bin from another dir as an overlay over the original /usr/bin that contained boot+repair binaries). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 2019-07-23 14:03, Daniel Molkentin wrote:
it is my understanding that openSUSE will no longer boot without /usr being around. A long time ago I hence opened https://bugzilla.suse.com/show_bug.cgi?id=1029961, with all the apps that I could find as subtickets. The suggestion was move all apps to /usr, and symlink /bin and /sbin, a step performed by Fedora a while ago.
So far I can see: [...]
- People have a hard time telling which binary is where
How so? Does it matter where binaries are? (It should not!) Isn't there $PATH and, for everyone still confused, the "which" utility? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (10)
-
Christian Boltz -
Daniel Molkentin -
Jan Engelhardt -
L A Walsh -
Michael Ströder -
Neal Gompa -
Simon Lees -
Stasiek Michalski -
Stefan Seyfried -
Thorsten Kukuk