Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

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
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Tobias Powalowski (tpowa)
Aaron Griffin (phrakture)
Thomas Bächler (brain0)
Roman Kyrylych (Romashka)
Allan McRae (Allan)
Architecture All
Severity Low
Priority Normal
Reported Version None
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Description:
Arch should use the /dev/tty* standard instead of old /dev/vc* devices.
See also  FS#3826 
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]
Comment by Roman Kyrylych (Romashka) - Sunday, 31 August 2008, 21:05 GMT
klibc-* packages will require modification too.
Comment by Gerardo Exequiel Pozzi (djgera) - Thursday, 07 May 2009, 01:40 GMT
Also don't follow this rule, still uses /dev/vcc/* from DEVFS instead of this:

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
Comment by Gerardo Exequiel Pozzi (djgera) - Thursday, 07 May 2009, 03:23 GMT
Btw: There is no problem at klibc-* and mkinitcpio. *kdb programs search first for /dev/tty* then fails try another schemes.

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"
Comment by Thomas Bächler (brain0) - Thursday, 07 May 2009, 09:53 GMT
klibc doesn't have problems, as it runs before init is launched and thus only /dev/console is being accessed.

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*.
Comment by Thomas Bächler (brain0) - Thursday, 07 May 2009, 09:54 GMT
Assigning to Allan too, as he does lots of core stuff these days.
Comment by Allan McRae (Allan) - Thursday, 07 May 2009, 10:47 GMT
Summary note of packages/files that need changed:

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.
Comment by Gerardo Exequiel Pozzi (djgera) - Thursday, 07 May 2009, 13:13 GMT
@Allan: This is a list of task related to filesystem/initscripts packages that I opened/watch all with fixes or trivial solution:

 FS#13728  - [initscripts] minilogd.c always eat memory on buflines>=MAX_BUF_LINES
 FS#13263  - [initscripts] Fix array count/walk in rc.shutdown and rc.single
 FS#12978  - [initscripts] rc.single fixes
 FS#12063  - [initscripts] At the end of /etc/rc.sysinit there is a useless check
 FS#13949  - [filesystem] bad/old entries in /etc/nsswitch.conf
 FS#12661  - [filesystem] uucp is missing in /etc/gshadow
 FS#10910  - [filesystem] /etc/group should contain the locate group by default
Comment by Gerardo Exequiel Pozzi (djgera) - Friday, 08 May 2009, 17:42 GMT
@Thomas: Yes, I seeing a little more, the file 81-arch.rules, has as main objective to organize the /dev as a devfs-like. So this is also apply to /dev/sound /dev/v4l /dev/misc and others. Quote: "# This ruleset should provide a DevFS-compatible device tree", had not paid attention before.

I try to disable the rules that apply to my system and I will see how it behaves ;)
Comment by Thomas Bächler (brain0) - Friday, 08 May 2009, 20:54 GMT
I think that comment is left over from ancient times. Not much of it is devfs-like.

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?
Comment by Gerardo Exequiel Pozzi (djgera) - Saturday, 09 May 2009, 00:53 GMT
Yes, in kernel source see Documentation/devices.txt ;)

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*
Comment by Gerardo Exequiel Pozzi (djgera) - Saturday, 09 May 2009, 04:59 GMT
oops reupload, this is against original 81-arch.rules, sorry :s


Comment by Gerardo Exequiel Pozzi (djgera) - Thursday, 28 May 2009, 03:26 GMT
Here are all the necesary patches against latest GIT or SVN...
Comment by Thomas Bächler (brain0) - Thursday, 28 May 2009, 07:00 GMT
I am definitely in favor of this - and Gerardo has done all the work already - still I'd like some confirmation. What do the other devs think here?
Comment by Allan McRae (Allan) - Thursday, 28 May 2009, 08:58 GMT
This looks good to me. I think we should just applying those patches and the ones from the bug reports mentioned above and stick the rebuilds into [testing].
Comment by Tobias Powalowski (tpowa) - Thursday, 28 May 2009, 20:51 GMT
Seems good, haven't tried the changes but everything should work with it.
Comment by Gerardo Exequiel Pozzi (djgera) - Saturday, 13 June 2009, 22:57 GMT
OK at this time, all task posted above are fixed with the except of  FS#13949  - [filesystem] bad/old entries in /etc/nsswitch.conf
I 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.
Comment by Gerardo Exequiel Pozzi (djgera) - Sunday, 12 July 2009, 04:25 GMT
Attached a fix for pkgbuild for udev, to only create a /lib/udev/devices/loop0 and not the symlink /lib/udev/devices/ loop0 -> loop/0 (against latest trunk)

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!
Comment by Allan McRae (Allan) - Sunday, 12 July 2009, 05:12 GMT
Once [testing] is a bit clearer (libjpeg+boost moves), I am happy to do this. The are lots of changes in git for the initscripts and on svn truck for filesystem that need a push anyway.

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...
Comment by Gerardo Exequiel Pozzi (djgera) - Saturday, 18 July 2009, 06:01 GMT
Fix for initscript to match the current rtc udev rule.
Comment by Xavier (shining) - Sunday, 19 July 2009, 12:39 GMT
djgera:
"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?
Comment by Thomas Bächler (brain0) - Sunday, 19 July 2009, 12:59 GMT
These conflicts only occur when a symlink to a directory is becoming an actual non-empty directory (or vice versa? no idea). Replacing symlinks to files by files should be fine.
Comment by Xavier (shining) - Sunday, 19 July 2009, 15:05 GMT
indeed, directory symlink vs directory is currently problematic in both directions.
But I have patches to fix this in the simple case, where it is the same package doing the replacement.
Comment by Gerardo Exequiel Pozzi (djgera) - Monday, 20 July 2009, 00:10 GMT
@Xavier: ohh! true no problem in this case (I was confused with directory <-> file)

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 :)

Loading...