Devuan, anyone?


Plume said:
Not really.
Let's suppose a mount fails. What should happen next ?
Obviously, if / (or /bin, /usr, /home) doesn't mount, the answer is quite easy, most of the time.
However, let us suppose /thing/weird/dir doesn't mount, what should happen ? Maybe something in /etc requires something there, so the boot should fail, but how could systemd know this ?
Click to expand...
Nothing. Why should anything happen? It should put an error in the log and continue trying to boot. If it reaches a point where it can go no further due to the missing volume. *then* it should drop back to the recovery console if necessary. If the volume is critical to the boot process it should be marked as such, in which case it would still stop at this point if missing.

-Neelix
 
Well, this is a quite optimistic point of view.
Having the safest possible default, not trying to boot in an unknown state, seems, at least for me, the sanest thing to do. If somebody wants to do something less safe, he may configure it, but he should state that.
 
Plume said:
Well, this is a quite optimistic point of view.
Having the safest possible default, not trying to boot in an unknown state, seems, at least for me, the sanest thing to do. If somebody wants to do something less safe, he may configure it, but he should state that.
Click to expand...
Exactly this. If something fails it should stop right there unless it's been explicitly told it's OK to fail. Consider a /etc partition that fails to mount. All the system services may now start with some default configuration that can lead to vulnerabilities or overwriting stuff. Say /home fails to mount. Users are now writing to / partition and mounting will fail the next time since the mount directory is not empty. There's just so many things that can go wrong when your file system is not how you'd expect that the safest bet is to hit the breaks the moment anything unexpected goes wrong. You've got a broken system, you need to fix it or tell it beforehand not to care. Letting it slide like business as usual is a huge risk.
 
I think if they had abused the "pass" field (determines the order in which fsck should scan the drives, 0 disables checking) a lot less users would had protested. Fail with a warning if 0 (root device should always have this set to 1), else fail with a critical error.

If the drives are necessary for a proper boot they should have this set to 2 or greater anyway or you may boot with a corrupted partition (and possibly cause irreversible data loss as a consequence).

There are times where a system simply has to boot with whatever it has despite the risks. Take for example the Parrot AR.Drone, which has a Linux system for a flight controller. Say a power glitch makes the system reboot. Every filesystem is now marked as dirty, however that doesn't matter when you have half of a kilo worth of airframe accelerating towards the ground at an unknown speed.

The sane thing to do here is probably to mount the filesystem's as read-only and get on with stabilizing the aircraft, then auto land and throw an error in the face if the pilot. In this application systemd would definitely not recover gracefully in its default configuration while the classic sysvinit would (mount as ro on a failed fstab entry). This is the only safe way I see to resume the boot and many admins seem to agree.
 
Wow, in this one specific case the default sysvinit configuration would have been better than the default systemd configuration.
 
As already pointed out on the previous page

nofail
With nofail, this mount will be only wanted, not required, by local-fs.target or remote-fs.target. This means that the boot will continue even if this mount point is not mounted successfully
Click to expand...

http://www.freedesktop.org/software/systemd/man/systemd.mount.html

So in your usecase, quite rightly pointed out by the previous poster as being rather fringe, if an expensive drone is at stake, maybe just set options to meet the requirements? Just an idea. Or, if you don't like systemd, don't use it.
 
At what point do you become aware of what lengths systemd will extend to interrupt expected and normal behaviour?
It would most probably be when something like this happens. At which point the "should have" only becomes more of a reason to _not_ be shipping the broken behavior by default.

The "I cant troubleshoot this now on my one very non-critical machine" isn't an excuse.

Stopping without so much as throwing an error is not graceful.
 
Erroring without a sufficient log in the event of a mounting error, if true (and I'm not questioning that), is a legitimate criticism. I'm not going to defend that, it's bad. But it does not automatically make systemd bad, it's just one flaw, no software is perfect.

My point-of-view is, the decision makers behind the majority of the major distributions have chosen to adopt systemd, and they know more than me, and I trust their opinion. I use Arch, and as such I put my trust in whomever decides what goes into the Arch repos. They have much more knowledge and expertise at their disposal, they know the pros and cons of systemd, and they chose to make it a fundamental part of Arch as did a bunch of other distos. I don't think for a second that they made that decision lightly. I'm a user of systemd, and as such I have my own viewpoint and experience when it comes to systemd, but my experience is limited, I'm not helping run a major Linux distribution. I don't unquestioningly follow whatever the Arch overlords say, but I've found that distro to be best for me and I'll continue to use it until such a time as I think there's a better distro for me.

Same goes for the systemd functionality that you clearly disagree with. I don't doubt that Poettering is an egomaniac, but I also don't doubt that he's a clever and skilled software engineer. I have a view on whether boots should fail or not by default upon mount errors, but I think whomever made that decision with regards to systemd knows more about it than me, and gave the decision careful consideration. Just because you don't like their decision, doesn't make you right. People have already posted in this thread pretty coherent arguments as to why the systemd devs might have made the decision that they did regarding defaults.

At the end of the day, it's open source software with a public bugtracker. Maybe your time would be better spent logging a bug about the mounting issue. But that's not really the issue is it? You just hate systemd, and you'll blow every issue up out of all proportion because hating on systemd is like a religion.
 
kaprikawn said:
As already pointed out on the previous page



http://www.freedesktop.org/software/systemd/man/systemd.mount.html

So in your usecase, quite rightly pointed out by the previous poster as being rather fringe, if an expensive drone is at stake, maybe just set options to meet the requirements? Just an idea. Or, if you don't like systemd, don't use it.
Click to expand...

I dropped the link explaining the nofail option on the previous page, my whole point was that you can't judge any piece of software based on the default configuration alone.

What I was trying to say above was that the defaults of sysvinit was less likely to cause problem on an unconfigured system. The example may have backfired though as obviously if you're designing something as critical as a flight controller then it's naive to the point of stupidity to rely on default configurations.

I am however a big believer is sane defaults, which is part of the reason why I use Debian on my machines (mostly though I just really like the APT infrastructure). Thus I am indeed running systemd myself but I'm not saying one is better than the other. One should be free to choose for oneself and as far as I can tell Debian leaves that option.
 
Sane defaults are great, but their actual values are debatable. Sane for one is insane for another. I'd put "least potential permanent damage assuming physical safety" as the first priority, then maybe "best guess for most users" as the second.
 
bzar said:
Sane defaults are great, but their actual values are debatable. Sane for one is insane for another. I'd put "least potential permanent damage assuming physical safety" as the first priority, then maybe "best guess for most users" as the second.
Click to expand...

Very true. In this case I think the most abused Star Trek quote is still appropriate; "the needs of the many outweigh the needs of the few".

That said perhaps we should drop a comment in fstab about the nofail option just to be safe, this is the cause of most issues I've seen about systemd anyway (based purery on personal observations). Something simple like "# To tell systemd an entry is nonessential at boot, add the 'nofail' option'". Most users modifying fstab will see that and hopefully save them from a few minutes of trying to make their system boot again.
 
Hope necro is ok here. I'm not interested in the pros/cons debate, just wondering how well supported Devuan is. I understand some software has been optimised for the Pyra but I'm not savvy enough to go through it all and confirm compatibility before committing to purchase. I imagine this thread has been viewed by others like myself who simply did not care enough to make an account.

Question 1: How well will Devuan (or a SysD purged Debian) work upon base install? This can be read as, "how significant are the Debian optimisations"?

Question 2: If any of the optimisations do depend on SystemD, which ones? How important are they and how difficult would it be to build them in a compatible manner?

In the interest of pacifying debate, Devuan and Debian are largely identical so it would be ideal to support both options. If the software optimisations rely on SystemD, that's fine with me; I just hope Devuan users will still be welcome in this forum without having to struggle through these debates in every thread.
 
Unless aTc wrote them for both init systems, some scripts like the ones that turn on the SGX drivers and such may need to be converted for sysvinit, outside of that I don't foresee too many hiccups.
 
Ok, that's great information. Thank you both. I probably won't be playing any 3d games any time soon but it might be nice for simple application acceleration or prolonging the battery life. Not sure how much of a difference it would actually make but that's something I can test myself if necessary. Maybe Linux-SWAT has already tested it?

For the sake of accessibility, and in the interest of documentation, I'm going to be honest and say that I spent 25 minutes trying to figure out what SGX is. The acronym is buried under Intel's Software Guard Extensions, but I assume that shouldn't apply since Pyra is supposed to use an ARM processor. Us muggles got to help each other out.

I found one old reference (link-1 below) to AM35x-OMAP35x graphics SDK using dedicated hardware "...based on SGX series of devices from Imagination Technologies" for 3D acceleration. I'm don't know if information is still relevant since that wiki page is "...no longer maintained and is being kept for reference only! " but Is this what you're talking about? A quick search for "Coretex A15 SGX" a lot of useless misassociations and finally a wiki page (link-2) that suggests PowerVR SGX544MP2 is somehow used in conjunction with T.I. OMAP5430, OMAP5432, and AM57x. Also mentions an "IT PowerVR SGX544MP3 (tri-core)" for Exynos 5 Octa. Sorry for being new here but I think the OMAP5xxx is used for Pyra? The home page (pyra-handheld.com) just says the C.P.U. is a Cortex A15. I'll take a look at the Pyra wiki in a bit and see if I can make sense of it but I assume one of the "Q2 2013" A15 models is used in the Pyra, or perhaps a newer model that is not listed on the Wiki. Not sure what PowerVR chip is used.

Link-1: http://processors.wiki.ti.com/index.php/AM35x-OMAP35x_Graphics_SDK_Getting_Started_Guide

Link-2: https://en.wikipedia.org/wiki/ARM_Cortex-A15

P.S., I couldn't figure out what the default font is so pasting in text may have screwed things up. I'll just change all text to size 4 and hope for the best.
 
Last edited:
Nope, didn't test extensively, I'm mostly working on Slackware, but I wanted to make sure to be able to bring back the PyraOS to the good side of the Force.
 
You must log in or register to reply here.

Similar threads

ClockworkCoder
Suckless - "Do one thing and do it well"
2 3
Replies
51
Views
15K
levi
levi
L
Nes Elite....?
Replies
15
Views
4K
lubidog
L
Kelvin
I'm worried about the Pyra's market performance.
2 3
Replies
51
Views
19K
second exodous
second exodous
ClockworkCoder
Preparing for the countdown...
2 3 4
Replies
63
Views
11K
levi
levi
K
Anyone Still Selling Replacement Control Stick?
Replies
7
Views
1K
Shaun
Shaun
Back
Top