|
Home > Archive > Debian Developers > February 2004 > udev uploaded to experimental
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
udev uploaded to experimental
|
|
| Marco d'Itri 2004-02-21, 11:33 pm |
| I'm lazy, so I will include my last blog post as a summary.
This goes to debian-glibc and the initscripts maintainer as well because
S35mountkernfs needs to be split in two parts: one which will mount /proc
and /sys, to be run at S03 and one for the rest, which can be left at S35.
This will have the positive side effect of allowing removal from some
other init scripts of the cruft needed to mount and then unmount /proc.
Please followup to the appropriate mailing list.
-----------------------------------------------------------------------------
(#16) udev uploaded to experimental
A new udev package is available at http://www.bofh.it/~md/debian/ and
has been uploaded to experimental (it's currently waiting in NEW).
It's the first version of the package that manages /dev instead of
/udev. It does this by mounting a ramfs over /dev, so there is no risk
of permanently breaking your system. If you are interested in
hotplugging, HAL and similar issues, please test the package! Do not
forget to read README.Debian.
The udev.rules file and the /etc/udev/*.sh scripts need a lot of
improvements in the parts which deal with IDE and SCSI devices. I'm not
looking for perfect devfs compatibility, but I'd like to have something
better than the typical /dev/sd* mess. OTOH, some hard disks are better
managed by devlabel[0].
I also uploaded a new module-init-tools[1] package.
[0] http://packages.debian.org/devlabel
[1] http://packages.debian.org/module-init-tools
Posted at 23:28:46. [http://blog.bofh.it/id_16]
--
ciao, |
Marco | [4704 fomLQu3BuWLeY]
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Miquel van Smoorenburg 2004-02-22, 12:33 am |
| On Sun, 22 Feb 2004 13:43:50, Marco d'Itri wrote:
> I'm lazy, so I will include my last blog post as a summary.
>
> This goes to debian-glibc and the initscripts maintainer as well because
> S35mountkernfs needs to be split in two parts: one which will mount /proc
> and /sys, to be run at S03 and one for the rest, which can be left at S35.
> This will have the positive side effect of allowing removal from some
> other init scripts of the cruft needed to mount and then unmount /proc.
I have been discussing this with the glibc people as well, in particular
with GOTO Masanori. Basically we agreed on something similar. I should
have drafted up a proposal to post to debian-devel some time ago,
but I didn't have time and later forgot about it .. sorry.
Part of that discussion:
Miquel van Smoorenburg wrote:
> Now there are packages that want to look at /proc even before
> /etc/rcS.d/S35mountall.sh. So much, that /etc/rcS.d/S10checkroot
> makes sure it's mounted. And there are even packages that need
> procps even earlier, like bootlogd and keysmaps. They mount /proc
> to peek in and then unmount it again: ugly.
>
> Now a request to mount /sys from the initscripts has also been filed,
> see Bug#225912.
>
> So, if I need to add a script to the initscripts (from sysvinit) package
> to manage proc and sysfs, why not throw devpts into it. It's a similar
> filesystem.
>
> I think it needs to be a 2-stage system. /etc/rcS.d/S02mountkernfs would
> mount all top-level kernel filesystems (there's also non-toplevel, e.g.
> /where/ever/chroot1/proc) but not write /etc/mtab. Then,
> /etc/rcS.d/S35mountall.sh would make sure that those mounts get written
> to /etc/mtab and that the other non-toplevel kernel filesystems get mounted.
>
> If you look at /etc/rc6.d/S31umountnfs.sh you'll see that the unmounting
> of some of those filesystems is already handled by that (admittedly now wrongly
> named) script.
GOTO Masanori wrote:
> I think it's sane that initscripts handles such mount works.
> The rest items I think are:
>
> - glibc package loses devpts.sh/mountkernfs, and initscripts
> gets it. So we need to add Conflicts: initscripts (<<
> oldversion) if we do without consideration. I don't want to
> add such Conflicts. Fortunately, my update to
> /etc/init.d/devpts.sh/mountkernfs is not still packaged to
> the latest glibc sid package, so we only consider to devpts
> (which is currently provided by glibc package). Can you
> provide good script which allows to coexist both devpts.sh
> and your new script?
>
> - Is this integration worth while doing?
>
> - we need to discuss this issue on the public lists
> (debian-devel, debian-glibc)
Mike.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| GOTO Masanori 2004-02-22, 3:33 pm |
| At Sun, 22 Feb 2004 14:32:38 +0100,
Miquel van Smoorenburg wrote:
> On Sun, 22 Feb 2004 13:43:50, Marco d'Itri wrote:
>
> I have been discussing this with the glibc people as well, in particular
> with GOTO Masanori. Basically we agreed on something similar. I should
> have drafted up a proposal to post to debian-devel some time ago,
> but I didn't have time and later forgot about it .. sorry.
Exactly. I fully agreed with the opinion of Miquel and Marco. If
once initscripts supports /proc or /sys handling code,
/etc/init.d/mountkernfs should be gone away from both our HDD and
debian-glibc package.
Regards,
-- gotom
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Marco d'Itri 2004-02-25, 9:37 am |
| On Feb 24, Martin Pitt <martin@piware.de> wrote:
>This is not really your fault since the current nvidia module does not
>create entries in /sys. So this must be done manually. Of course I
>could do that myself, but since it may affect quite a lot of people,
>would it be possible to check for a loaded module 'nvidia' and create
>above devices in the udev package? The only problem with this is that
No way. If the nvidia driver is broken then please fix it.
>Another problem is that plugging in my USB memory stick does not cause
>the creation of a device node in /udev (I changed the path to /udev to
>allow comparing against devfs in /dev), but an appropriate
>/dev/disc1/... is created in /dev (with devfs). I have the hotplug
>package installed and my kernel is hotplug enabled. Do I something
>wrong here?
Probably.
--
ciao, |
Marco | [4746 arOteiNGSnJ1A]
| |
| Tom Badran 2004-02-25, 9:37 am |
| On Wed 25 February 2004 13:04, Marco d'Itri wrote:
> On Feb 24, Martin Pitt <martin@piware.de> wrote:
>
> No way. If the nvidia driver is broken then please fix it.
There is already a patch the the nvidia driver that fixes this, search
for "udev nvidia" on google and its one of the first links.
However, ive seen in mentioned, and i have the same problem that
the /dev/tty* devices are not created, and thus there are no useable
configs. I hacked my syslog.conf to output to /dev/vc/12 which works
for that, but didnt look long enought at the inittab to fix the tty
issue, is this a kernel or udev issue?
Tom
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Tom Badran 2004-02-25, 9:37 am |
| On Wed 25 February 2004 14:15, Tom Badran wrote:
> and thus there are no useable
> configs.
I obvioulsy meant consoles, my brain has melted ;)
Tom
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Marco d'Itri 2004-02-25, 2:33 pm |
| On Feb 25, Tom Badran <tb100@doc.ic.ac.uk> wrote:
>However, ive seen in mentioned, and i have the same problem that
>the /dev/tty* devices are not created, and thus there are no useable
>configs. I hacked my syslog.conf to output to /dev/vc/12 which works
>for that, but didnt look long enought at the inittab to fix the tty
>issue, is this a kernel or udev issue?
Configuration issue, but since the default inittab we ship uses old
style devices, from the next version of the package it will create the
ttyNN aliases by default.
--
ciao, |
Marco | [4747 foquqfeOIzT0E]
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Darren Salt 2004-02-26, 2:33 pm |
| I demand that Isaac Clerencia may or may not have written...
[snip]
> I also have problems with tty's, I can't login in any of them.
Easily fixable, though you'll want to reboot with either a rescue disk/CD or
with init=3D/bin/sh (and remount / rw).
If you want to have devfs-compatible names as well, then you'll need the
following line somewhere in /etc/udev - udev-compat.rules is reasonable, or
you could add a new rules file (don't forget to edit udev.conf):
KERNEL=3D"tty[0-9]*", SYMLINK=3D"%k"
(Good to see that this'll be in the next release.)
Anyway, I'm now running 0.018 (plus trailing-spaces-in-sysfs-files patch) on
my laptop, but I encountered a few problems along the way.
A RAM disk was already present on /dev, but the init script created another
one. The problem was that the init script assumes that the admin has used
"none" as the mount point for a tmpfs on /dev, and of course I'd used
"tmpfs". Checking for "^[^[:space:]]+" instead of "^none" should work.
Then I found that device nodes weren't being given the correct permissions: X
was falling over on login; xinit worked, startx failed, .xsession-errors had
interesting things to say. I'd assumed that the multiple-rules-files patch
also applied to the permissions configuration - no such luck... :-(
I also saw messages of the form "/dev/ttyS? not found" from setserial, so
I've added the following two lines (might as well deal with the parallel port
at the same time):
KERNEL=3D"ttyS[0-9]*", SYMLINK=3D"%k"
KERNEL=3D"lp[0-9]*", SYMLINK=3D"%k"
Any chance that these too will be in the next release? :-)
--=20
| Darren Salt | linux (or ds) at | nr. Ashington,
| woody, sarge, | youmustbejoking | Northumberland
| RISC OS | demon co uk | Toon Army
| <URL:http://www.youmustbejoking.demon.co.uk/> (PGP 2.6, GPG keys)
A poetic Borg: "You will compose assimiliated rhythms and rhymes."
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Thomas Hood 2004-02-28, 10:33 am |
| Miquel van Smoorenburg wrote:
> I think it needs to be a 2-stage system. /etc/rcS.d/S02mountkernfs
> would mount all top-level kernel filesystems (there's also
> non-toplevel, e.g. /where/ever/chroot1/proc) but not write /etc/mtab.
> Then, /etc/rcS.d/S35mountall.sh would make sure that those mounts
> get written to /etc/mtab and that the other non-toplevel kernel
> filesystems get mounted.
In this thread there was no explicit mention of the shm filesystem,
mounted at /dev/shm. If possible I would like to see this mounted
early too.
Miquel van Smoorenburg wrote:[color=darkred]
> Now there are packages that want to look at /proc even before
> /etc/rcS.d/S35mountall.sh. So much, that /etc/rcS.d/S10checkroot
> makes sure it's mounted. And there are even packages that need
> procps even earlier, like bootlogd and keysmaps. They mount /proc
> to peek in and then unmount it again: ugly.
>
> GOTO Masanori wrote:
All these rcS.d scripts (including those listed below) mount-and-
unmount procfs:
S01devfsd
S05initrd-tools.sh
S05keymap.sh
S10checkroot.sh
Those that run after the new kernel filesystem mount script should
be updated to reflect the new way of doing things.
--
Thomas Hood <jdthood@yahoo.co.uk>
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|
|
|
|