FS#11352 - [udev] Use /dev/tty* standard instead of old /dev/vc*
Attached to Project:
Arch Linux
Opened by Xavier (shining) - Sunday, 31 August 2008, 10:31 GMT
Last edited by Allan McRae (Allan) - Monday, 20 July 2009, 03:11 GMT
Opened by Xavier (shining) - Sunday, 31 August 2008, 10:31 GMT
Last edited by Allan McRae (Allan) - Monday, 20 July 2009, 03:11 GMT
|
Details
Description:
Arch should use the /dev/tty* standard instead of old /dev/vc* devices. See also From my experience, this is the main difference that prevents vanilla udev to be usable on an Arch system. A simple grep reveals which files are affected : $ grep -r "vc/" /etc The main ones are /etc/securetty , /etc/inittab and /etc/rc.sysinit For these three files, a simple sed line will do the job : sed -e 's#vc/#tty#' Then there is syslog-ng which mentions vc/12 but it is disabled by default : # Log everything to vc12 destination console_all { file("/dev/vc/12"); }; # Log everything to vc12 #log { source(src); destination(console_all); }; Finally, the udev rule could be changed so that vc/* are the symlinks to tty*, and not the other way around. KERNEL=="tty[0-9]*", GROUP="tty", MODE="0620", NAME="vc/%n", SYMLINK+="%k" OPTIONS="last_rule" Maybe this would work, but I am not sure at all, and don't know what this last_rule thing is either. KERNEL=="tty[0-9]*", GROUP="tty", MODE="0620", SYMLINK+="vc/%n" OPTIONS="last_rule" But when we are sure the old devices are no longer used by anything, the symlinks can be simply dropped. |
This task depends upon
Closed by Allan McRae (Allan)
Monday, 20 July 2009, 03:11 GMT
Reason for closing: Implemented
Additional comments about closing: All patches here have been applied to the packages currently in [testing]
Monday, 20 July 2009, 03:11 GMT
Reason for closing: Implemented
Additional comments about closing: All patches here have been applied to the packages currently in [testing]
7 char Virtual console capture devices
0 = /dev/vcs Current vc text contents
1 = /dev/vcs1 tty1 text contents
...
63 = /dev/vcs63 tty63 text contents
128 = /dev/vcsa Current vc text/attribute contents
129 = /dev/vcsa1 tty1 text/attribute contents
...
191 = /dev/vcsa63 tty63 text/attribute contents
I currently running the my system with /dev/tty* scheme without vc/* and vcc/* symlinks. Boot and works OK.
Only I changed /etc/{inittab,rc.sysinit,securetty,syslog-ng.conf} and commented the lines in /lib/udev/rules.d/81-arch.rules
# consoles
# KERNEL=="tty[0-9]*", NAME="vc/%n", SYMLINK+="%k"
# KERNEL=="vcs", NAME="vcc/0"
# KERNEL=="vcs[0-9]*", NAME="vcc/%n"
# KERNEL=="vcsa", NAME="vcc/a0"
# KERNEL=="vcsa[0-9]*" NAME="vcc/a%n"
I always wondered why we had this devfs-like scheme instead of the classic /dev/tty* (I don't know what vcs or vcsa devices are though). Also, we have /dev/tts/* instead of /dev/ttyS*.
initscripts: /etc/{inittab,rc.sysinit}
filesystem: /etc/securetty
syslog-ng: /etc/syslog-ng.conf
udev: /lib/udev/rules.d/81-arch.rules
A quick search in the bug tracker shows a few initscript issues, so maybe we should do this a part of a big fixup for those.
FS#13728- [initscripts] minilogd.c always eat memory on buflines>=MAX_BUF_LINESFS#13263- [initscripts] Fix array count/walk in rc.shutdown and rc.singleFS#12978- [initscripts] rc.single fixesFS#12063- [initscripts] At the end of /etc/rc.sysinit there is a useless checkFS#13949- [filesystem] bad/old entries in /etc/nsswitch.confFS#12661- [filesystem] uucp is missing in /etc/gshadowFS#10910- [filesystem] /etc/group should contain the locate group by defaultI try to disable the rules that apply to my system and I will see how it behaves ;)
Anyway, can you summarize all the paths you think are non-standard (including the ones already mentioned) and post them here? Is there a document with standards, for example, does the LSB say anything about /dev layout?
Attached a patch for 81-arch.rules, removing/fixing related rules.
I cite comments from 81-arch.rules
# consoles
/dev/vc/*
/dev/vcc/*
# serial
/dev/tts/*
# mem
/dev/rd/*
# video4linux
/dev/v4l/*
# video devices
/dev/misc/agpgart
/dev/fb/*
# i2c devices
/dev/i2c/*
# loop devices
/dev/loop/*
# misc
/dev/misc/nvram
/dev/misc/psaux
/dev/misc/inotify (but the device /dev/inotify don't exist, now inotify is via syscalls)
# sound devices
/dev/sound/*
# netlink devices
/dev/netlink/* (Rare scheme. Also netlinks devs are obsolete, are for linux 2.0, netlink since linux 2.2 is via sockets *)
# miscellaneous
/dev/misc/rtc*
FS#13949- [filesystem] bad/old entries in /etc/nsswitch.confI add this one, remain decision of this: "
FS#14214[syslog-ng] use all necesary libs as shared instead of static" (patch provided in latest comment)For all users posted here are agree with the changes. Only applying the four patches is the remain: filesystem + syslog-ng + udev + initscript.
btw: any decision on this? For example (if your prefer) can prepare the system for the "udev" change in smooth way:, the pkgs "filesystem" and "initscripts" can be updated both at the same time (is important to update these at the same time, if not root can not login in ttys), without needed updated "udev", also this is applied to "syslog-ng". This is because changing these packages, will works via the current symlinks. ;)
And in second stage can release a new udev with the changes, removing all old devices names. A small break exists because the change of /lib/udev/devices/loop0 (symlink -> special file) pacman -Sf will be needed. or just rm "/lib/udev/devices/loop0" before the update. An annonunce in webpage is a good idea. ;)
Thats all folks!
Note: we should check with the installer gus whether this would cause them issues. I don't expect it to, but given they are ramping up for a new release...
"And in second stage can release a new udev with the changes, removing all old devices names. A small break exists because the change of /lib/udev/devices/loop0 (symlink -> special file) pacman -Sf will be needed. or just rm "/lib/udev/devices/loop0" before the update. An annonunce in webpage is a good idea. ;)"
I cannot reproduce this conflict, could you double-check?
But I have patches to fix this in the simple case, where it is the same package doing the replacement.
Just tested it on a chroot:
# pacman -S udev-141-3... (from core)
# ls -l /lib/udev/devices/loop0
lrwxrwxrwx 1 root root 6 Jun 7 11:48 /lib/udev/devices/loop0 -> loop/0
# pacman -U udev-141-5...(from testing + with the patch)
# ls -l /lib/udev/devices/loop0
brw-rw---- 1 root disk 7, 0 Jul 20 00:07 /lib/udev/devices/loop0
No problems, bad alert sorry :)