1. Home
  2. Raspberry Pi Group
  3. Raspbian and systemd
  4. Page 2

Raspbian and systemd

I should have written 'rationale' ^^^^^^^^

Its not a point for or against systemd.

Back when UNIX was a mere pup and 60MB was still a big disk there was a clear split:

- /bin and /sbin were on the boot disk and contained the executables needed to boot the system: they all had to be on the boot disk or Unix would not boot

- the remainder of a system of any size was spread over one or more additional disks which were mounted once the kernel and essential daemons were up and running. This included the compilers, applications and utilities which were never needed during the boot and, because /usr was often on a separate disk, they were held in /usr/bin and /usr/sbin

I realise a lot of you know all this, but its worth restating it to make the reason for having both /bin and /usr/bin as well as /sbin and /usr/ sbin crystal clear.

However, when we got to the point of thinking that even a 1GB disk was ridiculously small, a number of developers seem to have forgotten the reasons behind the /bin /usr/bin split or, indeed, have never known there was a reason. So they randomly splattered their new masterpieces into either directory regardless of whether they were needed at boot time or not. That has now gone on for so long that rationalising it now would be almost impossible. Current disk sizes also mean that we simply don't need the split now and its only there as a nod to tradition: if you look carefully, you'll see that some current distros (Fedora for one) now put all executables in /usr/bin and make /bin a symlink to it.

My point is that this mess existed before systemd came along and could do with cleaning up.

The only split that really matters is the one between /bin or /usr/bin and /usr/local/bin - this remains really useful because it makes a clear and maintainable distinction between executables that are part of the distro and so are liable to be upgraded/replaced/removed at any time for reasons outside the control of the sysadmin. These are in /bin and /usr/ bin

OTOH locally developed executables, or those in distro-agnostic packages, should live in /usr/local/bin to keep them safe from being interfered with by distro upgrades and reinstalls.

Same goes for the split between /usr/lib and /usr/local/lib

You're blaming the wrong person.

The culprits here are all those developers who didn't understand reason for the /bin /usr/bin split and completely FUBARed it out of sheer ignorance. The best we can do now is clean house by getting rid of either /bin or /usr/bin.

More scripts etc have hard-coded references to /usr/bin than to /bin, so IMHO /bin should get the chop.

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
org       |
Reply to
Martin Gregorie
Loading thread data ...

It is. I remember the time when the whole Unix startup was done from one single /etc/rc file where everyone inserted the startup of their subsystem, either a single call to another script or a short sequence directly into the /etc/rc file, and it was a big mess. The editing was done manually or sometimes by installers that looked for / placed specific comment lines.

When the new "Sys5 init" system was developed, there also was resistance but at least it was only causing more load and slower startup, not incompatabilities like systemd causes. Apparently those developer were more capable than mr Poettering.

There have been other reasons, e.g. workstations where /usr was mounted on NFS on a server and /bin was local. That worked. With systemd that is impossible.

It is not a mess, it is a level of versatility that not every one uses but does not need to be "cleaned up".

I'm blaming the person who did not understand that mounting partitions is part of the startup process and needs to be done at the correct moment, i.e. when the system is ready for it and before the system requires the directories.

This has worked fine all the way through just before systemd, so the developer of systemd clearly is incapable when he cannot make it work.

Reply to
Rob

formatting link

"systemd itself is actually completely fine with /usr on a separate file system that is not pre-mounted at boot time. However, the common basic set of OS components of modern Linux machines is not, and has not been in quite some time."

See also

formatting link

and the referenced

formatting link

It is a mess, that has stuck around for historical reasons, and one that has been around for a while. systemd makes this mess more evident, but it didn't cause it.

[ snippage ]

// Christian

Reply to
Christian Brunschen

It boots. What did you expect?

It works fine. Did you encounter any problems?

Just stick the number in kernel command line. Quoting from manpage: 2, 3, 4, 5 Boot into the specified legacy SysV runlevel. These are equivalent to systemd.unit=runlevel2.target, systemd.unit=runlevel3.target, systemd.unit=runlevel4.target, and systemd.unit=runlevel5.target, respectively, and provided for compatibility reasons and to be easier to type.

systemctl isolate rescue.target

So change the default target from graphical.target to multi-user.target: systemctl set-default multi-user.target

(or change the symlink if you prefer).

--
Tomasz Torcz               RIP is irrevelant. Spoofing is futile. 
xmpp: zdzichubg@chrome.pl     Your routes will be aggreggated. -- Alex Yuriev
Reply to
Tomasz Torcz

it doesn't boot because most of what is required in /bin and /sbin are now in /usr and symlinked to /bin /sbin etc.

It also can not boot if /usr is on NFS .

Yes broken. Since /bin /lib /lib43 /sbin are sym links can't be done with out puting /usr/bin /usr/lib /usr/lib64 and /usr/sbin on separate partitions. Only other way is to make all of /usr ro which I don't want, since I require /usr/src/ to be rw.

init S

Why should I have to modify the environment? And where would I look, see init levels are easy.

Reply to
Baho Utot

In such cases your initramfs is supposed to mount /usr partition. If it doesn't, then you initramfs is busted.

I don't undestand you. First you talk about ?/bin /lib /lib64 /etc /sbin file systems? suggesting you made separate partitions for each of them. Then you talk about symlinks, which means you have everything on one filesystem. Then you throw ?I want those ro but I want part of them rw". Which is all conflicting and has nothing to do with systemd at all.

Indeed, systemd implements /dev/initctl interface. Thanks for reminding.

Errm, because you wanted to? It's the same as changing "initdefault:" in /etc/inittab in last century.

For various definitions of ?easy?. Their meaning differ between distributions. I prefer clear, full-text names and clear dependencies between them:

formatting link 

--
Tomasz Torcz               RIP is irrevelant. Spoofing is futile. 
xmpp: zdzichubg@chrome.pl     Your routes will be aggreggated. -- Alex Yuriev
Reply to
Tomasz Torcz

Dzieki, Tomasz, za post o tresci:

Oh, I've got it. You want to boot withot X11 once? Then stick ?systemd.unit=multi-user.target? in kernel command line within your boot loader. Or stick there numerical runlevel, if you have consistent mapping.

--
Tomasz Torcz               RIP is irrevelant. Spoofing is futile. 
xmpp: zdzichubg@chrome.pl     Your routes will be aggreggated. -- Alex Yuriev
Reply to
Tomasz Torcz

Dzieki, Tomasz, za post o tresci:

Oh, I've got it. You want to boot without X11 once? Then stick ?systemd.unit=multi-user.target? in kernel command line within your boot loader. Or stick numerical runlevel there, if you have consistent mapping.

--
Tomasz Torcz               RIP is irrevelant. Spoofing is futile. 
xmpp: zdzichubg@chrome.pl     Your routes will be aggreggated. -- Alex Yuriev
Reply to
Tomasz Torcz

rget:

within your

I can't speak for anyone else, but for me SystemD (and the way it was sneak ed in) has been an expensive disaster. As per usual with testing going to rele ase in the near future, when visiting locations I had been changing the reposit ories from wheezy to jessie. In the past that has always given a seamless upgrade.

However, on this occasion, at random intervals users were happily following my directions to get updates, and suddenly all sort of things broke... but only the following day when they switched on their computers - in some cases lea ving them at a command line - which they didn't understand, and in one case a complete lockup which totally panicked the poor girl.

Years of stability suddenly became as flaky as puff pastry. I'll never real ly trust debian again.

I've now gone round all the offices and re-installed squeeze from DVD, but made sure they have no ability to do updates at all. From here on, I'll manage security ones myself as and when needed.

The worst of all of this is that our ordinary users have now gone from total confidence in the system to the more usual (Microsoft induced) worry and doubt. I absolutely hate that in most cases the users had blamed themselves for 'doing it wrong' :( :(

--
W J G
Reply to
Folderol

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.