[systemd-devel] PredictableInterfaceNames and Debian

[Reindl Harald]

honestly: what about just create your own operating system and leave us 
all in peace with endless mails mixing a dozen of rarely topics or just 
use a distribution like RHEL/CentOS/Fedora where you can just use 
ifup/ifdown scripts and tie MAC-address and interface-names togehter?


 > 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

like fsck *lol*

 > But you could for instance easily defrag while the
 > system was in use and many other thing were possible

you can do the same with "e4defrag /"
so *what* is your problem?

Am 16.04.2016 um 18:46 schrieb 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20160416/e80e746a/attachment.sig>