[arch-general] /dev/tty* borked ...
Hi folks, My system is uptodate with the current testing repo. During bootup today I noticed the error message: /etc/rc.sysinit: line 364: /dev/tty[0-9]*: no such file or directory To my surprise, only /dev/tty was present, but none of tty0..9. Instead there was a device literally named '/dev/tty[0-9]*' !! I deleted the latter, and attempted to create the missing ones with mknod. But I think I took the wrong major number, and now my system has started to behave a bit crazy... Any idea what I should do to restore it to sanity? Thanks, F
On Thu, Oct 8, 2009 at 5:01 PM, Firmicus <Firmicus@gmx.net> wrote:
Hi folks,
My system is uptodate with the current testing repo. During bootup today I noticed the error message: /etc/rc.sysinit: line 364: /dev/tty[0-9]*: no such file or directory To my surprise, only /dev/tty was present, but none of tty0..9. Instead there was a device literally named '/dev/tty[0-9]*' !! I deleted the latter, and attempted to create the missing ones with mknod. But I think I took the wrong major number, and now my system has started to behave a bit crazy... Any idea what I should do to restore it to sanity?
Hmmm, bad udev rule? Udev should be creating these devices. More to the point, though, your inittab should be using those devices, so if they don't exist, it should never get to rc.sysinit. Was there a udev update recently?
Firmicus schrieb:
Hi folks,
My system is uptodate with the current testing repo. During bootup today I noticed the error message: /etc/rc.sysinit: line 364: /dev/tty[0-9]*: no such file or directory To my surprise, only /dev/tty was present, but none of tty0..9. Instead there was a device literally named '/dev/tty[0-9]*' !! I deleted the latter, and attempted to create the missing ones with mknod. But I think I took the wrong major number, and now my system has started to behave a bit crazy... Any idea what I should do to restore it to sanity?
Thanks, F
rm -f /etc/udev/rules.d/udev.rules
Thomas Bächler a écrit :
Firmicus schrieb:
Hi folks,
My system is uptodate with the current testing repo. During bootup today I noticed the error message: /etc/rc.sysinit: line 364: /dev/tty[0-9]*: no such file or directory To my surprise, only /dev/tty was present, but none of tty0..9. Instead there was a device literally named '/dev/tty[0-9]*' !! I deleted the latter, and attempted to create the missing ones with mknod. But I think I took the wrong major number, and now my system has started to behave a bit crazy... Any idea what I should do to restore it to sanity?
Thanks, F
rm -f /etc/udev/rules.d/udev.rules
All right. Danke Thomas! Rebooting now... 0 o .
Firmicus a écrit :
Thomas Bächler a écrit :
Firmicus schrieb:
Hi folks,
My system is uptodate with the current testing repo. During bootup today I noticed the error message: /etc/rc.sysinit: line 364: /dev/tty[0-9]*: no such file or directory To my surprise, only /dev/tty was present, but none of tty0..9. Instead there was a device literally named '/dev/tty[0-9]*' !! I deleted the latter, and attempted to create the missing ones with mknod. But I think I took the wrong major number, and now my system has started to behave a bit crazy... Any idea what I should do to restore it to sanity?
Thanks, F
rm -f /etc/udev/rules.d/udev.rules
All right. Danke Thomas! Rebooting now...
0 o .
... and back! That was it indeed. Ah, well, how long did I live with that antediluvian udev.rules file? It was dated March 2008 and did not even belong to the udev package... Wonder what ill it caused otherwise. Well. Gone now. Thanks again. F
My system is uptodate with the current testing repo. During bootup today I noticed the error message: /etc/rc.sysinit: line 364: /dev/tty[0-9]*: no such file or directory To my surprise, only /dev/tty was present, but none of tty0..9. Instead there was a device literally named '/dev/tty[0-9]*' !! I deleted the latter, and attempted to create the missing ones with mknod. But I think I took the wrong major number, and now my system has started to behave a bit crazy... Any idea what I should do to restore it to sanity?
rm -f /etc/udev/rules.d/udev.rules
... and back! That was it indeed. Ah, well, how long did I live with that antediluvian udev.rules file? It was dated March 2008 and did not even belong to the udev package... Wonder what ill it caused otherwise. Well. Gone now. Thanks again.
That file is a real mistery, I didn't have it (I have probably removed it long time ago) but a friend had it timestamped at 2007 -- damjan
On Fri, Oct 9, 2009 at 12:42 PM, Damjan Georgievski <gdamjan@gmail.com> wrote:
... and back! That was it indeed. Ah, well, how long did I live with that antediluvian udev.rules file? It was dated March 2008 and did not even belong to the udev package... Wonder what ill it caused otherwise. Well. Gone now. Thanks again.
That file is a real mistery, I didn't have it (I have probably removed it long time ago) but a friend had it timestamped at 2007
Unfortunately we can no longer check the cvs repo afaik. We cannot see earlier than April 2008 : http://repos.archlinux.org/viewvc.cgi/udev/trunk/PKGBUILD?view=log I am also curious to know how did that file stay. Why wasn't it tracked and removed by pacman ?
Xavier schrieb:
Unfortunately we can no longer check the cvs repo afaik. We cannot see earlier than April 2008 : http://repos.archlinux.org/viewvc.cgi/udev/trunk/PKGBUILD?view=log
I am also curious to know how did that file stay. Why wasn't it tracked and removed by pacman ?
The old cvs-arch and cvs-core are still around somewhere, but not public.
On Fri, Oct 9, 2009 at 7:20 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Xavier schrieb:
Unfortunately we can no longer check the cvs repo afaik. We cannot see earlier than April 2008 : http://repos.archlinux.org/viewvc.cgi/udev/trunk/PKGBUILD?view=log
I am also curious to know how did that file stay. Why wasn't it tracked and removed by pacman ?
The old cvs-arch and cvs-core are still around somewhere, but not public.
They used to be listed in viewvc. Did we kill that off with the server move?
Aaron Griffin schrieb:
On Fri, Oct 9, 2009 at 7:20 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Xavier schrieb:
Unfortunately we can no longer check the cvs repo afaik. We cannot see earlier than April 2008 : http://repos.archlinux.org/viewvc.cgi/udev/trunk/PKGBUILD?view=log
I am also curious to know how did that file stay. Why wasn't it tracked and removed by pacman ? The old cvs-arch and cvs-core are still around somewhere, but not public.
They used to be listed in viewvc. Did we kill that off with the server move?
Yes, I found it confusing to have so many repositories with different names, there was nothing to uniquely point out that all the CVS stuff was historical. We don't even have CVS installed anymore.
On Fri, Oct 9, 2009 at 5:28 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Yes, I found it confusing to have so many repositories with different names, there was nothing to uniquely point out that all the CVS stuff was historical. We don't even have CVS installed anymore.
I did use the cvs stuff several times when it was still in viewvc. It was for the same reasons than now, just checking the history of a package. But well no big deal, it's usually not that important.
On Fri, Oct 9, 2009 at 2:20 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Xavier schrieb:
Unfortunately we can no longer check the cvs repo afaik. We cannot see earlier than April 2008 : http://repos.archlinux.org/viewvc.cgi/udev/trunk/PKGBUILD?view=log
I am also curious to know how did that file stay. Why wasn't it tracked and removed by pacman ?
The old cvs-arch and cvs-core are still around somewhere, but not public.
So since we still have no information about that /etc/udev/rules.d/udev.rules file, it seems it could potentially be on all old arch systems (2007 or older). Should the kernel post_upgrade either display a warning or just remove that file automatically ? A warning could be safer if a user used this file for custom rules.
Xavier wrote:
On Fri, Oct 9, 2009 at 2:20 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Xavier schrieb:
Unfortunately we can no longer check the cvs repo afaik. We cannot see earlier than April 2008 : http://repos.archlinux.org/viewvc.cgi/udev/trunk/PKGBUILD?view=log
I am also curious to know how did that file stay. Why wasn't it tracked and removed by pacman ? The old cvs-arch and cvs-core are still around somewhere, but not public.
So since we still have no information about that /etc/udev/rules.d/udev.rules file, it seems it could potentially be on all old arch systems (2007 or older). Should the kernel post_upgrade either display a warning or just remove that file automatically ? A warning could be safer if a user used this file for custom rules.
My current Arch Linux was (re)installed last time in 2005 and only updated after that. I don't have /etc/udev/rules.d/udev.rules . I must have removed it manually. I think some time ago there was an announcement or discussion about this on this list, but I'm not sure. Armando
Armando M. Baratti a écrit :
Xavier wrote:
On Fri, Oct 9, 2009 at 2:20 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Unfortunately we can no longer check the cvs repo afaik. We cannot see earlier than April 2008 : http://repos.archlinux.org/viewvc.cgi/udev/trunk/PKGBUILD?view=log
I am also curious to know how did that file stay. Why wasn't it tracked and removed by pacman ? The old cvs-arch and cvs-core are still around somewhere, but not
Xavier schrieb: public.
So since we still have no information about that /etc/udev/rules.d/udev.rules file, it seems it could potentially be on all old arch systems (2007 or older). Should the kernel post_upgrade either display a warning or just remove that file automatically ? A warning could be safer if a user used this file for custom rules.
My current Arch Linux was (re)installed last time in 2005 and only updated after that. I don't have /etc/udev/rules.d/udev.rules . I must have removed it manually.
I think some time ago there was an announcement or discussion about this on this list, but I'm not sure.
It could be that I missed that one, if indeed there was an announcement about it. My system was first (and last) installed in February 2006.
participants (6)
-
Aaron Griffin
-
Armando M. Baratti
-
Damjan Georgievski
-
Firmicus
-
Thomas Bächler
-
Xavier