Re: [systemd-devel] udev 182 and kernel 3.6.7
Using udevadm as you suggested yielded some interesting results. Under
kernel 3.6.7 70-persistent-cd.rules does in fact get loaded, however
ID_PATH is no longer exported, which is what 70-persistent-cd.rules uses to
identify the DVD-ROM on my system. While I am able to get udev working
properly with ENV{ID_SERIAL_SHORT}, I was wondering if the lack of ID_PATH
is because of a turned off option in the kernel or the removal of it?
On Sat, Nov 24, 2012 at 8:29 AM, Kay Sievers k...@vrfy.org wrote:
On Sat, Nov 24, 2012 at 8:55 AM, Nelson dim...@gmail.com wrote:
While my issue is still with udev 182 and kernel 3.6.7, does
70-persistent-cd.rules even get USED at all if it was created beforehand
with 183?
Yes, it should still work. Just new devices would not be automatically
added.
Newer udev versions dropped all persistent rule generators, we will
not create any system config from device hotplug handlers anymore. It
turned out to be the wrong thing and it created more problems than it
solved.
Regarding the initial question, there are no known kernel changes
which would make these rules not work anymore. The only reports so far
are from people who somehow enabled IDE drivers (/dev/hda) instead of
libata (/dev/sr0), which will not work with the rules.
You might want to check with:
udevadm test /sys/class/block/sr0
if it tells what's going wrong.
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev 182 and kernel 3.6.7
Also wondering, if this isn't a kernel issue then why does
70-persistent-cd.rules get generated if it's missing under kernel 3.2.29,
but under 3.6.7 it does not?
On Sat, Nov 24, 2012 at 1:44 PM, Nelson dim...@gmail.com wrote:
Using udevadm as you suggested yielded some interesting results. Under
kernel 3.6.7 70-persistent-cd.rules does in fact get loaded, however
ID_PATH is no longer exported, which is what 70-persistent-cd.rules uses to
identify the DVD-ROM on my system. While I am able to get udev working
properly with ENV{ID_SERIAL_SHORT}, I was wondering if the lack of ID_PATH
is because of a turned off option in the kernel or the removal of it?
On Sat, Nov 24, 2012 at 8:29 AM, Kay Sievers k...@vrfy.org wrote:
On Sat, Nov 24, 2012 at 8:55 AM, Nelson dim...@gmail.com wrote:
While my issue is still with udev 182 and kernel 3.6.7, does
70-persistent-cd.rules even get USED at all if it was created beforehand
with 183?
Yes, it should still work. Just new devices would not be automatically
added.
Newer udev versions dropped all persistent rule generators, we will
not create any system config from device hotplug handlers anymore. It
turned out to be the wrong thing and it created more problems than it
solved.
Regarding the initial question, there are no known kernel changes
which would make these rules not work anymore. The only reports so far
are from people who somehow enabled IDE drivers (/dev/hda) instead of
libata (/dev/sr0), which will not work with the rules.
You might want to check with:
udevadm test /sys/class/block/sr0
if it tells what's going wrong.
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev 182 and kernel 3.6.7
While my issue is still with udev 182 and kernel 3.6.7, does 70-persistent-cd.rules even get USED at all if it was created beforehand with 183? On Sat, Nov 24, 2012 at 12:35 AM, Jan Engelhardt jeng...@inai.de wrote: On Saturday 2012-11-24 06:08, Nelson wrote: Currently on Slackware 14.0 and that came with udev 182 and kernel 3.2.29. Under this configuration udev works properly, specifically /etc/udev/rules.d/70-persistent-cd.rules gets recreated if it doesn't exist and it is also USED to create certain links and dev nodes such as /dev/dvdrom. Once I move onto kernel 3.6.7 udev begins to act weird. /etc/udev/rules.d/70-persistent-cd.rules does not seem to be used at all, nor is it recreated if it gets removed. Somewhat related to the problem is that, starting with systemd-183, 70-persistent-cd.rules does not get created *at all* anymore, because the write_cd_rules script has been removed by Kay Sievers in commit 3e2147858f21943d5f4a781c60f33ac22c6096ed (move imported udev into place), but the commit messages leaves no trace as to why some files were removed. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] vgetty under systemd
On 7/16/2011 1:20 PM, Lennart Poettering wrote: On Sat, 16.07.11 10:43, Ryan Nelson (ryan.freedesk...@rnelnet.com) wrote: Ok, so I read more on systemd (and the man page for inittab) and came up with a basic vgetty.service that I'm using with systemd. After doing little ready its pretty easy. So I wanted to ask if I can make my service file better than this: --snip /lib/systemd/system/vgetty.service-- # This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it # under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 2 of the License, or # (at your option) any later version. This file isn't really part of systemd, is it? So the header can go... Changed [Unit] Description=Program to answer voice calls using Vgetty After=syslog.target [Service] ExecStart=-/sbin/vgetty /dev/ttyS2 Restart=always RestartSec=0 KillMode=process Why KillMode=process? It was part of the example, it should work as you only need to kill vgetty but control-group would work too, removed the KillMode option. [Install] WantedBy=multi-user.target As mentioned in my other response: consider making this a template you can easily enable for multiple ports by symlinking it to vgett@ttyS0.service, vgetty@ttyS1.service and so on. Right, but then how many do you include. So I took at look at the getty on and it has BindTo=dev-%i.device where does %i come from. Can I use this in a vgetty.service implementation so I don't have to specify the device? --snip vgetty.service-- # This is a basic .service file used with systemd to control vgetty. # # Vgetty turns your voice modem into an answering machine. # It is apart of the mgetty package. http://alpha.greenie.net/vgetty/ [Unit] Description=Vgetty turns your voice modem into an answering machine After=syslog.target [Service] ExecStart=-/sbin/vgetty /dev/ttyS2 Restart=always RestartSec=0 [Install] WantedBy=multi-user.target --end snip-- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] vgetty under systemd
Ok, so I read more on systemd (and the man page for inittab) and came up with a basic vgetty.service that I'm using with systemd. After doing little ready its pretty easy. So I wanted to ask if I can make my service file better than this: --snip /lib/systemd/system/vgetty.service-- # This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it # under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 2 of the License, or # (at your option) any later version. [Unit] Description=Program to answer voice calls using Vgetty After=syslog.target [Service] ExecStart=-/sbin/vgetty /dev/ttyS2 Restart=always RestartSec=0 KillMode=process [Install] WantedBy=multi-user.target --end snip-- thanks, Ryan On 7/15/2011 10:35 AM, Ryan Nelson wrote: I did a minimal search on your list and longer on the web about trying to get vgetty working under systemd. Forgive me although I just learning about systemd. So I use to have vgetty a program under the mgetty software working as an answering machine. I would get calls would be picked up and then acted apone via vgetty, under Sys V by the following line: --snip inittab-- S1:2345:respawn:/sbin/vgetty ttyS2 --end snip-- under upstart the following file did the same: --snip /etc/event.d/ttyS2-- # ttyS2 - vgetty # # This service maintains a getty on tty1 from the point the system is # started until it is shut down again. start on stopped rc2 start on stopped rc3 start on stopped rc4 start on stopped rc5 stop on runlevel 0 stop on runlevel 1 stop on runlevel 6 respawn exec /sbin/vgetty ttyS2 --end snip-- I'm trying to determine how to get the same functionality working under systemd. I suppose I have to generate a .service file however I don't know how to do this for this service. Any help would be grateful! Thanks in advance for info, Ryan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] vgetty under systemd
I did a minimal search on your list and longer on the web about trying to get vgetty working under systemd. Forgive me although I just learning about systemd. So I use to have vgetty a program under the mgetty software working as an answering machine. I would get calls would be picked up and then acted apone via vgetty, under Sys V by the following line: --snip inittab-- S1:2345:respawn:/sbin/vgetty ttyS2 --end snip-- under upstart the following file did the same: --snip /etc/event.d/ttyS2-- # ttyS2 - vgetty # # This service maintains a getty on tty1 from the point the system is # started until it is shut down again. start on stopped rc2 start on stopped rc3 start on stopped rc4 start on stopped rc5 stop on runlevel 0 stop on runlevel 1 stop on runlevel 6 respawn exec /sbin/vgetty ttyS2 --end snip-- I'm trying to determine how to get the same functionality working under systemd. I suppose I have to generate a .service file however I don't know how to do this for this service. Any help would be grateful! Thanks in advance for info, Ryan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
