[00:00] svu: the general idea is that you give *us* the log - and we look for things ;) [00:00] Keybuk, :) ok. I provided pastbin url :) [00:00] oh, missed that [00:03] slangasek: you know what I *don't* spy in that boot.log ? [00:03] Keybuk: udev? [00:03] udev [00:04] I would be surprised if you find something there. it looks so empty [00:04] so udev is *running*, but not under control of upstart [00:04] cjwatson, kernel [nnnn.nnnnnn] eth2: interrupt(s) dropped! < bloody hell [00:04] slangasek: but why isn't upstart even trying to start it? [00:04] you should see, at least, an attempt to start udev [00:04] W3ird_N3rd: sorry, I don't know anything about that, I doubt it's installer-specific [00:04] svu: can you pastebin /etc/init/udev.conf, please? [00:05] sure [00:05] http://pastebin.com/9m2GArqB [00:06] interesting [00:06] I'll just wait for mini.iso rebuilding 14 april and try again. I'm going to sleep now [00:06] Keybuk: I got nothin' [00:06] had enough :P [00:06] upstart must think it's already running [00:06] *but that makes no sense* [00:06] svu: what does "status udev" say? [00:07] udev start/running, process 393 [00:07] err [00:07] lool: no problem ... let me know how it goes. it's extremely timely for me to reproduce it as i don't have a ports mirror, etc. [00:07] Keybuk, or should I do "status udev" when in manual recovery mode? [00:07] I don't have enough space to try to reproduce myself either [00:08] please [00:09] Keybuk, ok, 2 mins, another reboot [00:10] hmm so the -dbgsym packages are correct but -dbg has the wrong CRC [00:15] Sarvatt: I'd noticed that too, but never investigated since -dbgsym works so well [00:15] Keybuk, udev start/running, process 401 [00:15] Sarvatt: they also crash libbfd sometimes :) [00:16] Sarvatt: if you could open a bug report, I can confirm it. I'd never gotten the time to really dig into that. [00:17] svu: can you pastebin a ps at this point [00:17] kees: will do, I was just insure where to file it. pkg-create-dbgsym? [00:18] Keybuk, arrgh. I wish you had asked a bit earlier :) ok [00:18] Keybuk: btw, thinking about it some more I know my fix for the deadlock is still racy, because "process incoming events until the queue is empty; write our request" is not atomic [00:18] but I don't think I'll have time to fully fix this [00:19] right, I was thinking we should just call poll() in the loop [00:21] Keybuk: in which loop? to fully fix it, ply_write() has to be interruptable, neh? [00:22] Is there a way to force update-manager to offer a restart? [00:22] persia: wow, quite eloquent [00:22] in the loop in that function [00:22] kirkland: are you still seeing bug #540091? Because bug #559582 claims to still have the problem, and that was filed after 540091 was fixed [00:22] Launchpad bug 540091 in mountall "libplymouth2<->mountall circular dep prevents upgrade from karmic" [High,Fix released] https://launchpad.net/bugs/540091 [00:22] Sarvatt: no, dbgsym is fine. it's the -dgb infrastructure from debian that is broken [00:22] Launchpad bug 559582 in mountall "Upgrade from karmic to lucid failes with Internal Error, Could not perform immediate configuration (2) on mountall" [Undecided,Confirmed] https://launchpad.net/bugs/559582 [00:22] Keybuk: ah [00:22] that'll mean it'll call read when it can, call write when it can [00:22] etc. [00:22] right [00:24] lifeless: thanks :) [00:24] persia: I don't think I achieved your eloquence, but I think you're rather better known than I:P [00:25] persia, btw I got X up on your little displaylink device [00:25] lifeless: I think the key bit for any nomination of me is probably "he seems to be around a lot". No eloquence required :) [00:25] bryceh: With the xsfbs build? [00:26] Keybuk, http://pastebin.com/k2yHLzsA [00:26] persia, well it also needed another library libdlo [00:26] which I just installed manually, it'll still have to be packaged I guess [00:26] persia, good news is I now understand what it'd take to make this thing work [00:26] bryceh: What did you do that needed that? I had it working in February without it. [00:27] bryceh: By "work" do you mean "autodetect and have GUI config interface"? [00:27] persia, but bad news is it looks like it'll only work with Xinerama [00:27] no I mean be able to get X running on it with an xterm [00:28] bryceh: Did you try the xorg.conf in the README? That mostly just worked for me with no extra libraires. [00:28] persia, yep, after installing the lib and verifying that worked I put the xorg.conf changes in and verified that worked. again though, it requires Xinerama if you want to fire up both the display and your regular monitor [00:28] bryceh: So, what does the xinerama limitation mean? What needs to happen to make it work the desired way? [00:28] so that's only feasible with -nvidia for now [00:29] Keybuk: triaged bug #559761 for the "mountall needs to flush" issue; I think we should fix this for final, is this something you'll be able to get to? [00:29] Launchpad bug 559761 in mountall "mountall needs to flush plymouth message queue before emitting upstart events" [High,Triaged] https://launchpad.net/bugs/559761 [00:29] I really had it working with -intel without the library :) I'll fiddle with it more after UDS, when I have hardware again. [00:29] slangasek: it's just adding that same flush function call into emit_event right? [00:29] Keybuk: I dunno, haven't looked at the code :) [00:29] svu: at this maintenance shell, do you have lvm working? [00:29] slangasek: can't see any reason why it would be harder than that [00:30] though it'd be a good idea to fix flush first ;) [00:30] bryceh: So, on a more general note: what does the xsdfbs bit bring to the package? [00:30] Keybuk, at that shell I can do "vgchange -a y" - and continue booting. otherwise I cannot boot [00:30] svu: that's not what I asked [00:30] bryceh: I noticed the extra Provides and dependency on the right base X lib, but that seemed to be two lines from the bundle of stuff. [00:30] Keybuk, well, perhaps I did not understand your question. [00:31] how do you mean "lvm working" - do you mean lvm binary? [00:31] persia, it means the driver needs to support xrandr (and will require upstream to support multiple video devices (bug #316514)) [00:31] Launchpad bug 316514 in xorg-server "MASTER: Xinerama/Multihead with several video cards is not supported" [Wishlist,In progress] https://launchpad.net/bugs/316514 [00:31] svu: can you reboot [00:31] get back to that maintenance shell [00:31] and then gather some information for me [00:31] persia, that's the packaging system debian uses, so if we want them to eventually adopt the package it has to have that packaging system [00:31] (without running vgchange or anything yourself) [00:32] ok [00:32] what commands should I run, what info to collect? [00:32] do you not have a second machine to IRC from? [00:32] bryceh: Did you plan to bring it to XSF for adoption? I had thought I'd just toss it in as an arbitrary optional extra package post-squeeze, but I'm happy if someone else wants to maintain (or team maintain) it. [00:32] persia, I have no such plans [00:33] Keybuk, ghm. I will check if my 2nd mac has any irc client... [00:33] svu: I guess a useful answer would be whether you have a /dev/.udev.log file at that maintenance shell [00:33] persia, in fact I think it looks like the work to get this supported is well beyond my scope and time availability [00:33] if you do, what is the output of "lvm vgs" and "lvm pvs" [00:33] are there device nodes in /dev/mapper? [00:33] ls -l /dev/mapper [00:33] include owner/group stuff [00:33] (even just of control) [00:33] hi [00:34] bryceh: Fair enough. If you have time, I'd appreciate a write-up of what you think needs doing, and I'll recollect the device and fiddle with it some more myself. [00:34] persia, anyway, I'll return the device to you at UDS [00:34] Keybuk, I know for sure I have /dev/.udev.log ! [00:34] svu: at that maintenance shell? [00:34] yes [00:34] and it has contents? [00:34] is there any project that needs a volunteer ? [00:34] bryceh: Sounds good. Thanks for confirming it still worked after the changes to the package. [00:34] persia, when you got it working before, did you get the full desktop session up and everything? [00:35] Keybuk, yes. IIRC I copied it yesterday here (pastebin) [00:35] ok [00:35] the answers to the other questions would be nice to have [00:35] persia, and was that with only the usb monitor enabled or did you have two monitors going? [00:35] oh [00:35] output of "cat /proc/self/mountinfo" there too [00:35] bryceh: I didn't try that far, as I only had about three days with the device, and was otherwise occupied at the time. I got X running in it with metacity and terminator though. [00:36] * persia mostly found it happened to still be in the laptop bag when the SiS USB devices were being bandied about. [00:37] well I didn't get to those either [00:38] ok, another me [00:38] yay, clones [00:38] :) [00:38] heh. No worries. A quick search found a fix for XRandR that was reported to work in Jaunty. I'll see if I can't get it to work more sensibly for maverick. Do you think that the USB probing might hit X so that it would be autodiscovered, or still need an xorg.conf. [00:39] svu_: ok, let's start with the basics [00:39] persia, to be honest I haven't dug into the usb probing to know if there's been work on that upstream [00:39] reboot the other box, and get it to that maintenance shell [00:40] snow_ru: There's heaps of stuff that needs volunteers, but here in Ubuntu we tend to focus on everything, rather than specific things. If you want to work on a specific thing, I recommend finding a bit of software you like, and chasing it to fix all the bugs (bugs.launchpad.net/ubuntu/+source/${PACKAGE}/+bugs is a good place to start. [00:40] persia, well, I should say I scanned through the xorg-devel mailing list but didn't find anything there [00:40] persia, but that was a few weeks ago [00:40] bryceh: Is USB probing something you're likely to be able to investigate in maverick? [00:40] yes, there is /dev/.udev.info [00:40] a lot of stuff inside [00:40] persia, no I won't be working on X in meerkat [00:40] svu_: no /dev/.udev.log [00:40] sorry I meant udev.log [00:40] of course [00:41] svu_: ok, can you get me the output of /proc/self/mountinfo ? [00:41] cat /proc/self/mountinfo I mean [00:41] bryceh: Ah, in that case, no worries. I'll file a bug if I run into a solution. [00:41] ghm.... smbmount does not work :( [00:41] svu_: ? I didn't ask you to run smbmount [00:41] how would I copy that stuff here? [00:42] on second machine? [00:42] Or just save it into different location and provide you after I boot successfully? [00:42] or copy to usb flash? [00:43] svu_: can you not take a photo of the screen? [00:43] ghm. ok :) [00:46] we're trying to debug a failure to mount a filesystem [00:46] going around mounting filesystems is *going to change the result* :p [00:47] indeed. ok, I got some shot using my mobile... [00:48] Keybuk, is rapidshare good enough? [00:49] svu_: you could just post it to the bug report? [00:49] slangasek, right:) [00:51] added to bug report [00:52] http://launchpadlibrarian.net/44204574/Image0021.jpg [00:53] anything else? [00:54] ok [00:54] bye [00:56] svu_: ok, well that all looks right [00:56] hmm [00:56] ls -l /dev/mapper/control [00:56] what's the permissions and ownership? [00:56] root:root [00:56] crw-rw---- [00:57] ok [00:57] Keybuk: didn't tseliot say he had a bzr branch for part of this i18n fix? I can't find it now [00:57] svu_: ls -l /dev/tty1 [00:57] same question [00:57] root:tty [00:58] ok [00:58] so udev is working [00:58] crw--w---- [00:58] what does "lvm vgs" say? [00:59] it shows VG1 [00:59] PV 1 LV 3 Attr wz--n- [00:59] BUT [00:59] there is one thing [00:59] suspicious [00:59] many commands say File descriptor 8 leaked [01:00] I noticed that before many times [01:00] does it matter? [01:00] that's just the shell ;-) [01:00] ok [01:01] I felt I have to let you know :) [01:01] * kees wonders if watershed is iin the intramfs [01:01] * svu_ feels soon he will have to tell the superuser passwd and IP address :) [01:03] * ScottK gets a pencil. [01:04] ScottK, nothing interesting on that system. Just old power g5... [01:05] ;-) [01:06] well that was interesting... updated my system which included an update to grub and a new kernel, and it decides not to add the initrd line to the new boot stanza.. add it myself and it boots.... grub-update again and it does it right this time.... I have a feeling there's a race condition somewheres.. ugh... [01:07] Keybuk, anything else to check? [01:08] well [01:08] I'm stuck [01:08] lvm knows about your vgs [01:08] no idea why it hasn't activated them [01:09] I think udev has run lvm [01:09] how would I check that in .udev.log ? [01:09] how could I debug udev activities on boot? [01:10] Keybuk: Excuse me, I've not seen the bug you're working on but mentioning the LVM not mounted issue reminded me I've seen that here too, but always just gone into maintenance mode [01:10] that's harder [01:10] modify udev.conf to start with --debug [01:10] IntuitiveNipple, and what did you do in the maint mode? [01:10] Keybuk: strangely what I found was that whilst I was at the prompt thinking what to do, the missing device 'appeared' after a delay [01:10] so I just exit M mode and the system continues to start correctly [01:11] svu_, the volumes don't belong to another machine or instance do they? unless they have been set up or imported they won't be automatically activated [01:11] I assumed a race condition in mountall or similar [01:11] psusi, all same machine, SATA drive [01:12] Keybuk, why is that harder? [01:20] svu_: well, you have to do something ;-) [01:21] Keybuk, :) I just did. interesting change in behaviour after reboot [01:22] When I ask 'vgchange -a y' - I am getting error about missing mapper in /proc/misc [01:22] !!! [01:22] slowed it down enough to make it work? [01:22] But [01:22] oh, that's kinda interesting [01:22] after some while [01:22] and several attempts [01:22] it worked [01:22] and ... I think I had to make udevadm trigger as well [01:22] yes [01:23] and I see device-mapper in /proc/misc - all the time! [01:26] actually! [01:26] device-mapper is not there initially [01:26] indeed [01:26] not in /proc/misc [01:27] that's odd [01:28] even after udevadm trigger [01:29] suddenly (timeout??) I see a lot of output on console [01:29] I thought we built that in [01:29] and voila - device-mapper in /proc/misc [01:30] sounds like the driver isn't being loaded before the tools try to use it [01:30] it seems there was some delay [01:30] and --debug made that delay even bigger [01:30] ./config.common.ports:289:CONFIG_BLK_DEV_DM=m [01:30] ./config.common.ubuntu:375:CONFIG_BLK_DEV_DM=y [01:30] so on svu_'s powerpc box it won't be built-in [01:30] ports!!!!!!!! [01:30] oh, that's kinda fun [01:30] so when the underlying block device shows up ... [01:30] lvm is run ... [01:30] silly ports split [01:30] but device-mapper isn't loaded [01:30] so boom [01:31] * persia filed a bug about that recently, and hunts up the number [01:31] boom [01:31] baga boom [01:31] bug #560717 [01:31] Launchpad bug 560717 in linux "lucid sever fails to boot with LVM root" [Undecided,New] https://launchpad.net/bugs/560717 [01:31] cjwatson: well done [01:31] shall I try and bread roll a kernel dev? [01:32] svu_: Please confirm and mark as affecting you :) [01:33] Keybuk: might not hurt, I don't know if they have time for another upload / were planning one anyway [01:33] slangasek: so that mountall typo I noticed above - do you think we can squeeze in a fix for it? [01:34] persia, I marked "affects me too" [01:34] it's sitting there on the screen for some time and I'd rather not have a typo there [01:34] svu_: Thanks. If we can get all the powerpc LVM users to do that, maybe we can get an SRU, even if we can't get a prerelease upload :) [01:34] cjwatson: we're getting mountall string changes anyway today (unfortunately) to fix an untranslatable string, so yes [01:34] (just as soon as I verify the upgrade path on mountall+plymouth) [01:35] ok [01:35] will commit in a sec [01:35] persia, ok. Thanks a bunch, I would love to get that fixed. Otherwise the boot process does not look nice :) [01:35] Keybuk, say... what sort of tools should I look at to investigate a blocktrace during boot? I got e2defrag to pack all the files ureadahead wants at the start of the disk and oddly, the peak throughput went down slightly though total time in ureadahead also went down by a few seconds [01:35] thank you all lads for you help [01:36] directhex: hola [01:36] directhex: why do you tink that having minVersion 1.9 is right? [01:37] in gluezilla [01:37] asac, because it works (although not with 1.9.3 according to micahg), whereas the previous hard-coding caused more issues than it solved [01:38] directhex: its not a good idea to just keep it fully open [01:38] psusi: blktrace ;) [01:38] directhex: so definitly minVersion needs to be 1.9.2 [01:38] lol... of course ;) [01:38] directhex: there is no guarantee that standalone glue works with something lower than what it was linked from [01:39] directhex: for higher versions we would need to review what xpcom components it uses. if those are all frozen its fine to keep 1.9.* [01:39] as maxversion [01:39] but 9.9 is definitly wrong ;) [01:40] I'll push my working patch up to the ffox36 transition PPA to test [01:41] Keybuk: udev starts before modules are loaded... [01:41] asac, frankly, i'm sick to death of the package. do whatever, i really don't care as it only affects people running system.windows.forms apps with embedded browser controls (i.e. nothing in the archive). do what you like with it, use http://www.java2s.com/Code/CSharp/GUI-Windows-Form/WebBrowserinaction.htm to test it [01:41] init-top, then module loads, etc. [01:41] kees: well, yes [01:41] udev *loads* modules [01:41] directhex: kk [01:41] since ide is builtin, the vgchange triggers before device-mapper is loaded [01:42] Keybuk: Ought udev be loading dm_mod in this case then? [01:42] * kees is fighting tmobile's network [01:42] directhex: sorry about that :( [01:42] persia: no [01:42] will take care [01:42] dm_mod is one of those modules that can't be auto-loaded [01:42] which is WHY IT'S BUILT IN! :p [01:42] aha! (except it's not) :) [01:42] well, that's the bug [01:42] Right. [01:42] asac, also try shana on gimpnet #mono, within portugese working hours [01:43] But now I understand it, rather than it just being a mysterious failure which I knew how to make go away :) [01:43] asac, at the very least, -2 works, -1 segfaulted, so it could be worse [01:43] heh ;) thanks alot [01:43] well, it could be auto loaded... if udev tested for and loaded it if not already before invoking the tools that depend on it... or better yet, the tools could do that... I don't see why libdevmapper doesn't do that already [01:43] or @sh4na on twitter [01:45] psusi: because libdevmapper can be invoked by users [01:45] Keybuk: so, bug on the kernel then? won't make rc1... [01:45] kees: I think so [01:46] psusi: users can't load modules [01:46] Keybuk: yeah, looks like it's built-in in karmic. [01:46] directhex: ok. makes some sense. the currently disabled patch forced the load of xulrunner 1.9.1. so yeah. that crashes :) [01:46] kees: yeah, it's like unix, ppp, fuse, etc. [01:46] it makes no sense to be a module [01:46] asac, forcing 1.9.2 didn't work for me on one machine, just had a grey screen [01:46] it has to be loaded by hand to work [01:46] asac, so be sure to test changes [01:46] etc. [01:47] so just build the thing in [01:47] kees: I can confirm it was built-in for powerpc/amd64 in karmic and amd64 in lucid (but not powerpc). [01:47] directhex: yes, dont bother. we will check this out [01:47] hrm. only I don't see it ... ah! not built-in in ppc! [01:47] directhex: will let you know [01:47] kees: RIght, or, for that matter, on sparc/ia64. armel is messy enough I don't even want to look. [01:48] we could make the initramfs hook for dmsetup fail if dm_mod isn't built-in... [01:48] Keybuk, they can't use libdevmapper either [01:48] psusi: sure they can [01:48] psusi: is this discussion anything other than academic? things clearly work better if it's built-in, so build it in. the only downside is a small increase in core kernel size, which really is not that much of an issue on Ubuntu. [01:48] Could we make the initramfs hook for dmsetup attempt to load dm_mod if it's not present? [01:48] then you just move the bug to requiring an initramfs [01:48] seriously [01:48] just build the module in [01:49] there's no point bikeshedding when there's precious little upside to making it be a module [01:49] lots of things stop working if you go around changing random =y to =m [01:49] persia: it does already. it's just after udev starts [01:49] Keybuk, crw-rw---- 1 root root 10, 59 2010-04-14 20:02 /dev/mapper/control [01:49] psusi: chmod id [01:49] cjohnston, true [01:49] Anyway, my bug calls for it to be a built-in. Let's hear from a kernel dev. [01:49] psusi: you're allowed to do that [01:49] persia: the kernel dev who walked past on his way to get a nexus one said it's ok to build it in on ports [01:49] since it is in common ;) [01:49] persia: which bug #, btw, I'm a bit lost on scrollback [01:50] heh [01:50] kees: bug #560717 [01:50] Launchpad bug 560717 in linux "lucid sever fails to boot with LVM root" [Undecided,New] https://launchpad.net/bugs/560717 [01:50] Keybuk, think the kernel checks for CAP_SYS_ADMIN anyhow ;) [01:50] directhex: oh. what was the best way to test? [01:50] psusi: for devmapper? it shouldn't [01:51] asac, paste the code from http://www.java2s.com/Code/CSharp/GUI-Windows-Form/WebBrowserinaction.htm into a .cs file, run gmcs -pkg:dotnet foo.cs; mono foo.exe [01:51] psusi: SYS_ADMIN for what operation? [01:51] asac, that's a reasonably minimal example SWF browswer [01:52] Keybuk: tested out the low-color icons, I think I'm ready to upload - any objections? [01:52] slangasek: none [01:52] does it look at least 5% less crappy? [01:53] it looks pretty crisp [01:53] kees, the ioctls to manipulate the device mapper tables [01:53] directhex: it wants dotnet.pc [01:53] * asac esarches [01:54] asac, mono-devel [01:54] slangasek: i haven't tried a karmic -> lucid upgrade in a while [01:54] oh .. thats a lot of stuff [01:54] kirkland: did you test one after I uploaded the change? [01:55] * psusi wonders what the HELL could be confusing parted about what fs type is on partition 1 after creating it while partition 2 is mounted... yet unmounting partition 2 OR reformatting partition 1 from within parted fixes it [01:55] slangasek: what's the date of that? [01:55] psusi: ah, yeah [01:55] slangasek: i can background one in a vm, if you like [01:55] kirkland: 30 Mar [01:55] kirkland: a test would be helpful [01:55] slangasek: i probably have not [01:55] slangasek: i'll do that now [01:57] psusi: blkid [01:57] touching things would result in blkid running again from udev [01:57] slangasek: via do-release-upgrade -d ? [01:57] Is there a default user group for admins? [01:57] kirkland: however it was reproduced before [01:57] kirkland: and/or however that bug says it's reproducible [01:58] I'm making a package, and debating what permissions to put on the config folder in /etc [01:58] MattJ: there is an admin group [01:58] Do you know if that's an Ubuntu-only thing, or Debian too? [01:58] Keybuk, yea... and blkid recognizes the partition type just fine... but even rescanning/restarting parted and it still doesn't [01:59] MattJ: i'm pretty sure admin is consistent across Ubuntu and Debian [01:59] slangasek: upgrade underway, against local mirror [01:59] slangasek: give it a few minutes, i'll check back [02:00] partition 1 exists, is readable, writable, mountable, yet parted won't detect the fs type... it's so weird.... [02:04] right [02:04] party [02:04] how long do the builders wait with no buildlog changes before they fail out? [02:04] bcurtiswx: 150 minutes [02:05] persia: yikes, openjdk is immobile right now [02:05] which arch? [02:06] I think it's been like that a bit longer than 150 minutes :/ [02:06] persia: i386 [02:07] persia: https://edge.launchpad.net/ubuntu/+source/openjdk-6/6b18-1.8-0ubuntu1/+build/1691250 [02:07] bcurtiswx: How long do you think it's been sitting at "Error: com/sun/jdi/BacktraceFieldTest.java"? [02:08] Persia: honestly, no idea, saw the backlog of i386 packages waiting to build, thought maybe there was one package holding a few back.. looked at openjdk and saw it was stuck [02:08] slangasek: i did get an error with mountall [02:08] slangasek: is this logged to a file somewhere I can pastebin or attach to that bug? [02:09] persia: plus it was started 14 hours ago [02:10] bcurtiswx: That's never a safe indication: the prior upload took 15 hours, 37 minutes, 55.9 seconds to build on i386. [02:11] persia: nice.. good to know [02:11] See https://launchpad.net/~ubuntu-security/+archive/ppa/+build/1625847 [02:11] slangasek: nevermind; i'm running again, tee'ing output [02:12] Oh yay, the PPA build queue seems to be moving, thanks for that whoever :) [02:13] persia: hey, it moved! [02:13] persia: thanks for your help :) [02:14] bcurtiswx: Happy to share how things work to avoid confusion :) [02:16] slangasek: http://paste.ubuntu.com/414635/ [02:17] slangasek: let me know if there are more detailed logs somewhere else [02:24] kirkland: no more verbose logs unless you pass apt some debugging options; can you follow up with mvo on this? === dendro-afk is now known as dendrobates [02:40] Hmmm... can anybody confirm having difficulty unlocking a disk at boot with plymouth? [02:40] At first I thought it was my imagination, but it is happening often enough for me to think there's an issue. I can usually unlock a disk on the first try if I boot in rescue mode (and enter my passphrase without it going through a plymouth theme). But if I boot normally, it takes me 6-7 tries. [02:41]