Re: [systemd-devel] cryptsetup vs. swapon/fsck (some kind of race condition)
El 20/05/14 12:16, Lennart Poettering escribió:
> Please, remove the old cruft! Or at least disable it by default int the
> code!
mdadm also has the same ugly assumptions.. even worst, it does not use
libudev but determines if udev is running by :
( (stat("/dev/.udev", &stb) == 0 || stat("/run/udev", &stb) == 0) ..
that also needs to be compiled out.
--
Cristian
"I don't know the key to success, but the key to failure is trying to
please everybody."
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cryptsetup vs. swapon/fsck (some kind of race condition)
On Mon, 19.05.14 10:13, Peter Rajnoha (prajn...@redhat.com) wrote: > > broken. We start these things in parallel, they create these races > > without reason. Since ages we don't support non-devtmpfs kernels > > anymore, so it's *always* wrong to invoke mknod(), since the kernel will > > create the device nodes. Unless you run an early 2.6 kernels this is > > completely wrong. I'd recommend filing a bug against the distribution to > > remove this old crap from libdm. > > > > What does libdm even check there precisely? > > It uses libudev's udev_queue_get_udev_is_active. So is there a better > function we should use instead? If not, there should probably be a better > one provided in libudev to check whether udev is ready to serve on the system > or not. Well, whether udev is already running yet or hasn't been started yet doesn't actually matter much, as udev's APIs are completely safe regarding that. You can allocate a monitor before udev is up, and it will work but only start reporting things after udev is up. And you can enumerate devices, and the API will report with udev_device_is_initialized() whether that specific device is initialized yet, and this will return true only if udev not only got started but also processed the device. The entire API is hence designed in a way that you don't need to synchronize against udev in order to use its APIs, hence the idea to check whether udev is running is completely against the entire design of it. > As for devtmpfs, are you sure it's enabled everywhere and always? Well, udev has been requiring that for a while, there's no code in udev anymore to even do a mknod() on its own... If you think it is worth support really old kernels with new LVM (though I really don't see why you would want that, after all LVM is hardly an app you install but part of the OS itself), then at least make the mknod madness a compile-time configurable option, and set it to "off" by default, so that people understand that this is archaic stuff nobody in his right mind would ever use when setting up a system today. The Gentoo developers apparently need holding hands for these kinds of things, and this is how you can guide them into the right direction. > It's configurable for the kernel and one does not need to enable it it seems. > I just need to be sure that if we completely turn this fallback node > management > in libdm, I won't cut someone off in some distro with settings not exactly > the same as used in Fedora. Well the kernel wants to support really archaic userspaces. I don't think that this really applies the same way for LVM. Also, I am pretty sure that pretty much any distro from the last 2 years is using devtmpfs, since udev stopped supporting non-devtmpfs systems from jan 1st 2012 on. And you can be quite sure that actually they already adopted it much earlier, since that was just the time where we removed support for it in udev upstream, where we have the guarantee. Early than that we just strongly recommended it, and it was merged into the kernel in apr 30th, 2009. Please, remove the old cruft! Or at least disable it by default int the code! Thanks, Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cryptsetup vs. swapon/fsck (some kind of race condition)
On 05/15/2014 11:38 PM, Lennart Poettering wrote: > On Thu, 15.05.14 23:15, Andy Kittner (andy.kitt...@gmail.com) wrote: > >> | May 15 22:06:47 pinky systemd[1]: Mounted Runtime Directory. >> | May 15 22:06:47 pinky systemd[1]: Mounted Lock Directory. > > This looks like remains from a *really* old systemd version. THis does not > exist anymore. What distribution is this? > > This used to bind mount /run to /var/run, and similar for /var/lock. > >> | May 15 22:06:47 pinky systemd[1]: Started udev Kernel Device Manager. >> | May 15 22:06:47 pinky systemd-cryptsetup[2433]: AKI DEBUG udev: >> open_queue_file failed with errno 2 >> | May 15 22:06:47 pinky systemd-cryptsetup[2433]: AKI DEBUG >> libdm:_check_udev_is_running: Udev is not running. Not using udev >> synchronisation code. >> >> So the udev queue file does not yet exist, libdm thinks the system is >> not running udev and things go wrong... > > This really should be turned off in libdm. It's really stupid and > broken. We start these things in parallel, they create these races > without reason. Since ages we don't support non-devtmpfs kernels > anymore, so it's *always* wrong to invoke mknod(), since the kernel will > create the device nodes. Unless you run an early 2.6 kernels this is > completely wrong. I'd recommend filing a bug against the distribution to > remove this old crap from libdm. > > What does libdm even check there precisely? It uses libudev's udev_queue_get_udev_is_active. So is there a better function we should use instead? If not, there should probably be a better one provided in libudev to check whether udev is ready to serve on the system or not. As for devtmpfs, are you sure it's enabled everywhere and always? It's configurable for the kernel and one does not need to enable it it seems. I just need to be sure that if we completely turn this fallback node management in libdm, I won't cut someone off in some distro with settings not exactly the same as used in Fedora. -- Peter ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cryptsetup vs. swapon/fsck (some kind of race condition)
On 16/05/14 16:31, Lennart Poettering wrote: > On Fri, 16.05.14 03:20, Andy Kittner (andy.kitt...@gmail.com) wrote: > "Minimal" configurations? Are you kidding? > > If you want something "minimal", then just use devtmpfs, and don't > involve userspace at all in creating device nodes. This is not about > being "minimal" or not, this is about actually getting basic things > right... With "minimal" I was thinking more of not wanting udev in some situations, since the code in question explicitly mentions udev synchronisation. Sorry, that admittedly wasn't clear from the context I wrote it in. As for devtmpfs itself, I don't know a situation where *I* wouldn't want it, of the top of my head, but the world is big and different people have different needs and IMHO it's up to the maintainers of each project whether or not they want to support those needs, or if they consider them not relevant enough to be worth that effort. That is all I was trying to say with this. > > Anyway, systemd is not compatible with Gentoo's way of doing LVM/DM, > sorry. Please file a bug against Gentoo. Um, the code in question is in upstream libdm, it has nothing to do with gentoo at all. Anyway, to bring this thread to a conclusion, since you don't consider this to be a dependency issue on systemd's side I just reported the issue on the LVM list, so let's see what they think about it. Regards, Andy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cryptsetup vs. swapon/fsck (some kind of race condition)
On Fri, 16.05.14 03:20, Andy Kittner (andy.kitt...@gmail.com) wrote: > >> | May 15 22:06:47 pinky systemd[1]: Mounted Runtime Directory. > >> | May 15 22:06:47 pinky systemd[1]: Mounted Lock Directory. > > > > This looks like remains from a *really* old systemd version. THis does not > > exist anymore. What distribution is this? > > Gentoo Oh, man. Gentoo is really getting on my nerves... That completly backwards /usr migration thing they are doing. The completely misunderstood multib setup of Gentoo, and now these idea of mknod from userspace on today's kernel Jezuz, guys. And Gentoo wants to be taken seriously... --omg-optifucked... I am tempted to just redirect all systemd questions coming from Gentoo users directly back to tgen Gentoo ML. They need to clean up their own mess first... > > This really should be turned off in libdm. It's really stupid and > > broken. We start these things in parallel, they create these races > > without reason. Since ages we don't support non-devtmpfs kernels > > anymore, [...] > And that's fine for systemd, but it doesn't necessarily mean that other > projects work under the same assumption. And IMHO especially for > critical things like lvm it is a good thing to support minimal > configurations. "Minimal" configurations? Are you kidding? If you want something "minimal", then just use devtmpfs, and don't involve userspace at all in creating device nodes. This is not about being "minimal" or not, this is about actually getting basic things right... Anyway, systemd is not compatible with Gentoo's way of doing LVM/DM, sorry. Please file a bug against Gentoo. > That sounds like this can only end in a systemd vs. the rest of the > world flamewar and I have no intention to get involved in one of > those, Dunno, every distro actually appears to get this right these days, but one... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cryptsetup vs. swapon/fsck (some kind of race condition)
On 15/05/14 23:33, Kay Sievers wrote: > On Thu, May 15, 2014 at 11:15 PM, Andy Kittner wrote: > > What is "Mounted Runtime Directory"? Is that /run? That must be part > of PID1's own early initialization, nothing to run externally. I thought so from the name, but aparently it is just some /var/run compatibility stuff (see my response to Lennart). Regards, Andy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cryptsetup vs. swapon/fsck (some kind of race condition)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 15/05/14 23:38, Lennart Poettering wrote: > On Thu, 15.05.14 23:15, Andy Kittner (andy.kitt...@gmail.com) wrote: > >> | May 15 22:06:47 pinky systemd[1]: Mounted Runtime Directory. >> | May 15 22:06:47 pinky systemd[1]: Mounted Lock Directory. > > This looks like remains from a *really* old systemd version. THis does not > exist anymore. What distribution is this? Gentoo > > This used to bind mount /run to /var/run, and similar for /var/lock. Yeah this appears to do something similar, but it's provided by sys-apps/gentoo-systemd-integration not systemd itself, so I guess it's something distro-specific. > >> | May 15 22:06:47 pinky systemd[1]: Started udev Kernel Device Manager. >> | May 15 22:06:47 pinky systemd-cryptsetup[2433]: AKI DEBUG udev: >> open_queue_file failed with errno 2 >> | May 15 22:06:47 pinky systemd-cryptsetup[2433]: AKI DEBUG >> libdm:_check_udev_is_running: Udev is not running. Not using udev >> synchronisation code. >> >> So the udev queue file does not yet exist, libdm thinks the system is >> not running udev and things go wrong... > > This really should be turned off in libdm. It's really stupid and > broken. We start these things in parallel, they create these races > without reason. Since ages we don't support non-devtmpfs kernels > anymore, [...] And that's fine for systemd, but it doesn't necessarily mean that other projects work under the same assumption. And IMHO especially for critical things like lvm it is a good thing to support minimal configurations. > What does libdm even check there precisely? They call udev_queue_get_udev_is_active() from libudev to determine whether the system currently runs udev, or not. See check_udev_is_running(): https://git.fedorahosted.org/cgit/lvm2.git/tree/libdm/libdm-common.c#n2071 >[...] > Nope, we don't need more synchronization. The LVM guys should stop doing > mknod() on their own. And if they insist, your distro should turn that > off, or patch it out. That sounds like this can only end in a systemd vs. the rest of the world flamewar and I have no intention to get involved in one of those, so I guess I'll just work around it locally and call it a day, saves nerves and effort for everyone. Anyway, thanks for the pointer with the device node, to me that looked like a rather harmless warning and not like a serious issue. Regards, Andy -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJTdWfcAAoJED4ymUd/KFGwP9MQALqupxFKdl42W/6g83uUI0uR zzNNpJhry2Iv/pR/foQhl3ml3Y9B0h+pECH0/ey44dXWPsEjwpHTInS62vDouibO 6c22a8SJFXhNJdyrzXbaFWkni9yrJqHZHQGfydza0sgH0bgZxozTs7Y3/ANShzrI l2qcRhYI3Ea3XFDvs+9BnjOiPpccqS1J2LXnBpTLgiZ44o/9dcMVlIXXli98zi81 ySUfnuP3SvtUJnbKicv/7Ei0DVSz8IoAdqP/5nAEZE32ZvPhPCyh1TRRBPxaQv67 EVF3lwIsNSKJ5ggxjCEWCsId4WXGkOxHDqS4EAZOVdYswREvnhqBWkQ8Y53A/KyM 4KPKUXh8Ovf5skbo4lZTNqWlnSOhjhwMD4z37vGQuy11QYRZQZvfDgEnHF4uWaBy ym7/zN+FOdGkmyx4VfDOlkjnFsLcBQ+J6loV0dRV6iAwB9Bx28FiNuwiQSdf4Fzd twfFTA4ANiKFMydHxA7usWzxLrNH+Qyr6W2tzW01DQVFnb/LPc9nwnnfoc48eViE ts5cjWqITMAF2mXX51vGoCp+yyXh56S0NrHqGQ2bvWi0mVtD9zkTrovBOdU2Mgt5 /WoFV6J658hS65A4fYBr8PmPNZ4dWBAbJZRjKVaXYqZusoXS194B8zHQZRKYq1Q5 YZggRD4teAxNPOKtzVqr =jBQS -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cryptsetup vs. swapon/fsck (some kind of race condition)
On Thu, 15.05.14 23:15, Andy Kittner (andy.kitt...@gmail.com) wrote: > | May 15 22:06:47 pinky systemd[1]: Mounted Runtime Directory. > | May 15 22:06:47 pinky systemd[1]: Mounted Lock Directory. This looks like remains from a *really* old systemd version. THis does not exist anymore. What distribution is this? This used to bind mount /run to /var/run, and similar for /var/lock. > | May 15 22:06:47 pinky systemd[1]: Started udev Kernel Device Manager. > | May 15 22:06:47 pinky systemd-cryptsetup[2433]: AKI DEBUG udev: > open_queue_file failed with errno 2 > | May 15 22:06:47 pinky systemd-cryptsetup[2433]: AKI DEBUG > libdm:_check_udev_is_running: Udev is not running. Not using udev > synchronisation code. > > So the udev queue file does not yet exist, libdm thinks the system is > not running udev and things go wrong... This really should be turned off in libdm. It's really stupid and broken. We start these things in parallel, they create these races without reason. Since ages we don't support non-devtmpfs kernels anymore, so it's *always* wrong to invoke mknod(), since the kernel will create the device nodes. Unless you run an early 2.6 kernels this is completely wrong. I'd recommend filing a bug against the distribution to remove this old crap from libdm. What does libdm even check there precisely? > The main difference I spot is a longer interval between starting udev > and the udev_is_running() check. > Also, I guess "Mounted Runtime Directory" refers to /run, where the file > in question resides? In the "bad" case this happens in the same second > as the cryptsetup call... /run is since a long time mounted from within PID 1 very early on, as part of its initial setup, before running any unit or forking off any other process. > Anyway, my conclusion from this is that either the LVM guys need to > use another method to detect that udev is running, or systemd should > not start the cryptsetup stuff until udev is fully initialized. Nope, we don't need more synchronization. The LVM guys should stop doing mknod() on their own. And if they insist, your distro should turn that off, or patch it out. > Should I open a bug for LVM or for systemd? Certainly not systemd. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cryptsetup vs. swapon/fsck (some kind of race condition)
On Thu, May 15, 2014 at 11:15 PM, Andy Kittner wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 15/05/14 18:27, Lennart Poettering wrote: >> Well, something appears to create your device nodes, and it shouldn't do >> that... >> >> On a udev system userspace never creates any device nodes, that's done >> on its own by the kernel via devtmpfs, udev then just creates symlinks >> on top, or changes access rights. It appears that your LVM/DM installation >> for some reason created device nodes anyway, and you need to figure out >> why it did that, and turn this off. It might be in your initrd... > > Hah, progress: I think I pinpointed the culprit. > libdm checks whether udev is running and falls back to non-udev code > otherwise. > > When the boot fails, this is what I get: > > | May 15 22:06:46 pinky systemd-udevd[1361]: starting version 212 > | May 15 22:06:46 pinky systemd[1]: Starting udev Kernel Socket. > | May 15 22:06:46 pinky systemd[1]: Listening on udev Kernel Socket. > | May 15 22:06:46 pinky systemd[1]: Starting udev Control Socket. > | May 15 22:06:46 pinky systemd[1]: Listening on udev Control Socket. > | May 15 22:06:46 pinky systemd[1]: Starting udev Coldplug all Devices... > | May 15 22:06:46 pinky systemd[1]: Starting > system-systemd\x2dcryptsetup.slice. > | May 15 22:06:46 pinky systemd[1]: Created slice > system-systemd\x2dcryptsetup.slice. > | May 15 22:06:46 pinky systemd[1]: Starting Cryptography Setup for swap... > | May 15 22:06:46 pinky systemd[1]: Starting Cryptography Setup for videos... > | May 15 22:06:46 pinky systemd[1]: Starting Cryptography Setup for data... > | May 15 22:06:46 pinky systemd[1]: Starting Cryptography Setup for home... > | May 15 22:06:46 pinky systemd[1]: Started udev Coldplug all Devices. > | May 15 22:06:46 pinky systemd[1]: Starting udev Wait for Complete Device > Initialization... > | May 15 22:06:46 pinky systemd-cryptsetup[2436]: Set cipher twofish, mode > xts-essiv:wp256, key size 512 bits for device > /dev/disk/by-uuid/57d30bae-878a-4931-bc39-10cc18b92486. > | May 15 22:06:46 pinky systemd-cryptsetup[2434]: Set cipher twofish, mode > xts-essiv:wp256, key size 512 bits for device > /dev/disk/by-uuid/ee5e92a6-18b6-4247-a1d8-8379b01928fb. > | May 15 22:06:46 pinky systemd-cryptsetup[2433]: Set cipher twofish, mode > xts-essiv:wp256, key size 512 bits for device > /dev/disk/by-uuid/b1c029d2-515b-47a1-becf-59c1f5191e43. > | May 15 22:06:46 pinky systemd-cryptsetup[2435]: Set cipher twofish, mode > xts-essiv:rmd256, key size 512 bits for device > /dev/disk/by-uuid/72c01d1e-ac93-4263-93d7-fb293dfe49c0. > | May 15 22:06:46 pinky systemd[1]: Started Create Static Device Nodes in > /dev. > | May 15 22:06:46 pinky systemd[1]: Starting udev Kernel Device Manager... > | May 15 22:06:46 pinky systemd-udevd[2485]: starting version 212 > | May 15 22:06:47 pinky systemd[1]: Mounted Runtime Directory. > | May 15 22:06:47 pinky systemd[1]: Mounted Lock Directory. > | May 15 22:06:47 pinky systemd[1]: Started udev Kernel Device Manager. > | May 15 22:06:47 pinky systemd-cryptsetup[2433]: AKI DEBUG udev: > open_queue_file failed with errno 2 > | May 15 22:06:47 pinky systemd-cryptsetup[2433]: AKI DEBUG > libdm:_check_udev_is_running: Udev is not running. Not using udev > synchronisation code. > > So the udev queue file does not yet exist, libdm thinks the system is > not running udev and things go wrong... > > > I also was lucky enough to get one of the rare "good" boots right after > I put in my debug prints (I was fearing a Heisenbug here for a minute) > > So here it is for comparison: > > | May 15 22:02:10 pinky systemd-udevd[1362]: starting version 212 > | May 15 22:02:10 pinky systemd[1]: Starting udev Kernel Socket. > | May 15 22:02:10 pinky systemd[1]: Listening on udev Kernel Socket. > | May 15 22:02:10 pinky systemd[1]: Starting udev Control Socket. > | May 15 22:02:10 pinky systemd[1]: Listening on udev Control Socket. > | May 15 22:02:10 pinky systemd[1]: Starting udev Coldplug all Devices... > | May 15 22:02:10 pinky systemd[1]: Starting > system-systemd\x2dcryptsetup.slice. > | May 15 22:02:10 pinky systemd[1]: Created slice > system-systemd\x2dcryptsetup.slice. > | May 15 22:02:10 pinky systemd[1]: Starting Cryptography Setup for swap... > | May 15 22:02:10 pinky systemd[1]: Starting Cryptography Setup for videos... > | May 15 22:02:10 pinky systemd[1]: Starting Cryptography Setup for data... > | May 15 22:02:10 pinky systemd[1]: Starting Cryptography Setup for home... > | May 15 22:02:10 pinky systemd[1]: Starting File System Check on Root > Device... > | May 15 22:02:10 pinky systemd-udevd[2464]: starting version 212 > | May 15 22:02:10 pinky systemd[1]: Starting Create Static Device Nodes in > /dev... > | May 15 22:02:10 pinky systemd[1]: Started udev Coldplug all Devices. > | May 15 22:02:10 pinky systemd[1]: Starting udev Wait for Complete Device > Initialization... > | May 15 22:02:10 pinky systemd[1]: Mounted Runti
Re: [systemd-devel] cryptsetup vs. swapon/fsck (some kind of race condition)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 15/05/14 18:27, Lennart Poettering wrote: > Well, something appears to create your device nodes, and it shouldn't do > that... > > On a udev system userspace never creates any device nodes, that's done > on its own by the kernel via devtmpfs, udev then just creates symlinks > on top, or changes access rights. It appears that your LVM/DM installation > for some reason created device nodes anyway, and you need to figure out > why it did that, and turn this off. It might be in your initrd... Hah, progress: I think I pinpointed the culprit. libdm checks whether udev is running and falls back to non-udev code otherwise. When the boot fails, this is what I get: | May 15 22:06:46 pinky systemd-udevd[1361]: starting version 212 | May 15 22:06:46 pinky systemd[1]: Starting udev Kernel Socket. | May 15 22:06:46 pinky systemd[1]: Listening on udev Kernel Socket. | May 15 22:06:46 pinky systemd[1]: Starting udev Control Socket. | May 15 22:06:46 pinky systemd[1]: Listening on udev Control Socket. | May 15 22:06:46 pinky systemd[1]: Starting udev Coldplug all Devices... | May 15 22:06:46 pinky systemd[1]: Starting system-systemd\x2dcryptsetup.slice. | May 15 22:06:46 pinky systemd[1]: Created slice system-systemd\x2dcryptsetup.slice. | May 15 22:06:46 pinky systemd[1]: Starting Cryptography Setup for swap... | May 15 22:06:46 pinky systemd[1]: Starting Cryptography Setup for videos... | May 15 22:06:46 pinky systemd[1]: Starting Cryptography Setup for data... | May 15 22:06:46 pinky systemd[1]: Starting Cryptography Setup for home... | May 15 22:06:46 pinky systemd[1]: Started udev Coldplug all Devices. | May 15 22:06:46 pinky systemd[1]: Starting udev Wait for Complete Device Initialization... | May 15 22:06:46 pinky systemd-cryptsetup[2436]: Set cipher twofish, mode xts-essiv:wp256, key size 512 bits for device /dev/disk/by-uuid/57d30bae-878a-4931-bc39-10cc18b92486. | May 15 22:06:46 pinky systemd-cryptsetup[2434]: Set cipher twofish, mode xts-essiv:wp256, key size 512 bits for device /dev/disk/by-uuid/ee5e92a6-18b6-4247-a1d8-8379b01928fb. | May 15 22:06:46 pinky systemd-cryptsetup[2433]: Set cipher twofish, mode xts-essiv:wp256, key size 512 bits for device /dev/disk/by-uuid/b1c029d2-515b-47a1-becf-59c1f5191e43. | May 15 22:06:46 pinky systemd-cryptsetup[2435]: Set cipher twofish, mode xts-essiv:rmd256, key size 512 bits for device /dev/disk/by-uuid/72c01d1e-ac93-4263-93d7-fb293dfe49c0. | May 15 22:06:46 pinky systemd[1]: Started Create Static Device Nodes in /dev. | May 15 22:06:46 pinky systemd[1]: Starting udev Kernel Device Manager... | May 15 22:06:46 pinky systemd-udevd[2485]: starting version 212 | May 15 22:06:47 pinky systemd[1]: Mounted Runtime Directory. | May 15 22:06:47 pinky systemd[1]: Mounted Lock Directory. | May 15 22:06:47 pinky systemd[1]: Started udev Kernel Device Manager. | May 15 22:06:47 pinky systemd-cryptsetup[2433]: AKI DEBUG udev: open_queue_file failed with errno 2 | May 15 22:06:47 pinky systemd-cryptsetup[2433]: AKI DEBUG libdm:_check_udev_is_running: Udev is not running. Not using udev synchronisation code. So the udev queue file does not yet exist, libdm thinks the system is not running udev and things go wrong... I also was lucky enough to get one of the rare "good" boots right after I put in my debug prints (I was fearing a Heisenbug here for a minute) So here it is for comparison: | May 15 22:02:10 pinky systemd-udevd[1362]: starting version 212 | May 15 22:02:10 pinky systemd[1]: Starting udev Kernel Socket. | May 15 22:02:10 pinky systemd[1]: Listening on udev Kernel Socket. | May 15 22:02:10 pinky systemd[1]: Starting udev Control Socket. | May 15 22:02:10 pinky systemd[1]: Listening on udev Control Socket. | May 15 22:02:10 pinky systemd[1]: Starting udev Coldplug all Devices... | May 15 22:02:10 pinky systemd[1]: Starting system-systemd\x2dcryptsetup.slice. | May 15 22:02:10 pinky systemd[1]: Created slice system-systemd\x2dcryptsetup.slice. | May 15 22:02:10 pinky systemd[1]: Starting Cryptography Setup for swap... | May 15 22:02:10 pinky systemd[1]: Starting Cryptography Setup for videos... | May 15 22:02:10 pinky systemd[1]: Starting Cryptography Setup for data... | May 15 22:02:10 pinky systemd[1]: Starting Cryptography Setup for home... | May 15 22:02:10 pinky systemd[1]: Starting File System Check on Root Device... | May 15 22:02:10 pinky systemd-udevd[2464]: starting version 212 | May 15 22:02:10 pinky systemd[1]: Starting Create Static Device Nodes in /dev... | May 15 22:02:10 pinky systemd[1]: Started udev Coldplug all Devices. | May 15 22:02:10 pinky systemd[1]: Starting udev Wait for Complete Device Initialization... | May 15 22:02:10 pinky systemd[1]: Mounted Runtime Directory. | May 15 22:02:10 pinky systemd[1]: Mounted Lock Directory. | May 15 22:02:10 pinky systemd-cryptsetup[2437]: Set cipher twofish, mode xts-essiv:wp256, key size 512 bits for device /dev/disk/by-uuid/ee5e92a6-18b
Re: [systemd-devel] cryptsetup vs. swapon/fsck (some kind of race condition)
On Thu, 15.05.14 02:30, Andy Kittner (andy.kitt...@gmail.com) wrote: > > On 14/05/14 18:33, Lennart Poettering wrote: > > On Tue, 13.05.14 20:01, Andy Kittner (andy.kitt...@gmail.com) wrote: > > > >> | May 13 18:50:33 pinky systemd-udevd[2751]: conflicting device node > >> '/dev/mapper/swap' found, link to '/dev/dm-1' will not be created > >> Thats the first one I find a bit fishy, but it doesn't sound fatal > >> either... > > > > This really looks as if you built the DM userspace stuff without udev > > support. File a bug against you distro. > > That should not be the case, the udev useflag is enabled across the > board and I just double-checked cryptsetup, libdevmapper and dmsetup > with ldd; > all are linked against libudev. > > Is there anything else I could/should check? Well, something appears to create your device nodes, and it shouldn't do that... On a udev system userspace never creates any device nodes, that's done on its own by the kernel via devtmpfs, udev then just creates symlinks on top, or changes access rights. It appears that your LVM/DM installation for some reason created device nodes anyway, and you need to figure out why it did that, and turn this off. It might be in your initrd... Further questions regarding LVM/DM should better be directed to the LVM/DM people... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cryptsetup vs. swapon/fsck (some kind of race condition)
On 15/05/14 10:16, Kay Sievers wrote: > Are you running an initrd without udev, and/or tools that mess around > with mknod in /dev? No, the initrd uses udev and is created by copying cryptsetup etc. including all dependent libraries from the host system. I recreated it yesterday, so there are the using the exact same versions. I also ran the initrd with the debug flag where it puts you in a debug shell at various points. Right before switching to the new root ( the /dev etc. mounts have been moved to /newroot already at this point) the only nodes I have in /newroot/dev/mapper are control root -> root_sdb5-root root_sdb5-root -> ../dm-0 Hmm, if I have some time tonight I think I'll try real_init=/bin/bash and see what happens if I fire up things manually Regards, Andy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cryptsetup vs. swapon/fsck (some kind of race condition)
On Thu, May 15, 2014 at 2:30 AM, Andy Kittner wrote: > On 14/05/14 18:33, Lennart Poettering wrote: >> On Tue, 13.05.14 20:01, Andy Kittner (andy.kitt...@gmail.com) wrote: >> >>> | May 13 18:50:33 pinky systemd-udevd[2751]: conflicting device node >>> '/dev/mapper/swap' found, link to '/dev/dm-1' will not be created >>> Thats the first one I find a bit fishy, but it doesn't sound fatal >>> either... >> >> This really looks as if you built the DM userspace stuff without udev >> support. File a bug against you distro. > > That should not be the case, the udev useflag is enabled across the > board and I just double-checked cryptsetup, libdevmapper and dmsetup > with ldd; > all are linked against libudev. > > Is there anything else I could/should check? Are you running an initrd without udev, and/or tools that mess around with mknod in /dev? Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cryptsetup vs. swapon/fsck (some kind of race condition)
On 14/05/14 18:33, Lennart Poettering wrote: > On Tue, 13.05.14 20:01, Andy Kittner (andy.kitt...@gmail.com) wrote: > >> | May 13 18:50:33 pinky systemd-udevd[2751]: conflicting device node >> '/dev/mapper/swap' found, link to '/dev/dm-1' will not be created >> Thats the first one I find a bit fishy, but it doesn't sound fatal >> either... > > This really looks as if you built the DM userspace stuff without udev > support. File a bug against you distro. That should not be the case, the udev useflag is enabled across the board and I just double-checked cryptsetup, libdevmapper and dmsetup with ldd; all are linked against libudev. Is there anything else I could/should check? Regards, Andy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cryptsetup vs. swapon/fsck (some kind of race condition)
On Tue, 13.05.14 20:01, Andy Kittner (andy.kitt...@gmail.com) wrote: > | May 13 18:50:33 pinky systemd-udevd[2751]: conflicting device node > '/dev/mapper/swap' found, link to '/dev/dm-1' will not be created > Thats the first one I find a bit fishy, but it doesn't sound fatal > either... This really looks as if you built the DM userspace stuff without udev support. File a bug against you distro. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cryptsetup vs. swapon/fsck (some kind of race condition)
On 13/05/14 23:39, Zbigniew Jędrzejewski-Szmek wrote: > On Tue, May 13, 2014 at 08:01:21PM +0200, Andy Kittner wrote: >> | May 13 18:50:33 pinky systemd-udevd[2751]: conflicting device node >> '/dev/mapper/swap' found, link to '/dev/dm-1' will not be created >> Thats the first one I find a bit fishy, but it doesn't sound fatal >> either... > When this happens, what does /dev/mapper/swap point at? Here are the nodes I have right now: /dev/mapper: total 0 crw--- 1 root root 10, 236 May 13 18:50 control brw--- 1 root root 254, 3 May 13 18:50 data brw--- 1 root root 254, 4 May 13 18:50 home lrwxrwxrwx 1 root root 14 May 13 18:50 root -> root_sdb5-root lrwxrwxrwx 1 root root7 May 13 18:50 root_sdb5-root -> ../dm-0 lrwxrwxrwx 1 root root7 May 13 18:50 swap -> ../dm-1 lrwxrwxrwx 1 root root7 May 13 18:50 videos -> ../dm-2 /dev/dm-*: brw-rw 1 root disk 254, 0 May 13 18:50 /dev/dm-0 brw-rw 1 root disk 254, 1 May 13 18:50 /dev/dm-1 brw-rw 1 root disk 254, 2 May 13 18:50 /dev/dm-2 brw-rw 1 root disk 254, 3 May 13 18:50 /dev/dm-3 brw-rw 1 root disk 254, 4 May 13 18:50 /dev/dm-4 Regards, Andy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cryptsetup vs. swapon/fsck (some kind of race condition)
On Tue, May 13, 2014 at 08:01:21PM +0200, Andy Kittner wrote: > | May 13 18:50:33 pinky systemd-udevd[2751]: conflicting device node > '/dev/mapper/swap' found, link to '/dev/dm-1' will not be created > Thats the first one I find a bit fishy, but it doesn't sound fatal > either... When this happens, what does /dev/mapper/swap point at? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] cryptsetup vs. swapon/fsck (some kind of race condition)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi all, first I hope I'm asking at the right place here, if not feel free to kick me in the right direction. Now, for my problem: I have several encrypted partions set up via /etc/crypttab Since the update to systemd-212 (from 207 I think) the following happens - - Oh, here is a partition from crypttab, lets uncrypt it - - Crypto for /home done - - Hey, this block device for /home just turned up, lets fsck it - - Stopping crypto for /home (WTF? why would you do that?) - - Surprise fsck'ing the home partition failed because the device just disappeared I'm pretty sure it is some kind of race-condition/ timing problem, because about 1 in 10 boots works just fine. Also, the same setup worked fine before. I've been kind of living with this for a while now (login at the admin-shell and systemctl isolate default.target --> system goes up normally) because I was to lazy to dig through the logs, but today I finally got fed up enough with it to get of my lazy but. Sadly the logs didn't tell me much of *why* things happen the way they do, so maybe someone here as an idea how to investigate this further. These are the relevant parts of the log: | May 13 18:50:31 pinky systemd[1]: Received SIGCHLD from PID 2647 (systemd-cryptse). | May 13 18:50:31 pinky systemd[1]: Child 2647 (systemd-cryptse) died (code=exited, status=0/SUCCESS) | May 13 18:50:31 pinky systemd[1]: Child 2647 belongs to systemd-cryptsetup@swap.service | May 13 18:50:31 pinky systemd[1]: systemd-cryptsetup@swap.service: main process exited, code=exited, status=0/SUCCESS | May 13 18:50:31 pinky systemd[1]: systemd-cryptsetup@swap.service changed start -> exited | May 13 18:50:31 pinky systemd[1]: Job systemd-cryptsetup@swap.service/start finished, result=done | May 13 18:50:31 pinky systemd[1]: Started Cryptography Setup for swap. | May 13 18:50:31 pinky systemd[1]: systemd-cryptsetup@swap.service: cgroup is empty | May 13 18:50:33 pinky systemd-udevd[2751]: conflicting device node '/dev/mapper/swap' found, link to '/dev/dm-1' will not be created Thats the first one I find a bit fishy, but it doesn't sound fatal either... | May 13 18:50:33 pinky systemd[1]: dev-mapper-swap.device changed dead -> plugged | May 13 18:50:33 pinky systemd[1]: Job dev-mapper-swap.device/start finished, result=done | May 13 18:50:33 pinky systemd[1]: Found device /dev/mapper/swap. | May 13 18:50:33 pinky systemd[1]: dev-disk-by\x2duuid-e51117ad\x2db39b\x2d4ca3\x2da3cf\x2d81016a3b0190.device changed dead -> plugged | May 13 18:50:33 pinky systemd[1]: Job dev-disk-by\x2duuid-e51117ad\x2db39b\x2d4ca3\x2da3cf\x2d81016a3b0190.device/start finished, result=done | May 13 18:50:33 pinky systemd[1]: Found device /dev/disk/by-uuid/e51117ad-b39b-4ca3-a3cf-81016a3b0190. | May 13 18:50:33 pinky systemd[1]: dev-disk-by\x2did-dm\x2duuid\x2dCRYPT\x2dLUKS1\x2db1c029d2515b47a1becf59c1f5191e43\x2dswap.device changed dead -> plugged | May 13 18:50:33 pinky systemd[1]: dev-disk-by\x2did-dm\x2dname\x2dswap.device changed dead -> plugged | May 13 18:50:33 pinky systemd[1]: dev-dm\x2d1.device changed dead -> plugged | May 13 18:50:33 pinky systemd[1]: sys-devices-virtual-block-dm\x2d1.device changed dead -> plugged So far, so good | May 13 18:50:33 pinky systemd[1]: dev-mapper-swap.device changed plugged -> dead And here I think is the root of my problem, but I have no idea what causes this or how to get more information about that, | May 13 18:50:33 pinky systemd[1]: Trying to enqueue job systemd-cryptsetup@swap.service/stop/replace | May 13 18:50:33 pinky systemd[1]: Installed new job systemd-cryptsetup@swap.service/stop as 282 | May 13 18:50:33 pinky systemd[1]: Job cryptsetup.target/start finished, result=canceled | May 13 18:50:33 pinky systemd[1]: Installed new job cryptsetup.target/stop as 283 | May 13 18:50:33 pinky systemd[1]: Enqueued job systemd-cryptsetup@swap.service/stop as 282 | May 13 18:50:33 pinky systemd[1]: dev-disk-by\x2duuid-e51117ad\x2db39b\x2d4ca3\x2da3cf\x2d81016a3b0190.device changed plugged -> dead | May 13 18:50:33 pinky systemd[1]: dev-disk-by\x2did-dm\x2duuid\x2dCRYPT\x2dLUKS1\x2db1c029d2515b47a1becf59c1f5191e43\x2dswap.device changed plugged -> dead | May 13 18:50:33 pinky systemd[1]: dev-disk-by\x2did-dm\x2dname\x2dswap.device changed plugged -> dead | May 13 18:50:33 pinky systemd[1]: dev-dm\x2d1.device changed plugged - -> dead | May 13 18:50:33 pinky systemd[1]: sys-devices-virtual-block-dm\x2d1.device changed plugged -> dead | May 13 18:50:33 pinky systemd[1]: Collecting sys-devices-virtual-block-dm\x2d1.device | May 13 18:50:33 pinky systemd[1]: Collecting dev-dm\x2d1.device | May 13 18:50:33 pinky systemd[1]: Collecting dev-disk-by\x2did-dm\x2dname\x2dswap.device | May 13 18:50:33 pinky systemd[1]: Collecting dev-disk-by\x2did-dm\x2duuid\x2dCRYPT\x2dLUKS1\x2db1c029d2515b47a1becf59c1f5191e43\x2dswap.device | May 13 18:50:33 pinky systemd[1]: Stopped target Encrypted Volumes. | May 13 18:50:33 pinky sy
