Re: [systemd-devel] Question on debugging getty 'runlevel 3' issue.
В Mon, 19 Aug 2013 17:59:23 -0700 Ben Greear пишет: > On 08/19/2013 05:53 PM, Kay Sievers wrote: > > On Tue, Aug 20, 2013 at 12:36 AM, Ben Greear > > wrote: > >> I'm using Fedora 19 on a 32-bit dual-core Atom system. > >> > >> I installed Mate, various other packages, and among other configuration, > >> tried to put the system into the equivalent of 'runlevel 3'. > >> > >> The system boots to black console as expected, but it will not > >> give a prompt, except on 'alt F2' window. > >> > >> On clean bootup, if I ssh in, I there are no getty processes running: > >> > >> [root@ct520-128-6034 ~]# ps -auxww|grep getty > >> root 2699 0.0 0.0 4940 860 pts/1S+ 15:03 0:00 grep > >> --color=auto getty > >> > >> > >> [root@ct520-128-6034 ~]# grep -i getty /var/log/messages > >> [root@ct520-128-6034 ~]# ls -l /etc/systemd/system/getty.target.wants/ > >> total 0 > >> lrwxrwxrwx. 1 root root 38 Jun 27 10:12 getty@tty1.service -> > >> /usr/lib/systemd/system/getty@.service > >> > >> [root@ct520-128-6034 ~]# ls -l /usr/lib/systemd/system/getty@.service > >> -rw-r--r--. 1 root root 1662 Jun 24 08:30 > >> /usr/lib/systemd/system/getty@.service > >> > >> [root@ct520-128-6034 ~]# systemctl status getty@tty1.service > >> getty@tty1.service - Getty on tty1 > >> Loaded: loaded (/usr/lib/systemd/system/getty@.service; enabled) > >> Active: inactive (dead) > >> Docs: man:agetty(8) > >> man:systemd-getty-generator(8) > >> http://0pointer.de/blog/projects/serial-console.html > > > > Try? > >$ systemctl isolate multi-user.target > > This hangs, maybe forever, maybe just for a long time (1+ minutes). > Do you use plymouth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Question on debugging getty 'runlevel 3' issue.
On 08/19/2013 05:53 PM, Kay Sievers wrote: On Tue, Aug 20, 2013 at 12:36 AM, Ben Greear wrote: I'm using Fedora 19 on a 32-bit dual-core Atom system. I installed Mate, various other packages, and among other configuration, tried to put the system into the equivalent of 'runlevel 3'. The system boots to black console as expected, but it will not give a prompt, except on 'alt F2' window. On clean bootup, if I ssh in, I there are no getty processes running: [root@ct520-128-6034 ~]# ps -auxww|grep getty root 2699 0.0 0.0 4940 860 pts/1S+ 15:03 0:00 grep --color=auto getty [root@ct520-128-6034 ~]# grep -i getty /var/log/messages [root@ct520-128-6034 ~]# ls -l /etc/systemd/system/getty.target.wants/ total 0 lrwxrwxrwx. 1 root root 38 Jun 27 10:12 getty@tty1.service -> /usr/lib/systemd/system/getty@.service [root@ct520-128-6034 ~]# ls -l /usr/lib/systemd/system/getty@.service -rw-r--r--. 1 root root 1662 Jun 24 08:30 /usr/lib/systemd/system/getty@.service [root@ct520-128-6034 ~]# systemctl status getty@tty1.service getty@tty1.service - Getty on tty1 Loaded: loaded (/usr/lib/systemd/system/getty@.service; enabled) Active: inactive (dead) Docs: man:agetty(8) man:systemd-getty-generator(8) http://0pointer.de/blog/projects/serial-console.html Try? $ systemctl isolate multi-user.target This hangs, maybe forever, maybe just for a long time (1+ minutes). What does that print? $ systemctl get-default [root@ct520-128-6034 ~]# systemctl get-default Unknown operation 'get-default'. Are you sure there is nothing that has opened the device? $ sudo fuser /dev/tty1 Looks clean to me: [root@ct520-128-6034 ~]# fuser /dev/tty1 [root@ct520-128-6034 ~]# Thanks, Ben Kay -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Question on debugging getty 'runlevel 3' issue.
On Tue, Aug 20, 2013 at 12:36 AM, Ben Greear wrote: > I'm using Fedora 19 on a 32-bit dual-core Atom system. > > I installed Mate, various other packages, and among other configuration, > tried to put the system into the equivalent of 'runlevel 3'. > > The system boots to black console as expected, but it will not > give a prompt, except on 'alt F2' window. > > On clean bootup, if I ssh in, I there are no getty processes running: > > [root@ct520-128-6034 ~]# ps -auxww|grep getty > root 2699 0.0 0.0 4940 860 pts/1S+ 15:03 0:00 grep > --color=auto getty > > > [root@ct520-128-6034 ~]# grep -i getty /var/log/messages > [root@ct520-128-6034 ~]# ls -l /etc/systemd/system/getty.target.wants/ > total 0 > lrwxrwxrwx. 1 root root 38 Jun 27 10:12 getty@tty1.service -> > /usr/lib/systemd/system/getty@.service > > [root@ct520-128-6034 ~]# ls -l /usr/lib/systemd/system/getty@.service > -rw-r--r--. 1 root root 1662 Jun 24 08:30 > /usr/lib/systemd/system/getty@.service > > [root@ct520-128-6034 ~]# systemctl status getty@tty1.service > getty@tty1.service - Getty on tty1 >Loaded: loaded (/usr/lib/systemd/system/getty@.service; enabled) >Active: inactive (dead) > Docs: man:agetty(8) >man:systemd-getty-generator(8) >http://0pointer.de/blog/projects/serial-console.html Try? $ systemctl isolate multi-user.target What does that print? $ systemctl get-default Are you sure there is nothing that has opened the device? $ sudo fuser /dev/tty1 Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Question on debugging getty 'runlevel 3' issue.
On 08/19/2013 03:36 PM, Ben Greear wrote:
I'm using Fedora 19 on a 32-bit dual-core Atom system.
I installed Mate, various other packages, and among other configuration,
tried to put the system into the equivalent of 'runlevel 3'.
The system boots to black console as expected, but it will not
give a prompt, except on 'alt F2' window.
On clean bootup, if I ssh in, I there are no getty processes running:
[root@ct520-128-6034 ~]# ps -auxww|grep getty
root 2699 0.0 0.0 4940 860 pts/1S+ 15:03 0:00 grep
--color=auto getty
[root@ct520-128-6034 ~]# grep -i getty /var/log/messages
[root@ct520-128-6034 ~]# ls -l /etc/systemd/system/getty.target.wants/
total 0
lrwxrwxrwx. 1 root root 38 Jun 27 10:12 getty@tty1.service ->
/usr/lib/systemd/system/getty@.service
[root@ct520-128-6034 ~]# ls -l /usr/lib/systemd/system/getty@.service
-rw-r--r--. 1 root root 1662 Jun 24 08:30 /usr/lib/systemd/system/getty@.service
[root@ct520-128-6034 ~]# systemctl status getty@tty1.service
getty@tty1.service - Getty on tty1
Loaded: loaded (/usr/lib/systemd/system/getty@.service; enabled)
Active: inactive (dead)
Docs: man:agetty(8)
man:systemd-getty-generator(8)
http://0pointer.de/blog/projects/serial-console.html
A 64-bit server-class system installed in same manner works fine.
Any ideas on how to debug this further?
Here's some more things I tried to debug this.
I noticed that if I do:
systemctl start getty@tty1.service
It just hangs. Here is strace output from the command above:
getsockname(3, {sa_family=AF_LOCAL, NULL}, [2]) = 0
getsockopt(3, SOL_SOCKET, SO_PEERCRED, {pid=1, uid=0, gid=0}, [12]) = 0
clock_gettime(CLOCK_MONOTONIC, {7804, 989051445}) = 0
poll([{fd=3, events=POLLOUT}], 1, 9) = 1 ([{fd=3, revents=POLLOUT}])
send(3, "\0", 1, MSG_NOSIGNAL) = 1
send(3, "AUTH EXTERNAL 30\r\n", 18, MSG_NOSIGNAL) = 18
clock_gettime(CLOCK_MONOTONIC, {7804, 994345644}) = 0
poll([{fd=3, events=POLLIN}], 1, 89995) = 1 ([{fd=3, revents=POLLIN}])
read(3, "OK 0709ee02ee0916d059fdc66252128fe8\r\n", 2048) = 37
clock_gettime(CLOCK_MONOTONIC, {7804, 995190179}) = 0
poll([{fd=3, events=POLLOUT}], 1, 89994) = 1 ([{fd=3, revents=POLLOUT}])
send(3, "NEGOTIATE_UNIX_FD\r\n", 19, MSG_NOSIGNAL) = 19
clock_gettime(CLOCK_MONOTONIC, {7804, 998475081}) = 0
poll([{fd=3, events=POLLIN}], 1, 89991) = 1 ([{fd=3, revents=POLLIN}])
read(3, "AGREE_UNIX_FD\r\n", 2048) = 15
clock_gettime(CLOCK_MONOTONIC, {7804, 999282320}) = 0
poll([{fd=3, events=POLLOUT}], 1, 89990) = 1 ([{fd=3, revents=POLLOUT}])
send(3, "BEGIN\r\n", 7, MSG_NOSIGNAL) = 7
clock_gettime(CLOCK_MONOTONIC, {7805, 868722}) = 0
stat64("/proc/1/root", {st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0
stat64("/", {st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
{B38400 opost isig icanon echo ...}) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0xb73b67e8) = 4505
gettid()= 4504
mmap2(NULL, 278528, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7172000
sendmsg(3, {msg_name(0)=NULL,
msg_iov(2)=[{"l\1\0\1$\0\0\0\1\0\0\0\240\0\0\0\1\1o\0\31\0\0\0/org/freedesktop/systemd1\0\0\0\0\0\0\0\6\1s\0\30\0\0\0org.freedesktop.systemd1\0\0\0\0\0\0\0\0\2\1s\0
\0\0\0org.freedesktop.systemd1.Manager\0\0\0\0\0\0\0\0\3\1s\0\t\0\0\0StartUnit\0\0\0\0\0\0\0\10\1g\0\2ss\0", 176},
{"\22\0\0\0getty@tty1.service\0\0\7\0\0\0replace\0", 36}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 212
clock_gettime(CLOCK_MONOTONIC, {7805, 7451585}) = 0
poll([{fd=3, events=POLLIN}], 1, 25000) = 1 ([{fd=3, revents=POLLIN}])
recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"l\2\1\1'\0\0\0\1\0\0\0\17\0\0\0\5\1u\0\1\0\0\0\10\1g\0\1o\0\0\"\0\0\0/org/freedesktop/systemd1/job/1415\0", 2048}],
msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 71
recvmsg(3, {msg_name(0)=NULL,
msg_iov(1)=[{"l\4\1\0016\0\0\0\2\0\0\0\233\0\0\0\1\1o\0\"\0\0\0/org/freedesktop/systemd1/job/1415\0\0\0\0\0\0\2\1s\0\37\0\0\0org.freedesktop.DBus.Properties\0\3\1s\0\21\0\0\0PropertiesChanged\0\0\0\0\0\0\0\10\1g\0\10sa{sv}as\0\0\0\6\1s\0\n\0\0\0:no-sender\0\0\0\0\0\0\34\0\0\0org.freedesktop.systemd1.Job\0\0\0\0\0\0\0\0\n\0\0\0\5\0\0\0State\0",
2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 230
recvmsg(3, 0xbfe5b700, MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily
unavailable)
sendmsg(3, {msg_name(0)=NULL,
msg_iov(2)=[{"l\1\0\1\27\0\0\0\2\0\0\0\227\0\0\0\1\1o\0\31\0\0\0/org/freedesktop/systemd1\0\0\0\0\0\0\0\6\1s\0\30\0\0\0org.freedesktop.systemd1\0\0\0\0\0\0\0\0\2\1s\0
\0\0\0org.freedesktop.systemd1.Manager\0\0\0\0\0\0\0\0\3\1s\0\7\0\0\0GetUnit\0\10\1g\0\1s\0\0", 168}, {"\22\0\0\0getty@tty1.service\0", 23}], msg_controllen=0,
msg_flags=0}, MSG_NOSIGNAL) = 191
clock_gettime(CLOCK_MONOTONIC, {7805, 13045269}) = 0
poll([{fd=3, events=POLLIN}], 1, 25000) = 1 ([{fd=3, revents=POLLIN}])
[systemd-devel] Question on debugging getty 'runlevel 3' issue.
I'm using Fedora 19 on a 32-bit dual-core Atom system. I installed Mate, various other packages, and among other configuration, tried to put the system into the equivalent of 'runlevel 3'. The system boots to black console as expected, but it will not give a prompt, except on 'alt F2' window. On clean bootup, if I ssh in, I there are no getty processes running: [root@ct520-128-6034 ~]# ps -auxww|grep getty root 2699 0.0 0.0 4940 860 pts/1S+ 15:03 0:00 grep --color=auto getty [root@ct520-128-6034 ~]# grep -i getty /var/log/messages [root@ct520-128-6034 ~]# ls -l /etc/systemd/system/getty.target.wants/ total 0 lrwxrwxrwx. 1 root root 38 Jun 27 10:12 getty@tty1.service -> /usr/lib/systemd/system/getty@.service [root@ct520-128-6034 ~]# ls -l /usr/lib/systemd/system/getty@.service -rw-r--r--. 1 root root 1662 Jun 24 08:30 /usr/lib/systemd/system/getty@.service [root@ct520-128-6034 ~]# systemctl status getty@tty1.service getty@tty1.service - Getty on tty1 Loaded: loaded (/usr/lib/systemd/system/getty@.service; enabled) Active: inactive (dead) Docs: man:agetty(8) man:systemd-getty-generator(8) http://0pointer.de/blog/projects/serial-console.html A 64-bit server-class system installed in same manner works fine. Any ideas on how to debug this further? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] arch bootstrapping
Am 19.08.2013 21:05, schrieb Zbigniew Jędrzejewski-Szmek: >> Now to do the --populate archlinux, you need to have an archlinux >> keyring in /usr/share/pacman/keyrings/. If you look at the >> `archlinux-keyring` package in arch, that should give you some ideas. > So, I've created a simple archlinux-keyring package for Fedora. > I have one question: is there an official license for the archlinux-keyring > sources? It is just a collection of publicly accessible information, > but it would be much easier if the license (Public Domain?) would > be publicly specified. It seems there is no license in the archlinux-keyring repository, and the Arch Linux package says "GPL", which may not even make sense for this stuff (the package doesn't include the scripts, only the collection of PGP keys). I CC'd Pierre - can we clarify the license on this? signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to wait for a group of devices?
On Mon, Aug 19, 2013 at 10:37 AM, Greg KH wrote: > On Mon, Aug 19, 2013 at 05:35:35PM +0200, Manuel Reimer wrote: >> On 08/19/2013 04:53 PM, Greg KH wrote: >> >>The second one wants to access DVB devices. >> >> >> >>These could be connected via PCI, PCI express or USB. So here I need >> >>"Wait until all possible, currently connected, DVB devices are >> >>initialized and drivers are loaded". >> > >> >Same here, there is no way to ever do this (PCI devices can be >> >hotplugged at anytime, just like USB). >> > >> >Instead, just do something based on _when_ you see a specific type of >> >USB device, that way everything will work properly, no need to "wait" >> >for anything. >> >> I'm not the developer of that daemon. I just want to run it reliably >> on a distribution, using systemd. > > What happens to that daemon if a new device is plugged into the system > while it is already running? It has to handle that properly today, so > there's no need in waiting around for some unknown amount of time for > any reason. > > If it doesn't handle it properly, go poke upstream to get that fixed, as > that's a major bug. I've encountered the problem in e.g. mythtv - if your DVB adapter takes a long time to initialize (40 seconds for my hauppauge cards, for instance, due to some weird FW loading problem), then your system will just boot and run mythbackend, which won't see any DVB tuners, and none of your scheduled recordings will record. This isn't something that can be fixed outside of MythTV. maybe it's been already fixed upstream, but in 0.25.1 this was still a bug. libudev should provide the methods needed to implement a proper fix. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] arch bootstrapping
On Sat, Aug 17, 2013 at 02:50:01PM -0500, William Giokas wrote: > On Sat, Aug 17, 2013 at 05:44:27PM +0200, Daniel Buch wrote: > > I run with SigLevel = Required DatabaseOptional. And i guess that's > > recommended. Have you tried pacman-key --init before you --populate > > archlinux? > > Pacman has it's own `pacman-key` command that interfaces with gpg to > manipulate its keys. What you're probably going to want to do is what > Daniel said, initialize the keyring. This just takes a bunch of entropy > but things will (by default) be put in /etc/pacman.d/gnupg/. Having this > all set up will let you populate it. Here's an example workflow: > > # yum install pacman > # $EDITOR /etc/pacman.conf #[1] > # pacman-key --init # you may need to do things while this happens > > [1]: The SigLevel should be fine at `Required DatabaseOptional`. You may > want to set GPGDir to something else, though the default shouldn't > conflict with anything. Thank you (all three) for useful comments. This is more or less what I was trying to do, but apparently I missed something along the way. Everything seems to work nicely now. > Now to do the --populate archlinux, you need to have an archlinux > keyring in /usr/share/pacman/keyrings/. If you look at the > `archlinux-keyring` package in arch, that should give you some ideas. So, I've created a simple archlinux-keyring package for Fedora. I have one question: is there an official license for the archlinux-keyring sources? It is just a collection of publicly accessible information, but it would be much easier if the license (Public Domain?) would be publicly specified. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to wait for a group of devices?
On Mon, Aug 19, 2013 at 05:35:35PM +0200, Manuel Reimer wrote: > On 08/19/2013 04:53 PM, Greg KH wrote: > >>The second one wants to access DVB devices. > >> > >>These could be connected via PCI, PCI express or USB. So here I need > >>"Wait until all possible, currently connected, DVB devices are > >>initialized and drivers are loaded". > > > >Same here, there is no way to ever do this (PCI devices can be > >hotplugged at anytime, just like USB). > > > >Instead, just do something based on _when_ you see a specific type of > >USB device, that way everything will work properly, no need to "wait" > >for anything. > > I'm not the developer of that daemon. I just want to run it reliably > on a distribution, using systemd. What happens to that daemon if a new device is plugged into the system while it is already running? It has to handle that properly today, so there's no need in waiting around for some unknown amount of time for any reason. If it doesn't handle it properly, go poke upstream to get that fixed, as that's a major bug. greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cryptsetup-generator: allow specifying options in /proc/cmdline
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Am 19.08.2013 13:25, schrieb Thomas Bächler: > Am 19.08.2013 11:58, schrieb Harald Hoyer: >> On 08/19/2013 11:21 AM, Thomas Bächler wrote: >>> Am 19.08.2013 10:34, schrieb Harald Hoyer: Hmm, the naming "luks.options" is IMHO poorly chosen. "options" as an option name... hmm. Also crypttab can contain more encryption modes, than LUKS. Another remark: The option "luks.crypttab" already affects other schemes than luks - it is a generic option that can disable reading of crypttab altogether. Having an option 'crypttab=' even seems more confusing now. What do you think we should do? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSElZIAAoJEChPw0yOSxolzbMP/1DnmmhYtHAyq8koFZbWpsk6 JVWnZnhQrU7Y/QZJyvapWt/dnQY9MOgXzc6s49HE09A40qyLs2WYHM1dXKlx8B5N N9Q5V07xmD0WKbTNztmoIBLouUPv+NzfvF+2HoN+XwVcAuCmU9BV/HLG6V90aI+y 5Eh0pDTO1jFyL7Rhcf81MJus462POJSciLXZOTnXHDDm/42gg3McfT6x+xlcQh1T +aYsLao9Tg9iYXxi0/+LL8Z6KPELAeeaspIZllXa3tYSL6q233cPrqdkxtvCwZFc HMOY65usWNppjrzW9EM554dcoDsQ6iBII2ORPAQiMJnSJgaVUTWgmw5AJKNLAeRS X6SKf9STQtDSPpEpyyHNn4pl2wMW+olJ1VgU1s+NNgjw9ryRt04e/iD3cNHbCecI CnXFjDUbXM5aGef4OIk7hzK2CraOcFXagHzgUTF0HCxQLeNrnLwIsqtErnCAfLOL 7rNdwn2rbZfW278dT9A1LVDjNXYk9FwMaHBbQpIsuQSuhn9geU2LKOqBd9LWYzff KaPLg4O81H1Lb+JNduQKrRSN6ZCTkfSvjI/1/2Ro7hXK2hEbvX5doU94pfRJuPrn Yz50SEVNiGpWxmdoY+ADmJ1RSAHJ8gQgtRGki7AF2aE1Cj07f5uES/H/PCWbdvw6 OC1onClOzAw6OELeDHgt =a2Ge -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to wait for a group of devices?
On Mon, Aug 19, 2013 at 5:35 PM, Manuel Reimer wrote: > On 08/19/2013 04:53 PM, Greg KH wrote: >>> >>> The second one wants to access DVB devices. >>> >>> These could be connected via PCI, PCI express or USB. So here I need >>> "Wait until all possible, currently connected, DVB devices are >>> initialized and drivers are loaded". >> >> >> Same here, there is no way to ever do this (PCI devices can be >> hotplugged at anytime, just like USB). >> >> Instead, just do something based on _when_ you see a specific type of >> USB device, that way everything will work properly, no need to "wait" >> for anything. > > > I'm not the developer of that daemon. I just want to run it reliably on a > distribution, using systemd. > > Isn't there some kind of event, I can wait for, when the system did the > first run over the connected devices? As Greg already said, there is no point in time where we could send out such an event. If you want, read it as: systemd boots up and enumerates devices until you shut down the system. Such a daemon needs to monitor new devices, build its own list/tree of it, and starts using them when it decides they are ready to be used. For legacy applications, which are too simple to do that, "udevadm settle" is the only tool that can provide something like that. There is nothing in the base OS could claim to be able to send an event for the state of "everything is there" or "there are no more devices to expect", it's just not how things work or should work. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to wait for a group of devices?
On 08/19/2013 04:53 PM, Greg KH wrote: The second one wants to access DVB devices. These could be connected via PCI, PCI express or USB. So here I need "Wait until all possible, currently connected, DVB devices are initialized and drivers are loaded". Same here, there is no way to ever do this (PCI devices can be hotplugged at anytime, just like USB). Instead, just do something based on _when_ you see a specific type of USB device, that way everything will work properly, no need to "wait" for anything. I'm not the developer of that daemon. I just want to run it reliably on a distribution, using systemd. Isn't there some kind of event, I can wait for, when the system did the first run over the connected devices? Greetings, Manuel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to wait for a group of devices?
On Mon, Aug 19, 2013 at 04:10:22PM +0200, Manuel Reimer wrote: > Hello, > > I need two service files for two daemons. > > The first one expects some type of device to be accessible via USB. > > So what I need for this one is something like "Wait until all currently > plugged in USB devices are enumerated and the relevant kernel modules > have been loaded". There is no way to ever know that "all plugged in USB devices are enumerated". USB has no such knowledge of this, so wanting to wait for it, would mean you just wait for forever. So you might want to rethink your requirement, unless you like impossible requirements :) > The second one wants to access DVB devices. > > These could be connected via PCI, PCI express or USB. So here I need > "Wait until all possible, currently connected, DVB devices are > initialized and drivers are loaded". Same here, there is no way to ever do this (PCI devices can be hotplugged at anytime, just like USB). Instead, just do something based on _when_ you see a specific type of USB device, that way everything will work properly, no need to "wait" for anything. thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] How to wait for a group of devices?
Hello, I need two service files for two daemons. The first one expects some type of device to be accessible via USB. So what I need for this one is something like "Wait until all currently plugged in USB devices are enumerated and the relevant kernel modules have been loaded". The second one wants to access DVB devices. These could be connected via PCI, PCI express or USB. So here I need "Wait until all possible, currently connected, DVB devices are initialized and drivers are loaded". Is there something like that? "udevadm settle" doesn't seem to do the trick. Thank you in advance Yours Manuel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cryptsetup-generator: allow specifying options in /proc/cmdline
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Am 19.08.2013 11:58, schrieb Harald Hoyer: > On 08/19/2013 11:21 AM, Thomas Bächler wrote: >> Am 19.08.2013 10:34, schrieb Harald Hoyer: >>> Hmm, the naming "luks.options" is IMHO poorly chosen. "options" >>> as an option name... hmm. Also crypttab can contain more >>> encryption modes, than LUKS. >>> >>> If you want to reflect crypttab, why not specify something >>> like: >>> >>> [rd.]crypttab=;;; > >> So, systemd-cryptsetup-generator currently reads luks, >> luks.crypttab, luks.uuid and luks.key (+ the rd. variants). Now >> you are proposing to add a 'crypttab' option as well. This seems >> awfully inconsistent to me. > > Well, I think before adding more and more rd.luks parameters, we > might want to step back and add one option, which supports all. When you phrase it that way, I must fully agree. > An object oriented syntax might be: > > rd.luks..name= rd.luks..options= > rd.luks..password= > > This of course would have made parsing with shell functions > unpractical. > > Now that we already have rd.luks.uuid= adding parameters to > results in > > rd.luks.options== rd.luks.name== > rd.luks.password== > > Both solutions blow up the length of the kernel command line and > make it really unreadable. Agreed. Your initial [rd.]crypttab=;;; proposal sounds reasonable. Is ';' a good separator for this (I think it is, just making sure I don't overlook something)? Should the [rd].luks* options be deprecated at the same time? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSEgDEAAoJEChPw0yOSxolVQgP/3hAox/FdrCKi7BMs5rsSe+r NHXnu9nOngBLRHw/DnICQ5HoMAX1HDHLUOdqeWOt4XVI0jn4RDFivzIZnSmpf6QS zi8/oltC38gBd8LyKNfklt3tF6xw5/pfrIBe6DGa6clYywUd9daIsdOXN3sh7yHK InEn3oyfPA4Eno0p5d6hKn4g03KJlsgm313V2Fxr97y6enu2yJjeemlmdOoyMeNf FcUqphobaJWiGYqePEyLJtKoaNq91h6CnLNVQJ8dIIleZeGmCwwpv8xT4A8WyjXQ cRIrDvo7bHMBIHPdFV+UPZ+Crn7OTnJBDTKFJzttnEY8AYI4vpc7kcuTD8yVHxln K/c/NGEuYjO50e26Sso12kFicTXexdXxdELijMZ2MzHpTd6hFeHwa9R5/ts3ZasS AQJLqtVOpJMT2EMnk48JLgOpkgGJiXTs8wC08DMuYP1KjOWa43/EFy1KCHoA6N8G L47meHpIw0EzRgMXtXGBcmFKDbrGZeuX/gxnhAAw17ZO1X0K5sY1Y2FWanc21kqq Zn3PK1OHGlLwiqhblo6hrv0LNRNh1oYJtbQel1DbS60v8Pq3qidsb0IVB8vUuZ8M Zgnjk7N1GgY2DiYkBVjzpvD7og74hK8pf4vvRC/WkmbOsG2VqW1grejzAoF8T1I0 P/f/Zne4C5KGYvBdHhV2 =gtpu -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cryptsetup-generator: allow specifying options in /proc/cmdline
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/19/2013 11:21 AM, Thomas Bächler wrote: > Am 19.08.2013 10:34, schrieb Harald Hoyer: >> Hmm, the naming "luks.options" is IMHO poorly chosen. "options" as an >> option name... hmm. Also crypttab can contain more encryption modes, than >> LUKS. >> >> If you want to reflect crypttab, why not specify something like: >> >> [rd.]crypttab=;;; > > So, systemd-cryptsetup-generator currently reads luks, luks.crypttab, > luks.uuid and luks.key (+ the rd. variants). Now you are proposing to add a > 'crypttab' option as well. This seems awfully inconsistent to me. Well, I think before adding more and more rd.luks parameters, we might want to step back and add one option, which supports all. An object oriented syntax might be: rd.luks..name= rd.luks..options= rd.luks..password= This of course would have made parsing with shell functions unpractical. Now that we already have rd.luks.uuid= adding parameters to results in rd.luks.options== rd.luks.name== rd.luks.password== Both solutions blow up the length of the kernel command line and make it really unreadable. This is why I propose to simplify the whole thing and just mirror what we already support with the crypttab file. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSEewvAAoJEANOs3ABTfJwzLIQAMfKxeRXkVTklsI6EYYpMQ4X z8F7Mg5Vu79taEZ+e+t71s9U/wNdX6hkCysHQ1qXs8+1IvqxyaFRtdC8HHBSZB0/ CBT6L9v/tH+WOKlEjJesOHPKV1zg2uxRKCHc74bBHdKVJqUrqgB+u42CDsRYq7a0 xgL2Ebvh99a8RoKJEDr+9/Ty+5KgTM0y99z3Wk12JPqAeK+N5z5pnbe6RAW89tG2 f3OjN7Ejf6c+BuJc0S+Eod/2pMV7ccgJJFhKAUQyFYaFfZgG8Wo5sxnUC0SIj508 /MkpVdgrTSsBQt8HxVrlFXm4Zj0M3rA5HsRF77PCPPpJKbU4YAoxkKwMMr6bGEQo 7eeZh3DI/jnpS/QFCDaedDRblWP7rs9e3uso+NDyphq0Th2mg5XiYvhCVsDo5VTX Ys3o78tcfCUyCSdrNhJ+A3hoKxPI9vn1AmA/AnGyI3WMgXiCFJWtGvR6Us5ClTBh iYtZvgZexikpqlZXNN3nBjf6J6hxvtNHFpsAweLrigrMBWrJ4cU4nmrWb2A/ei4G 4h/Z60YQmCKXhymmNQGcZMBpzSGfXdDgLqIbtzdFvvRwPBtG2wuvO+cZaCeF0Dye 3oiOYtoLaIGzfPTvUGbV3FSzAb5Cvjy83qSQMmiDeh5pyAIcBqCpmTUKM4cx4ait xptLc2g2ra1/O59vSyiX =sjhR -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cryptsetup-generator: allow specifying options in /proc/cmdline
Am 19.08.2013 10:34, schrieb Harald Hoyer: > Hmm, the naming "luks.options" is IMHO poorly chosen. "options" as an option > name... hmm. Also crypttab can contain more encryption modes, than LUKS. > > If you want to reflect crypttab, why not specify something like: > > [rd.]crypttab=;;; So, systemd-cryptsetup-generator currently reads luks, luks.crypttab, luks.uuid and luks.key (+ the rd. variants). Now you are proposing to add a 'crypttab' option as well. This seems awfully inconsistent to me. OTOH, allowing to give more options on the command line would open the door to more encryption schemes than just LUKS (which I don't particularly care about). I just fear that syntax gets more confusing when allowing many ways to achieve the same goal. >rd.luks.allow-discards= >Allow using of discards (TRIM) requests for LUKS partitions with >the given UUID. Any "luks-" of the LUKS UUID is removed before >comparing to . The comparisons also matches, if uuid> is only the beginning of the LUKS UUID, so you don't have to >specify the full UUID. This parameter can be specified multiple >times. > >rd.luks.allow-discards >Allow using of discards (TRIM) requests on all LUKS partitions. So 1) you are not actually using systemd-cryptsetup-generator, 2) you single out this one option and don't support the rest. signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cryptsetup-generator: allow specifying options in /proc/cmdline
On 08/18/2013 06:15 PM, Tom Gundersen wrote: > The main usecase for this is to make it possible to use cryptsetup in > the initrd without it having to include a host-specific /etc/crypttab. > > Cc: Harald Hoyer > Tested-by: Thomas Bächler > --- > > Hi guys, > > This allows us to use systemd in the initrd for encrypted root in Arch. I > didn't look much into how this is done in dracut, so comments on whether > or not this will work for you would be welcome. > > Cheers, > > Tom > Hmm, the naming "luks.options" is IMHO poorly chosen. "options" as an option name... hmm. Also crypttab can contain more encryption modes, than LUKS. If you want to reflect crypttab, why not specify something like: [rd.]crypttab=;;; As for dracut, here is what we currently have: https://www.kernel.org/pub/linux/utils/boot/dracut/dracut.html#_crypto_luks $ man dracut.cmdline crypto LUKS rd.luks=0 disable crypto LUKS detection rd.luks.uuid= only activate the LUKS partitions with the given UUID. Any "luks-" of the LUKS UUID is removed before comparing to . The comparisons also matches, if is only the beginning of the LUKS UUID, so you don't have to specify the full UUID. This parameter can be specified multiple times. rd.luks.allow-discards= Allow using of discards (TRIM) requests for LUKS partitions with the given UUID. Any "luks-" of the LUKS UUID is removed before comparing to . The comparisons also matches, if is only the beginning of the LUKS UUID, so you don't have to specify the full UUID. This parameter can be specified multiple times. rd.luks.allow-discards Allow using of discards (TRIM) requests on all LUKS partitions. rd.luks.crypttab=0 do not check, if LUKS partition is in /etc/crypttab ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
