The complaint by the anti-systemd crowd is that the systemd crowd is actively promoting things becoming dependent on systemd. It's not that they can't maintain a systemd free distro, it's just that nobody wants to spend all of their time undoing the work of the village idiot. You must have missed the articles about organizing a Debian fork. Or the whole uselessd thing. If systemd would just keep their fingers out of everyone else's pie, nobody would much care what they do or don't do.
I have fixed the btrfs/systemd problem. I gave systemd the boot and now the VM just works.
It is actually kinda funny to me after hearing all the systemd can do anything! systemd is great, all hail systemd cheerleading not to mention the excessive delight of some of the fans that people might have problems avoiding it and then a really simple problem comes up and literally the whole community is stumped. Not just a little stumped, they actually have no idea how to handle the situation even in principle. Meanwhile, going back to sysvinit fixed it right up.
That's because they don't properly trim trees, they hack off whatever might be near the lines. If they would actually trim the trees so they don't look like the crippled survivors of a war, people wouldn't gripe.
There are a couple trees near me that they 'trimmed' such that they will almost inevitably fall over onto the road sooner or later. That's what happens when you cut all the branches off of one side. It's a classic "somebody else's problem now" sort of 'solution'
I would say a complete inability to mount a degraded btrfs (which figures heavily in future plans) is hardly some obscure bug.
As for use something else, that's my intention. I gave systemd it's shot and it failed miserably. A bug like that shows that they aren't even trying to make the thing robust.
The question I asked about a workaround is a fairly fundamental thing to not know about systemd. That is, how to get it to run something needed to meet dependencies and how to get it to not run something.
First, Abe wasn't any part of the government of the Confederacy so the obligation to openness didn't apply there.
However, no matter where you might draw the line for public disclosure, surely the executive has no right to keep Congress and the judicial branch in the dark as they have done with Stingray. I would go further and say that the existence and use of the tech should be publicly disclosed while I understand they may need to keep the operational details of a particular use secret until they either prosecute or abandon the investigation (but no longer).
Any longer than that and they have defied consent of the governed and lost all moral legitimacy.
Alas, if you DON'T ask, you'll still get the recommendations and even scolding if you ignore the unwanted advice.
Further, 'they' will continue dispensing that advice even as the evidence piles up against it. They won't stop giving that advice until they find an excuse to tell people they must not eat something else that most people enjoy.
To add to the fun, the 'science' behind all of these food and drug fads just isn't there.
I added a unit file to mount/var and gave it a "before" dependency on dbus
Yes, files declare themselves to be dependencies of other files. It's as rational and comprehensible as the joke 'COMEFROM' statement (think opposite of GOTO).
Especially funny. Rock Stars don't multi-task. They lock themselves away in a darkened office working on the currently interesting single problem until it is solved. Then they come out, decompress, and repeat.
Part of why they have rock star performance is that they don't multi-task and don't sit through endless meetings re-hashing yesterday's meeting.
It might work as a dirty hack, but I would really like to have my fstab not be hackery. Noauto is supposed to mean not mounted on boot after all. I do know that systemd isn't actually issuing the mount command. I also know that once in the emergency shell, a simple mount/aux works perfectly (showing that the fstab and dependencies are fine).
There should be a way to alter systemd's configuration to let mount -a take care of fstab.
I'm a bit skeptical that a.mount file will behave any better since it's still part of the systemd world that has already proven it isn't up to the task. I may try it though just to see if systemd failures are at all hackable short of twisting it to resemble sysV.
I think the many megaton explosive effect of a comet hitting the Earth and the resulting severe disruption of the weather and massive loss of life would probably make us forget all about the kilo of plutonium.
And still, all the fear would have been unfounded. Yes, from ESA's standpoint, it would be no consolation to know that the fear that was destroying them was unfounded.
Perhaps they should just say the space probes are powered by new and improved power pellets! (Pac Man approved!)
The point here is that of all of the advocates claiming systemd skeptics are just afraid of change and that systemd is just fine as is cannot seem to come up with a solution to this problem. It's almost as if they don't actually know anything about the software they advocate...
As for solutions, I know a free one involving going back to sysvinit. I'm not going to get paid support for a test installation. If a simple problem can't be solved simply, it will just be rated not ready for prime time.
It doesn't matter which it is, what I was using before didn't have it.
But beyond that, it refuses to tell me why it isn't just doing the right thing and none of the big systemd advocates here can seem to tell me how one might fix it or work around it.
Beyond that, the thing that is hanging up shouldn't exist in the first place. It has no business caring about anything but the identified (implicitly) dependence on/dev/disk/by-label/aux. Since that is present, it should attempt the mount. Were it designed with an appropriate philosophy, the part that is causing the problem wouldn't exist at all.
The way systemd seems resistant to workarounds is a real design problem IMHO.
All I see on various mailing lists is systemd people deeply confused and at a loss as to what should be done about this and similar problems that the old init system has handled flawlessly for a very long time. That suggests that systemd is not ready for production use. If there was a decent workaround for now, that could potentially be forgiven, but I have yet to see one offered.
It is a bit different. The label had been created correctly by udev in/dev/disk/by-label such that once it dropped me to the shell 'mount/aux' was all that was needed to mount the filesystem correctly. If I could just get systemd to actually try the mount command, it would be fine.
I honestly have no idea what systemd thought it was waiting for and the journal doesn't say. If it would just do what I say, it would be fine.
Is there really nowhere I can just add 'mount/aux' to make it do the right thing?
Slashdot Mirror
Uselessd addresses not only the packaging but the excessively tight coupling of components.
The fact that a small team could make such substantial changes shows that it really is a lack of maturity in the design/implementation of systemd.
That's actually dead simple to do. Most already have one that's been stable for years.
The complaint by the anti-systemd crowd is that the systemd crowd is actively promoting things becoming dependent on systemd. It's not that they can't maintain a systemd free distro, it's just that nobody wants to spend all of their time undoing the work of the village idiot. You must have missed the articles about organizing a Debian fork. Or the whole uselessd thing. If systemd would just keep their fingers out of everyone else's pie, nobody would much care what they do or don't do.
I have fixed the btrfs/systemd problem. I gave systemd the boot and now the VM just works.
It is actually kinda funny to me after hearing all the systemd can do anything! systemd is great, all hail systemd cheerleading not to mention the excessive delight of some of the fans that people might have problems avoiding it and then a really simple problem comes up and literally the whole community is stumped. Not just a little stumped, they actually have no idea how to handle the situation even in principle. Meanwhile, going back to sysvinit fixed it right up.
I have validated a systemd-less solution that should be good for a few years at least.
I already indicated I would simply not use systemd, I don't know why you keep telling me to do what I have indicated I am already doing.
I don't suppose you could toss me one of those links you found where the problem is actually solved, could you? I do like keeping options open...
All of the ones I saw consisted of a bunch of people shrugging and wondering what the proper way is to handle it might be.
That's because they don't properly trim trees, they hack off whatever might be near the lines. If they would actually trim the trees so they don't look like the crippled survivors of a war, people wouldn't gripe.
There are a couple trees near me that they 'trimmed' such that they will almost inevitably fall over onto the road sooner or later. That's what happens when you cut all the branches off of one side. It's a classic "somebody else's problem now" sort of 'solution'
Or get it for $253.
I would say a complete inability to mount a degraded btrfs (which figures heavily in future plans) is hardly some obscure bug.
As for use something else, that's my intention. I gave systemd it's shot and it failed miserably. A bug like that shows that they aren't even trying to make the thing robust.
The question I asked about a workaround is a fairly fundamental thing to not know about systemd. That is, how to get it to run something needed to meet dependencies and how to get it to not run something.
HAHAHAHAHAHAHAHAHA! Udev has existed for quite a while now (before systemd existed) and until very recently, had no dependencies on systemd.
First, Abe wasn't any part of the government of the Confederacy so the obligation to openness didn't apply there.
However, no matter where you might draw the line for public disclosure, surely the executive has no right to keep Congress and the judicial branch in the dark as they have done with Stingray. I would go further and say that the existence and use of the tech should be publicly disclosed while I understand they may need to keep the operational details of a particular use secret until they either prosecute or abandon the investigation (but no longer).
Any longer than that and they have defied consent of the governed and lost all moral legitimacy.
Alas, if you DON'T ask, you'll still get the recommendations and even scolding if you ignore the unwanted advice.
Further, 'they' will continue dispensing that advice even as the evidence piles up against it. They won't stop giving that advice until they find an excuse to tell people they must not eat something else that most people enjoy.
To add to the fun, the 'science' behind all of these food and drug fads just isn't there.
I added a unit file to mount /var and gave it a "before" dependency on dbus
Yes, files declare themselves to be dependencies of other files. It's as rational and comprehensible as the joke 'COMEFROM' statement (think opposite of GOTO).
Especially funny. Rock Stars don't multi-task. They lock themselves away in a darkened office working on the currently interesting single problem until it is solved. Then they come out, decompress, and repeat.
Part of why they have rock star performance is that they don't multi-task and don't sit through endless meetings re-hashing yesterday's meeting.
It might work as a dirty hack, but I would really like to have my fstab not be hackery. Noauto is supposed to mean not mounted on boot after all. I do know that systemd isn't actually issuing the mount command. I also know that once in the emergency shell, a simple mount /aux works perfectly (showing that the fstab and dependencies are fine).
There should be a way to alter systemd's configuration to let mount -a take care of fstab.
I'm a bit skeptical that a .mount file will behave any better since it's still part of the systemd world that has already proven it isn't up to the task. I may try it though just to see if systemd failures are at all hackable short of twisting it to resemble sysV.
Mod parent up!
I think the many megaton explosive effect of a comet hitting the Earth and the resulting severe disruption of the weather and massive loss of life would probably make us forget all about the kilo of plutonium.
That's 12 kilos for the SNAP minus the weight of batteries and associated chargers/management, solar panels , and heaters.
And still, all the fear would have been unfounded. Yes, from ESA's standpoint, it would be no consolation to know that the fear that was destroying them was unfounded.
Perhaps they should just say the space probes are powered by new and improved power pellets! (Pac Man approved!)
The point here is that of all of the advocates claiming systemd skeptics are just afraid of change and that systemd is just fine as is cannot seem to come up with a solution to this problem. It's almost as if they don't actually know anything about the software they advocate...
As for solutions, I know a free one involving going back to sysvinit. I'm not going to get paid support for a test installation. If a simple problem can't be solved simply, it will just be rated not ready for prime time.
Words just can't express the level of warm fuzzies I get with that cylon staring at me for 90 seconds each time I try to boot!
It doesn't matter which it is, what I was using before didn't have it.
But beyond that, it refuses to tell me why it isn't just doing the right thing and none of the big systemd advocates here can seem to tell me how one might fix it or work around it.
Beyond that, the thing that is hanging up shouldn't exist in the first place. It has no business caring about anything but the identified (implicitly) dependence on /dev/disk/by-label/aux. Since that is present, it should attempt the mount. Were it designed with an appropriate philosophy, the part that is causing the problem wouldn't exist at all.
The way systemd seems resistant to workarounds is a real design problem IMHO.
All I see on various mailing lists is systemd people deeply confused and at a loss as to what should be done about this and similar problems that the old init system has handled flawlessly for a very long time. That suggests that systemd is not ready for production use. If there was a decent workaround for now, that could potentially be forgiven, but I have yet to see one offered.
That would be a good safety measure except that there's nothing to prevent the pollen from giving a neighboring crop the terminator trait.
You've never heard of terminator seeds, have you?
The seeds will grow normally but the seeds from the grown plants will die upon germination.
Nobody?!?
All the systemd fans here and not one can show the skeptic how easy it all is? How much better?
Bueller?
It is a bit different. The label had been created correctly by udev in /dev/disk/by-label such that once it dropped me to the shell 'mount /aux' was all that was needed to mount the filesystem correctly. If I could just get systemd to actually try the mount command, it would be fine.
I honestly have no idea what systemd thought it was waiting for and the journal doesn't say. If it would just do what I say, it would be fine.
Is there really nowhere I can just add 'mount /aux' to make it do the right thing?