[00:16] robert_ancell_: Thats difficult, because its difficult to transition users from using one shortcut to another. The installer still offers both, although the desktop uses the newer shortcut, super + alt + s. Probably worth changing to be consistant. [00:16] TheMuso`, so should we make u-g do both in trusty? [00:16] seb128 was concerned about changing the existing key combo [00:17] robert_ancell_: Is that hard to do? Afaik we offer the shortcut via the menu shortcut stuff atm. [00:18] robert_ancell_: Particularly since the menu shows the shortcut as well. [00:18] TheMuso`, harder than backporting the fix but shouldn't be too hard to change the default to alt+ctrl+s and also support ctrl+s [00:18] Alt + super + S, and yeah sounds good. [00:18] as well as control + s. [00:19] yeah, that one :) === TheMuso` is now known as TheMuso [04:56] Good morning [04:58] hello pitti [05:00] hey desrt, how are you? [05:00] okay [05:00] just writing some NEWS [06:04] good morning [06:08] bonjour didrocks, ça va ? [06:15] good morning! [06:16] pitti: ça va bien, et toi ? [06:16] good morning larsu ! [06:20] hum, keybindings don't work, restarting session [06:20] and while I'm at it, rebooting under upstart for a test [06:24] good luck ;) [06:24] interesting, pressing escape on plymouth even on upstart just shows a blank screen, we don't display /dev/console here, maybe only failing jobs… [06:24] at least, I have my keybindings back now :) [06:26] larsu: if you try to scroll the volume on the sound menu, don't you see weird behavior [06:26] when dragging the slider? [06:26] didrocks: yep, it's broken (and on my list) [06:26] there's a bug about it iirc [06:27] ok, I'm not dreaming then! :) [06:27] I guess it's due to the 120% patch [06:27] sure? [06:27] I think it worked in U [06:27] * larsu wrote that patch and probably tried the slider [06:28] I'm unsure, the offset seems to match a 20% missing :) [06:28] like if a callback would reset from the % the slider is completed [06:28] hm, this might be a different issue [06:28] I don't really know in utopic, most of the time, I'm using the multimedia keys for this [06:29] for me, it simply jumps back to 0 [06:29] … until they broke at login time :) [06:29] ah [06:29] try to drag until 80% [06:29] like some event translation problem (sometimes I can make it go to 1/3) [06:29] right [06:29] and if you go over 80%, it's setting at 100% [06:29] * larsu moves that up in his todo list. didrocks important. [06:30] larsu: ahah, don't! I just noticed it this morning due to the multimedia keys :) [06:30] didrocks: interesting. I can't try that right now because I can't move it beyond 30% [06:30] well, still to fix for vivid [06:30] right [06:30] larsu: I think I will be a good candidate to test your patch then! [06:31] :) [06:31] didrocks: je vais bien, merci ! [06:31] nous avons regardé un bon concert hier soir -- "Scrap Arts Music" [06:32] ah, http://scrapartsmusic.com/ [06:32] * didrocks looks [06:32] they do drums and sounds on metal scrap, plastic pipes, isolation material and what not [06:33] pitti: sounds interestering! Were they giving a show in your city? [06:33] didrocks: yeah, right in the "Parktheater" which is a 15 mins walk from here [06:34] I love that place -- it's a beautiful theater in "Jugendstil" and they have a lot of nice shows [06:35] oh, nice! :) [06:36] I guess that style goes very well with this arts music show :) [06:36] didrocks: well, let's say it's a nice contrast :) [06:37] didrocks: we've seen magic shows and Jazz concerts there, and of course more classical theater plays [06:38] https://de.wikipedia.org/wiki/Kurhaus_G%C3%B6ggingen [06:39] didrocks: would you have some minutes this morning for catching up on some systemd stuff? [06:42] good morning desktopers [06:42] hey pitti [06:42] bonjour seb128, ça va ? [06:42] word up seb [06:42] pitti, is using /lib/systemld [06:42] pitti, is using /lib/systemd/system a debian/ubuntu-ism? [06:42] rather than /usr/lib/systemd [06:43] pitti, oui, et toi ? [06:43] seb128: well, it's an -ism of distros which haven't merged /usr into / yet [06:43] s/yet// [06:43] desrt, good middle-of-the-night [06:43] :) [06:43] seb128: but upstream software isn't supposed to hardcode that path anyway [06:43] pitti, ok, I was reading a bit the systemd documentation to get more familiar with it and upstream documents /usr/lib/systemd so I was wondering [06:44] seb128: yeah, that's for Fedora which installs the entire OS into /usr/ now [06:44] k [06:44] * desrt wonders when the debian world will realise the wisdom of os-in-/usr [06:45] pitti, btw I noticed that you added some systemd job without having a Documentation=man:..., should we add that to the recommendations/template we use/...? [06:45] pitti: 30 minutes? having family here [06:45] seb128: it's in the examples on https://wiki.ubuntu.com/SystemdForUpstartUsers and documented there [06:46] seb128: I added it to most stuff, but indeed I left it out where there are no manpages; did I forget one? [06:46] we might also add some URLs or README files [06:46] didrocks: sure, sounds fine! [06:47] hey seb128, desrt! [06:47] didrocks: good morning [06:48] pitti, well, e.g ufw doesn't have one and has a manpage, but you did that earlier in the cycle [06:48] seb128: ah, I guess I was young and needed the ... education [06:48] :-) [06:49] seb128: yeah, that one certainly has manpages or other documents [06:49] pitti, I'm trying to educate myself as well [06:49] - debian/rulles: Call dh_systemd_{enable,start}. [06:49] go, pitti, go! spelling R us! [06:49] didrocks, pitti, btw do you have your sysgtemd catchup/discussion in public channels, or just over hangouts? [06:49] seb128: I don't know yet [06:50] seb128: the one I have in mind probably works better over IRC, but I'm fine with HO too [06:50] (i. e. the writing-to-thinking ratio is quite low) [06:50] if you do IRC I'm probably going to keep an eye on it [06:50] seb128: that said, I always enjoy hangouts to actually see my friends :) [06:50] trying to get a bit more involved with that side of things [06:50] * pitti hugs seb128 [06:51] hehe [06:51] * seb128 hugs pitti [06:52] seb128: we got through most stuff, but especially on the phone there's still some bits to port if you are interested [06:53] pitti, yeah, I might have a look at helping there [06:53] and if not I'm going to try to help at least on bugs and maybe on the user session stuff next cycle [07:12] pitti: as you prefer, we can go on IRC [07:12] my family will live in a bit, but we can start chatting now [07:12] leave* [07:13] didrocks: so, I was working on providing a counterpart for static-network-up [07:13] i. e. I want to make network-online.target wait until all "auto" interfaces in /e/network/interfaces are up [07:13] that's similar to NetworkManager-wait-online.service or systemd-networkd-wait-online.service which hook themselves there [07:14] this is not the default of network-online.target? [07:14] or is it when the first is up? [07:14] * didrocks remembers a wiki page about it, but quite rotten in my mind [07:14] n-o.t by itself does nothing, it just comes up when requested [07:14] you have to "implement" it by adding dependencies to it, such as NetworkManager-wait-online.service [07:14] gotcha [07:14] but so far we don't have an implementation for ifupdown [07:15] indeed [07:15] so, you know about our udev rule to activate ifup@.service? [07:15] grep net /lib/udev/rules.d/99-systemd.rules [07:16] that one will call ifup@iface.service which will call "ifup iface" once these interfaces appear [07:16] that is for catching interfaces which are hotplugged/slow to initialize and thus aren't covered by the /etc/init.d/networking run during boot [07:16] with $name, corresponding to the newly detected device [07:17] so, my initial approach was to write a generator which adds Requires/After=ifup@XXX.service to network-online.target, for XXX in all "auto" /e/n/i [07:17] that was http://paste.ubuntu.com/9792001/ [07:18] but this starts the services, due to Requires? [07:18] didrocks: but at that point I think the "dependencies" approach and the "hotplugged udev event" don't go well together [07:18] even before they are ready [07:18] didrocks: right [07:18] yeah, so dependency vs event :) [07:19] didrocks: so if you e. g. make whoopsie Requires/After=network-online.target (the standard way to say "start this service only after we have networking up") [07:19] it will start network-online.target [07:19] didrocks: then whoopsie and network-online.target will fail with "dependency failure" [07:19] which will starts all if@ [07:19] ifup@ [07:19] yep [07:19] because the unit doesn't exist [07:19] if any of the /e/n/i interfaces aren't ready yet [07:19] well, it exists, but not ready [07:20] didrocks: well, it works if /e/init.d/networking brings them all up [07:20] didrocks: in my experiment I added an "eth42" to /e/n/i which doesn't exist [07:20] but I can make it exist later with 'sudo ip link add name eth42 type veth peer name veth42' [07:20] oh right, that's how "new ones" come up [07:21] didrocks: so that was my Q on the upstream mailing list -- can I somehow re-trigger the startup of network-oline.target and reverse deps [07:21] didrocks: yeah, that just simulates a hotplug event, or an interface being detected very late during boot [07:21] i. e. that ip link command will create an eth42 device, trigger the udev rule, trigger ifup eth42 through ifup@.service [07:22] didrocks: so that's where in http://paste.ubuntu.com/9792001/ the last paragraph comes into play [07:22] hum [07:22] didrocks: whenever an ifup@.service starts, it re-triggers network-online.target with the Wants=network-online.target [07:22] didrocks: so while that bit works fine, this doesn't propagate "upwards", i. e. everything *depending on* n-o.target won't start [07:23] i. e. it's the same problem one level up [07:23] sure, as it's not an event [07:23] it's just "that destination is reached" [07:23] because fundamentally, when you start a unit, it starts all of its deps, and if anything fails it fails itself too [07:23] yep [07:24] so I was wondering if you have a clever idea about "try to re-start everything which depends on n-o.target" in n-o.target [07:24] which is arguably turning the design upside down, but I wondered if it's possible [07:24] as that's basically what you need to trigger units on hardware [07:24] I guess from the dbus API, we can list all failed units and redo the logic… [07:24] but then, you have the rdepends on the rdepends… [07:24] and so on [07:25] sounds hackish [07:25] so, that would mean: [07:25] - listing failed units, check the reason and that they Requires/Wants n-o.target [07:25] - restarts them [07:25] didrocks: well, instead of re-triggering, it would be enough to not fail into dep-wait, but instead just wait (with a timeout) until your requirements become ready [07:25] - check if there was no rdepends on those units [07:25] didrocks: yeah, doing all that is crazy, and a "you don't want to do that", I think [07:25] so n-o.target waiting forever? [07:25] yeah ;) [07:26] the waiting would be better [07:26] didrocks: so, yesterday I finally gave up and opted for a very simple "waiting" solution [07:26] as it's really what you want to express [07:26] didrocks: http://paste.ubuntu.com/9787017/ [07:26] the target isn't really ready until all interfaces are up [07:26] * didrocks looks [07:26] didrocks: it's basically what {NetworkManager,systemd-networkd}-wait-online.service do -- these services wait until the network is up, then exit, and then the unit is started [07:27] +TimeoutStartSec=2min -> the issue of course, is that you have to quantify… [07:27] didrocks: ^ the 2 mins is to copy the behaviour of /etc/init/networking [07:27] ... .conf [07:28] (default is 1.5min, which would certainly work too, but that's just a detail..) [07:28] well, better to express it explicitely [07:28] TBH, the wait solution is the less hackish to me [07:29] as it's really what you want to express [07:29] didrocks: so, I don't find that very elegant, with the polling loop [07:29] but in essence, I think it fits the design best, and mirrors what the other "implementations" of n-o.t do [07:29] pitti: can't we have a simple daemon receiving some udev events? [07:29] instead of polling [07:29] didrocks: that's not enough [07:29] ifup'ing an interface doesn't send out uevents [07:29] ifup is ... special [07:30] ah… :) [07:30] you actually have to ask ifquery whether an interface is up [07:30] that's the only guaranteed way [07:30] ok, hence being bound to polling [07:30] you can't even rely on ifup's exit status (debian bug 773539), but that wouldn't help that much either [07:30] Debian bug 773539 in ifupdown "ifupdown: Please return exit status 1 when up command fails (unconfigured interface affects network-manager)" [Normal,Open] http://bugs.debian.org/773539 [07:32] didrocks: so, I think it's an ok way to get the correct behaviour (I tested it in a VM pretty extensively), it's just not terribly elegant [07:33] yeah, and we can't really get that in a dependency fashion to reevaluate it [07:34] now the only question is whether we want n-o.target to fail after two mins (by instsalling it into network-online.target.requires/) or to succeed after two mins (by installing it into network-online.target.wants/) [07:34] so far under upstart we have a "fallback mode" which boots the system anyway after 2 mins, so I went with wants/ for now [07:35] which means, whoopsie whould start after 2 mins if an interface fails [07:35] which for most applications is probably what we want -- the standard case is to wait for all ifaces so that you can bind on all network addresses [07:35] i. e. for old-skool servers which don't react to hotplugged interfaces [07:36] didrocks: so, if you don't have a better idea either, I guess I'll go with that ifupdown patch? [07:36] I'm trying to think about it [07:37] give me 15 minutes, I'm experimenting something [07:38] cat < auto eth42 [07:38] iface eth42 inet static [07:38] address 192.168.2.42 [07:38] EOF [07:38] didrocks: ^ that's what I did to add a non-existing interface at boot [07:38] sudo ip link add name eth42 type veth peer name veth42 [07:38] and that's how you bring it up after boot [07:38] thanks! trying with this [07:39] (another day of yaying for super-quick throw-away VMs, thank you QEMU!) [07:39] heh, indeed! [07:42] pitti: yeah, forget about it, this isn't going to work… [07:43] however, thinking about it, why wouldn't we create another target? [07:43] like network-online.target -> at least, one interface is up [07:43] network-online-all.target (or whatever) [07:43] didrocks: I had a version of the generator with creating ifup-all-auto.target and adding deps there, but that makes the problem worse [07:43] that way, we don't delay the whoopsie startup [07:43] well, the problem isn't delaying the woopsie startup -- it's not starting it up at all if not all ifaces are ready at boot [07:43] as most of services only need "some connexion" [07:44] of course whoopsie is just my usual test guinea pig -- whoopsie doesn't actually need a n-o.target dep [07:44] (i. e. you have to hack its .service to add this) [07:44] hum, why would we want to start it without network connection? [07:45] didrocks: as for "why do services want to delay their startup until all interfaces are up", that's a different discussion [07:45] servers usually bind to all available interfaces during startup [07:45] and if you bring up an interface later, they won't automatically bind to that [07:45] unless they listen to udev and re-bind, etc. [07:45] you think it's the majority? I would say it's the minority actually [07:46] didrocks: so whether to have different targets for both cases is of course also something which we can discuss [07:46] but it still has the same problem [07:46] and if we explicitely divide that in 2 targets, we can have one succeeding, and the other one failing [07:46] a direct "hardware comes up" -> "start a unit" link is easy [07:46] add a SYSTEMD_WANTS=foo.service in an udev rule [07:46] but putting any indirection in between seems hard [07:47] like, make that uevent activate a service which implements a target [07:47] well, I guess I'll re-send that to the upstream ML [07:47] I'm a little uneasy if we are making it failing if any interface doesn't come up to basically say "there is no network at all" [07:48] but I can see you want to know it… [07:48] didrocks: well, that's how stuff has worked for years in Ubuntu with the upstart jobs [07:48] and they do time out after 2 mins and start anyway after that [07:48] stgraber wrote that as at early boot, when /etc/init/networking.conf (or /etc/init.d/networking) runs, often some interfaces aren't ready yet on big servers [07:49] so, even on upstart, we didn't retrigger an event to say "there is more interfaces, please reevaluate" [07:49] are* [07:49] didrocks: and this only applies to services which explicitly depend on network-online.target (which isn't actually a lot; but they did come up during porting) [07:49] didrocks: we did [07:50] net-device-up [07:50] ah, so, we restarted let's say apache… as a consequence (or reload) [07:50] but we already have that -- the uevent, plus the systemd .device unit [07:50] didrocks: correct; look at e. g. /etc/network/if-up.d/openssh-server [07:51] didrocks: that restarts openssh on new interfaces [07:51] and that's the correct way to do it [07:51] ah, but we are getting that in a non systemd way [07:51] but with those specific rules [07:51] in /etc/network/if-up.d/ [07:51] yeah, kind of making sense [07:51] but we need the "static-networking-up" (upstart), respectively network-online.target for "old-skool" servers which aren't designed for hotplugging, but just for a server world of static interfaces [07:52] yeah, I think your approach is good enough for most of the case anyway [07:52] i. e. where you just want to extend the notion of "boot" a bit [07:52] right [07:52] it's not a clearly defined semantics anyway, I mostly wanted to mirror what we do on upstart [07:53] it gets you a little closer to the old "static" world where you define stuff in /e/n/i and assume it's there [07:53] for a desktop it's entirely a no-op [07:53] I think that would be an interesting case, where "boot" isn't an answer for those, for the systemd hackfest [07:53] we do have your solution which is mostly working (as you told, no-op on desktop, mirroring what we did on server) [07:54] but maybe we can really look how to pull that further and be more dynamic [07:54] yeah [07:54] did you discuss about it with Lennart already? [07:54] didrocks: only very quickly, but I think I explained it wrongly; I'll re-explain it on the ML [07:55] yeah ;) [07:55] tricky! [07:55] "how to make hardware activated targets" basically [07:55] I think the "force reevaluating" is maybe an answer [07:56] didrocks: right, and that works fine for re-evaluating network-online.target itself, through the extra "Wants" in the ifup@.service [07:56] but not for its rdepends [07:56] yeah, I more "reevaluating all failed-units" [07:56] meant* [07:57] like, it can be a keyword as part of the transaction [07:57] pitti: ok, I'll update you on plymouth/fsck, back in 5 if you don't mind? [07:57] didrocks: sure! [07:57] didrocks: I need to leave for a doctor appt. in ~ 20 mins FYI [07:57] takes about 30 mins [07:58] 1 min to get the allergy shot, and 30 mins sitting there reading the news, in case something goes wrong [07:58] (never happened, but oh well, they insist) [07:59] * pitti goes back to testing ubuntu CD insertion with update-notifier, to fix its upstart job [07:59] ugh CDs, who has them still? [07:59] * pitti plays with QEMU hot-adding virtual drives [08:00] how does one plug a CD into qemu ;) [08:00] by squeezing really hard! [08:01] you can add an empty drive with -drive if=ide,index=1,media=cdrom [08:01] and send a monitor command to insert a "medium" (from an image), which I'm currently RTFMing about [08:02] pitti, or just melt the CD and plug it into the USB port ;) [08:02] * didrocks back [08:02] actually, -drive media=cdrom is enough [08:02] pitti: I really think that if systemd internals can reevaluate (not restart), but retry failing jobs and only try restarting one path that makes sense with the new state of the world… [08:03] let's see what upstream thinks about it [08:03] pitti: ok, so on fsck/plymouth [08:03] yeah, something for the hackfest [08:03] I have multiple systemd-fsck process talking to one central systemd-fsckd [08:03] and systemd-fsckd talking to plymouth [08:04] I hacked our ubuntu logo theme to get those info [08:04] which means: [08:04] - systemd grows a dep on plymouth [08:04] - I factorized plymouth communication in the shared static lib [08:04] I have to update the text theme + xubuntu and such to this new protocol [08:05] also, there are some fixes for some corner cases, like reconnecting if plymouth respawn [08:05] I'm stuck on i18n though [08:05] didrocks: you mean libplymouth, right? or plymouth the daemon? [08:05] libplymouth [08:05] morning :P [08:05] didrocks: oh, plymouthd crashing in the middle of fsck'ing, and you can survive that? [08:05] hey mlankhorst, how are you? [08:05] hey mlankhorst [08:06] hey I'm good :-) [08:06] pitti: yeah, right now, I survive, but I don't reconnect to the new one [08:06] ambitious! [08:06] well, shouldn't be too hard, like a 20 minutes job testing included :) [08:06] so yeah, then adding the .services, writing manpages… [08:06] I'm just worried about this i18n [08:07] darkxst: ah, awesome! FTR: change ide0-cd0 /home/martin/Downloads/ubuntu/vivid-desktop-amd64.iso [08:07] - the first version of plymouth theme (the code is still there, just not in use) did create the string shown to the user [08:07] pitti, given I don't have a functioning cd drive, melting might work better ;) [08:07] - then, mountall sent the translation as part of the message and that's what is used with upstart nowdays [08:08] darkxst: it's all virtual :) (I don't have a physical CD drive either) [08:08] - systemd doesn't have any i18n facility… [08:08] didrocks: oh, you mean s-fsckd will already generate the strings, not the theme [08:08] it seems it makes sense to do that on systemd-side, but maybe different themes wants different message to display and we just send the metadata? [08:08] didrocks: systemd does have i18n [08:08] the theme doesn't support i18n either [08:08] hum, really? [08:09] didrocks: yeah, mostly for the .policy files (polkit) [08:09] didrocks: but also for the CLI tools [08:09] pitti, CD's are a physical media that can't be virtualised ;) iso's on the other can ;) [08:09] pitti: I did only see the policy files, which is different, not the CLI tools [08:09] * didrocks looks [08:09] didrocks: oh right [08:10] yeah, regrepped and nothing [08:10] didrocks: I guess there's something to be said to leave the representation to the theme [08:10] some themes might want this entirely graphical, or on really small screens or whatever [08:10] pitti: I agree, that's the current implmentation [08:10] but! [08:11] .script doesn't seem to support i18n [08:13] not an issue for the C themes of course, but our main one is a script… [08:13] didrocks: hmm, if themes don't suppor that, how do we i18n this today? [08:13] pitti: as told, that was put into mountall which send the strings to the theme [08:13] eww, yes [08:13] as part of the message [08:14] didrocks: and "script" can't call shell tools like "gettext", I suppose? [08:14] which sounds wrong to me [08:14] yes, it is [08:14] I didn't try, didn't see that in practice [08:14] * didrocks looks for example, but theme documentation is really thin [08:17] yeah, nothing obvious at least [08:18] * pitti looks at themes/ubuntu-logo/ubuntu-logo.script [08:19] pitti: btw, as told, I tried to be minimal in my patch in the theme, meaning, I don't touch most of the rest of the logic [08:19] but there is a lot of already dead code due to design changes [08:19] (like the progress bars) [08:20] and all the fsck logic was there [08:20] didrocks: hm, I can't imagine why plymouth themes wouldn't have their own text/i18n, but maybe they did design it like that, that clients have to create the strings [08:20] didrocks: adding i18n to fsckd doesn't seem much of a problem really; add it to po/POTFILES.in and use glibc's gettext [08:20] but I wonder if that's the right design [08:20] well, obviously it's the current design [08:21] pitti: I don't think it is as it means, we are forcing upon each themes our strings [08:21] well, forcing/proposing :) [08:21] (as we can keep, as of today, the metadata as well) [08:24] didrocks: need to run for appointment, back in 30; but I guess for now let's put the strings into fsckd then? [08:24] pitti: yeah :/ [08:24] pitti: just to be complete on the fsck question: we won't implement the question about "your partition is broken, do you want to fix it?" as systemd-fsck force repair by default [08:24] I need to implement the escape feedback though [08:24] at least with that themes don't have to copy&paste the fsck messages [08:24] like you press escape -> cancel all fsck jobs [08:24] right [08:24] we mostly just need the "checking, NN% done" and maybe the cancel [08:24] right [08:25] so, doing the escape first [08:25] and text theme, should be easy [08:25] i18n -> I'm quite "sad" :/ [08:32] hum, ubuntu-text never supported fsck messages [08:32] * didrocks wonders if it worths it to add that now (it's in C) [09:02] good morning all [09:03] hey willcooke [09:03] didrocks: hm, we install that on servers, right? [09:03] didrocks: but if fsckd sends the messages, wouldn't -text get that automatically? [09:04] hallo [09:04] pitti: we install that on the client as well, it's shown when you have nvidia cards [09:04] pitti: and no, there is no room for "update" message into that theme [09:05] (like no sprite placement) [09:05] oh, ok [09:05] Laney, bad news... [09:05] Laney, no tenner found. [09:05] pitti: the one on the right: http://i.stack.imgur.com/EPKXz.png [09:06] willcooke: oh well, I'll take that raise then [09:06] I might be in the office this week, I'll be sure to check down the back of the sofa in reception for your "raise" [09:06] :-) [09:10] hum, can't get the disconnect signal from plymouth :/ [09:30] pitti: I'm unsure that we tested disconnection from plymouth in a long time [09:30] the issue is that the even loop is stuck, and so is the daemon… [09:31] I'm checking what we are doing in casper or mountall, and it seems to be the same though [09:32] Laney, hey, btw it seems the upower transition was a redherring on that sleep issue on the device [09:32] didrocks: I'm unsure that we tested anythign in plymouth recently :/ [09:32] it's quite a bit of a bitrot case [09:33] didrocks: i. e. our current approach is to hope that plymouth won't crash? :/ [09:33] pitti: seems so, if it does, I'm pretty sure mountall or md5check is stuck [09:33]