[systemd-devel] PredictableInterfaceNames and Debian

[Xen]

Reindl was trying to give me links on Debian.

Andrei alluded to the fact that the infrastructure has been removed.

Indeed in systemd 215 in Debian the file
/lib/udev/rules.d/75-persistent-net-generator.rules still exists, but in
220 it was removed.

The original solution was a persistent file written to /etc.

Every other operating system probably uses a persistent state.

Three reasons were named:

- race conditions in renaming to the same namespace
- unwriteable /etc
- doesn't work in VMs

If writing persistent configuration information to any filesystem is an
impossibility anyway, you have a very limited system to begin with.

This is a kind of design choice that steers the directions you can go,
and if the design choice is inelegant, so too will be your solutions.

Personally I think it is a bad -- a terribly bad -- choice to begin with.

Persistence is the obvious solution but now you're not allowed to use it
and then people say that the (kernel) devs know what they are doing.

A system that cannot save autoconfiguration data is just a flawed system.

The model arises in which only an administrator can configure something
by willful choice, but the system cannot aid you in that.

The system therefore cannot remember what devices existed on the
previous boot.

At once that is the strength of Linux: you can basically run a system on
any hardware and it will basically run.

And it is the horror that plagues windows, as a Windows installation can
only be migrated to different hardware with specialist tools.

It is not really inherent in the design choice to save persistent data
though, but in your inability to cope with changing conditions.

Most of what those tools do that I mentioned is fixing missing
drivers........

As far as I can tell anyway.

Basically from my perspective the solution that existed was perfect
although the udev rule syntax is not that easy for a user to change or
understand.

But now we have a solution that revolves around not being able or
allowed to write persistent data.

And in order to be persistent now it is attempted to use stuff that
normally doesn't change, except when you add or remove hardware, then it
does change, and the resulting system does not alias anything but just
encodes the addresses into the names.

In order to solve a problem without being able to use the real solution.

All because we don't want or sometimes cannot have writable filesystems
at boot.

So the stuff I wrote in ": Solution for a desktop OS" was merely meant
to simulate something that would resemble real persistency by increasing
the chances that the boot process would end up with the same solution
every time. Simply by renaming stuff after all onboard/pci non-pluggable
devices had (hopefully) been found. Not a real solution, but the closest
I can think of given that a real solution is not possible (or has been
removed).

And why networking has to be online before the root fsck has been
completed: I don't know.

And if you did need to write stuff: why not queue the changes and then
apply them after the remount rw, if that is necessary? Create an overlay
to /etc ;-), write stuff to the overlay, then remount, freeze access,
and write the changed files to the real /etc ;-).

"Changes are being held until a moderator has approved it".

I'm just saying here it's rather obvious you'd end up with something
ugly if you could not use the solution that was intended for such things.

Now you require users to go out of their way manually to write changes
to /etc using ill-understood formats or hard-to-find man pages.

Without ANY of the advantages of a system (such as udev, I guess) that
can dynamically update the device list, remove devices that are no
longer there, add new ones, or move them from one hardware position to
another.

And then you say you have created the best solution. But it is so
dreadfully lacking. And then some of you say : Well, if you want it, you
can do it on your own!!!!!.

Sure, I can do what you haven't been able to or that you didn't choose
to enable. And even removed from existence.

A flaw in design will not be so bad if the system is small. The bigger
the system is that is built on a flawed design, the bigger the flaws
will become.

LVM can merge snapshots back into the main filesystem, why can't you? I
mean - postponed writing.

The whole /run -> /var/run was something people riled against as well.

I am saying that from my perspective this whole ro shit is causing a
bagload of trouble. "/var may be on another filesystem that is not
mounted yet" well yeah, then just fix that issue by creating a dedicated
writable /var that always needs to be present. Ensure that some piece of
the root filesystem or its essential "neighbours" is going to be
writable. People mount /var elsewhere but probably mostly for writing
log files or keeping databases or whatever. That mixes up a lot of
goals. If the root filesystem is writable, use the root filesystem. If
it is not, use something else that is. But don't do away with real,
persistent, writable filesystems.

Keep a place where the core system can maintain persistent data.
Separate "core" from "user" if you must. The /run we have now did create
a seperation with "user" mode /var files, but we lost real persistent
writability!!.

So it seems Linux has been moving in the direction of really losing that
ability.

Problem: the kernel/boot system cannot write persistent data.

SOLVE THAT.

There are only three ways:

1. Postpone writing as described
2. Ensure a real writeable filesystem from the moment it is required
3. Give up and explode and try again next time.

I think the mainline kernel has what is known as "overlayFS" -- if you
enable an atomic remount operation that merges the overlay with the now
rw filesystem beneath, you will have solved the issue in a general sense.

The only other solution falls along the lines of:
- Just don't do anything until you have fscked
- That almost sounds like fucked.

- Create a form of independent filesystem that can be independently
checked (such as /boot).
- Other solutions require massive requirements (add another partition,
require the use of LVM, require the use of btrfs
probably/perhaps/likely, all things that require the enablement of
contested technologies or unnecessary or unwanted extras).

>From these solutions requiring an independent /boot and writing to IT is
probably the most likeable and achieveable.

So basically you *could* combine overlayFS with tempFS (tmpfs) and
enable automatic merging on atomic remount. Maybe not as pretty. But
could work.

The only other thing that comes to mind is: why on EARTH is it so
difficult to fsck a mounted filesystem when I don't remember having done
anything else ever in MS Windows? Today some operations are scheduled
for reboot, true. But you could for instance easily defrag while the
system was in use and many other thing were possible. It was NEVER as
hard as it is in Linux. However Windows can fsck during boot just fine
and still keep persistent network records or whatever it is doing.

So I don't know much and I don't know everything and sometimes I don't
know anything at all, but this is just what it seems to me.

Regards, Bart Schouten.