On 22.12.2022 11:49, Arkadiusz Miśkiewicz via pld-devel-en wrote:
> udev-core change:
>
> -Requires: uname(release) >= 3.13
> +Requires: uname(release) >= 4.15
>
>
> Is this true requirement?
This R: was updated purely based on very first ent
udev-core change:
-Requires: uname(release) >= 3.13
+Requires: uname(release) >= 4.15
Is this true requirement?
I mean docs say:
"
README: say kernel 4.15 is the minimum recommended
After various long discussions
(https://lists.freedesktop.org/archives/systemd
On 11.09.2016 20:13, Tomasz Pala wrote:
The same applies to bash-completion and zsh-completion subpackages.
"same" does not:
➔ rpm -qf /usr/share/bash-completion /usr/share/zsh/site-functions
bash-completion-2.1-5.noarch
zsh-5.0.2-3.x86_64
--
glen
___
On Sun, Sep 11, 2016 at 15:36:48 +0200, Jan Rękorajski wrote:
> On Sun, 11 Sep 2016, Elan Ruusamäe wrote:
>
>> - drop udev-* addon packages for distro packages
[...]
> Makes sense. Ok with me.
The same applies to bash-completion and zsh-completion subpackages.
On Sun, 11 Sep 2016, Elan Ruusamäe wrote:
> proposition:
>
> - drop udev-* addon packages for distro packages
>
> because:
> ➔ rpm -qf /lib/udev/rules.d/
> filesystem-4.1-1.x86_64
>
> they are harmless if udev is not installed, no extra deps than base
> package
proposition:
- drop udev-* addon packages for distro packages
because:
➔ rpm -qf /lib/udev/rules.d/
filesystem-4.1-1.x86_64
they are harmless if udev is not installed, no extra deps than base
package and the packages are also tiny
and sometimes you lack some behavior and then find out that
On 2016-08-31 09:51, Elan Ruusamäe wrote:
On 31.08.2016 10:47, Jacek Konieczny wrote:
# grep add /etc/udev/rules.d/80-idcard.rules
SUBSYSTEM=="usb", ACTION=="add", ENV{DEVTYPE}=="usb_device",
ENV{ID_MODEL}=="*Smart*Card*Reader*", RUN+="/sbin/service
On 31.08.2016 10:47, Jacek Konieczny wrote:
# grep add /etc/udev/rules.d/80-idcard.rules
SUBSYSTEM=="usb", ACTION=="add", ENV{DEVTYPE}=="usb_device",
ENV{ID_MODEL}=="*Smart*Card*Reader*", RUN+="/sbin/service pcscd start"
What init do you
On 2016-08-31 07:28, Elan Ruusamäe wrote:
i'm trying to write udev rule to start service when usb device is attached
here's what i got. yet it doesn't work
# grep add /etc/udev/rules.d/80-idcard.rules
SUBSYSTEM=="usb", ACTION=="add", ENV{DEVTYPE}=="
hi
i'm trying to write udev rule to start service when usb device is attached
here's what i got. yet it doesn't work
# grep add /etc/udev/rules.d/80-idcard.rules
SUBSYSTEM=="usb", ACTION=="add", ENV{DEVTYPE}=="usb_device",
ENV{ID_MODEL}=="*Sm
On 01.08.2016 11:07, Tomasz Pala wrote:
# service --status-all
S:[+] allowlogin: running
S:[+] console: running
S:[+] cpusets: running
S
iles to /lib/systemd; /usr/lib/systemd is not used on Debian
However we have always followed/supported /usr as a separate filesystem,
so we shouldn't have had /usr/lib/udev in use ever.
So if anyone wants to help, please remove this symlink on your system
and report if anything breaks. If n
onfuses systemd-delta into thinking, that the contents are overriden:
>
>
> [OVERRIDDEN] /usr/lib/udev/rules.d/70-mouse.rules ->
> /lib/udev/rules.d/70-mouse.rules
>
> Files /lib/udev/rules.d/70-mouse.rules and
> /usr/lib/udev/rules.d/70-mouse.rules are identical
>
>
:
[OVERRIDDEN] /usr/lib/udev/rules.d/70-mouse.rules ->
/lib/udev/rules.d/70-mouse.rules
Files /lib/udev/rules.d/70-mouse.rules and /usr/lib/udev/rules.d/70-mouse.rules
are identical
...35 times (reports 49 including 14 really overriden, but there are 49
rules inside).
--
Tomasz P
On 28/03/14 00:03, Kacper Kornet wrote:
# rpm -q dev udev
>dev-3.4-10.x86_64
>udev-208-11.x86_64
And how did you end with both dev and udev installed, as udev obsoletes
dev?
installed "dev" after "udev*" was already installed, intention was to
On Thu, Mar 27, 2014 at 11:08:49PM +0200, Elan Ruusamäe wrote:
> posting here, as maybe someday somebody wants to fix this.
> seems start_udev trigger is invoked when *udev* package is removed,
> and that call seems even to succeed!
> # rpm -q dev udev
> dev-3.4-10.x86_64
>
posting here, as maybe someday somebody wants to fix this.
seems start_udev trigger is invoked when *udev* package is removed, and
that call seems even to succeed!
# rpm -q dev udev
dev-3.4-10.x86_64
udev-208-11.x86_64
# rpm -e udev
* Starting udev
if you upgrade to udev-198 and have not generated initrd with geninitrd
>= 12635 then your /dev/null, /dev/*random are with wrong permission,
which leads to random problems, like can't ssh out as regular user,
desktop environments not starting up, etc
20:14:59 glen> arekm: tha
*** lang=en
Hi,
As you may know udev, as of version 183, has been merged into systemd
and is now built from systemd source tree.
This new version of systemd and udev is now available in th-test.
Due to libudev soname change, udev-libs must be installed with
'just-install' for now
On Sun, 27 May 2012, Jakub Bogusz wrote:
> udev-acl disappeared, there was changelog entry:
>
> - don't obsolete udev-acl as it is provided by systemd and will also be
> provided by ConsoleKit
>
> but it's not provided by ConsoleKit.
> And it's still r
udev-acl disappeared, there was changelog entry:
- don't obsolete udev-acl as it is provided by systemd and will also be
provided by ConsoleKit
but it's not provided by ConsoleKit.
And it's still required by some packages, like gnome-bluetooth.
(BTW, since udev 183 it has b
Dnia piątek, 30 marca 2012, Elan Ruusamäe napisał:
[...]
> no, just take start_udev script and replace it in your system, no need
> to do full udev rebuild
>
> http://cvs.pld-linux.org/packages/udev/start_udev
Seems to be OK, I've observed no errors.
On 30.03.2012 12:16, Łukasz Maśko wrote:
Dnia piątek, 30 marca 2012, Elan Ruusamäe napisał:
[...]
can you test with start_udev from HEAD again? i.e is the initial error
also back?
Do you mean, I should rebuild udev from CVS with -r HEAD and try again? OK,
but later, whem my daughter goes to
Dnia piątek, 30 marca 2012, Elan Ruusamäe napisał:
[...]
> can you test with start_udev from HEAD again? i.e is the initial error
> also back?
Do you mean, I should rebuild udev from CVS with -r HEAD and try again? OK,
but later, whem my daughter goes to sleep, now she will not let me d
ent thread about new install for gory details.
OK. Solved. I had udev_root="/dev/" defined in my udev.conf (from the
ancient times) an that caused this problem. Now it's clean.
And - yes, I have static /dev/{console,null,zero} in my system (even without
udev).
can you test wit
/dev/zero on this filesystem? Normal nodes, directly on
> fs. See recent thread about new install for gory details.
OK. Solved. I had udev_root="/dev/" defined in my udev.conf (from the
ancient times) an that caused this problem. Now it's clean.
And - yes, I have static /
On Thu, 29 Mar 2012, Jan Rękorajski wrote:
> On Thu, 29 Mar 2012, Łukasz Maśko wrote:
>
> > Dnia czwartek, 29 marca 2012, Jan Rękorajski napisał:
> > [...]
> > > The problem was in start_udev script.
> > > udev-182-2 should work again.
> >
> >
On Thu, 29 Mar 2012, Łukasz Maśko wrote:
> Dnia czwartek, 29 marca 2012, Jan Rękorajski napisał:
> [...]
> > The problem was in start_udev script.
> > udev-182-2 should work again.
>
> It is not, kind of error has changed (sorry for picture quality):
> http://yen.ipipa
Dnia czwartek, 29 marca 2012, Jan Rękorajski napisał:
[...]
> The problem was in start_udev script.
> udev-182-2 should work again.
It is not, kind of error has changed (sorry for picture quality):
http://yen.ipipan.waw.pl/~ed/udev_devtmpfs2.jpg
--
Łukasz
[czwartek, 29 marzec 2012], Łukasz Maśko napisał(a):
> Dnia środa, 28 marca 2012, Jan Rękorajski napisał:
> > Hi,
> > This is a heads-up, new udev 182 that is in th-test requires mounted
> > devtmpfs to operate properly as it (udev >= 181) does not create any
> > nod
Dnia środa, 28 marca 2012, Jan Rękorajski napisał:
> Hi,
> This is a heads-up, new udev 182 that is in th-test requires mounted
> devtmpfs to operate properly as it (udev >= 181) does not create any
> nodes anymore. Current rc.sysinit (rc-scripts >= 0.4.5.3-1) do mount
>
Hi,
This is a heads-up, new udev 182 that is in th-test requires mounted devtmpfs to
operate properly as it (udev >= 181) does not create any nodes anymore.
Current rc.sysinit (rc-scripts >= 0.4.5.3-1) do mount devtmpfs,
as does systemd.
--
Jan Rękorajski
t for older kernels?
> >
> > imho it should check if /dev is mounted either tmpfs or devtmpfs then
> > mount nothing
> >
> > if kver >= 2.6.32 mount with devtmpfs, otherwise mount tmpfs
>
> I added this for your happiness, but udev >= 181 _requires_ devtmpfs
n
> mount nothing
>
> if kver >= 2.6.32 mount with devtmpfs, otherwise mount tmpfs
I added this for your happiness, but udev >= 181 _requires_ devtmpfs.
That's why it has still rel 0.1.
You both obviously didn't read the changelogs for
On 03/03/12 08:25, Arkadiusz Miśkiewicz wrote:
On Friday 02 of March 2012, baggins wrote:
> Author: baggins Date: Fri Mar 2 22:42:24 2012 GMT
> Module: packages Tag: HEAD
> Log message:
> - mount devtmpfs not tmpfs over /dev if not already moun
2 only? We drop support for older kernels?
>
> Files affected:
> packages/udev:
>start_udev (1.40 -> 1.41)
>
> Diffs:
>
> ====
> Index: packages/udev/start_udev
> diff -u packages/ud
> Is it possible these days to not have udev packages installed at all?
>From what I know... no. But I may be totally wrong :-)
I had bunch of machines running with static dev. They were fine with
kernel 2.6.27.x, but stopped working properly with kernel 2.6.32.x. One
was unable to init
On Mon, May 3, 2010 at 8:05 PM, Caleb Maclennan wrote:
> Does anybody have any input on keeping a TH system up to date while
> being forced to run an old kernel (2.6.16) not compatible with current
> udev packages?
>
> Is it possible these days to not have udev packages installed
Does anybody have any input on keeping a TH system up to date while
being forced to run an old kernel (2.6.16) not compatible with current
udev packages?
Is it possible these days to not have udev packages installed at all?
Or should I work on setting up a custom udev package with an an older
eems to point
>> to /lib/udev/firmware binary).
>
> There is a typo in configure.ac. See:
>
> http://git.kernel.org/?p=linux/hotplug/udev.git;a=summary
>
> Corrected in udev-153 (please, let someone send it to builders).
Done.
--
Patryk Zawadzki
_
On Wed, Apr 21, 2010 at 11:22:12PM +0200, Patryk Zawadzki wrote:
> The firmware helper is broken and does not load any firmware the
> kernel requests.
> Downgrading to 151 immediately fixes the problem (which seems to point
> to /lib/udev/firmware binary).
There is a typo in confi
The firmware helper is broken and does not load any firmware the
kernel requests.
Downgrading to 151 immediately fixes the problem (which seems to point
to /lib/udev/firmware binary).
--
Patryk Zawadzki
___
pld-devel-en mailing list
pld-devel-en
On Saturday 08 of August 2009, Fryderyk Dziarmagowski wrote:
> On Sat, 08 Aug 2009 13:33:28 +0200
>
> arekm wrote:
> > Author: arekmDate: Sat Aug 8 11:33:28 2009 GMT
> > Module: packages Tag: HEAD
> > ---- Log message:
On Sat, 08 Aug 2009 13:33:28 +0200
arekm wrote:
> Author: arekmDate: Sat Aug 8 11:33:28 2009 GMT
> Module: packages Tag: HEAD
> Log message:
> - use udev for starting stuff
>
> Files affected:
> packages/bluez:
>
On Thursday 12 March 2009 23:10:11 Arkadiusz Miskiewicz wrote:
> On Thursday 12 of March 2009, Elan Ruusamäe wrote:
> > can this be added to HEAD (th) too? as it's quite difficult to open tray
> > to remove disc if it gets closed immediately again.
>
> Was it reported upstream?
no, i did not know
On Thursday 12 of March 2009, Elan Ruusamäe wrote:
> can this be added to HEAD (th) too? as it's quite difficult to open tray to
> remove disc if it gets closed immediately again.
Was it reported upstream?
>
> -- Forwarded Message --
>
> Subject: SPEC
can this be added to HEAD (th) too? as it's quite difficult to open tray to
remove disc if it gets closed immediately again.
-- Forwarded Message --
Subject: SPECS (UDEV-124): udev.spec - added -vol_id-cdrom.patch (for cdrom
tray clo...
Date: Thursday 12 March 2009
On Saturday 25 of October 2008, Mariusz Mazur wrote:
> udev.spec has this inside:
Rule dropped since not needed on Th.
--
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
___
pld-devel-en mailing list
pld
udev.spec has this inside:
# needed on kernels < 2.6.25
cat <$RPM_BUILD_ROOT%{_sysconfdir}/udev/rules.d/05-udev-early.rules
# sysfs is populated after the event is sent
ACTION=="add", SUBSYSTEM=="scsi", WAIT_FOR_SYSFS="ioerr_cnt"
EOF
On kernels >2.6.25 (
On Tue, Mar 11, 2008 at 12:39:56AM +0100, Marcin Krol wrote:
> I've been playing a bit with udev inside initrd. Currently it
> doesn't work at all because after starting 'udevd --daemon'
> /dev is almost empty (just basic entries like null, console,
> etc., no dev
> I'll test it tomorrow. I'll also test initrd with udev and lvm.
I've already commited changes to geninitrd. Now it works properly with
udev inside initrd. Tested with root fs on raid1, lvm2 and lvm2 on top
of raid1.
M.
___
pld-dev
I've been playing a bit with udev inside initrd. Currently it doesn't
work at all because after starting 'udevd --daemon' /dev is almost empty
(just basic entries like null, console, etc., no device nodes). This may
be fixed by using PROBESTATICMODULES=yes in geninitrd (
On Sun 11. of February 2007, Tomasz Wittner wrote:
> Hello,
>
> Nearly every two booting I'm forced to press reset button on my workstation
> (or sometimes is possible Alt+PrintScreen+S/B) - starting hangs during
> hdparm invokation. Because hdparm is called right after start
--- Tomasz Wittner <[EMAIL PROTECTED]> wrote:
> Hello,
>
> Nearly every two booting I'm forced to press reset button on my workstation
> (or sometimes is possible Alt+PrintScreen+S/B) - starting hangs during hdparm
> invokation. Because hdparm is called right after st
Hello,
Nearly every two booting I'm forced to press reset button on my workstation
(or sometimes is possible Alt+PrintScreen+S/B) - starting hangs during hdparm
invokation. Because hdparm is called right after starting udev I suspect that
udev (v. 079) doesn't finish its job and hd
On Tue 26. September 2006 07:37, Fryderyk Dziarmagowski wrote:
> --- shadzik <[EMAIL PROTECTED]> wrote:
>
> > Author: shadzik Date: Mon Sep 25 23:41:15 2006 GMT
> > Module: SPECS Tag: HEAD
> > Log message:
--- shadzik <[EMAIL PROTECTED]> wrote:
> Author: shadzik Date: Mon Sep 25 23:41:15 2006 GMT
> Module: SPECS Tag: HEAD
> Log message:
> - up to udev-100
> - 60-cdrom_id.rules added
Adding it will cause a clash with other
Anyone against such patch?
IMO users should have rw access to CD devices, not only for writing.
F.e. cdaudio or eject requires them as well. Maybe group name is not the
best now, but it doesn't matter that much.
Index: udev.rules
==
Hi,
I've just made some bugfixes to udev from AC-branch.
Please test it and report problems if any.
--
Fryderyk Dziarmagowski
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
On Sat, Mar 04, 2006 at 02:16:57 +0100, Tomasz Pala wrote:
> gnome-vfs2-2.13.91-4 marks hal-fstab-sync-0.5.6-6 (cap storage-methods)
[...]
> I don't have udev and don't use gnome, just need libgnomevfs-2.so.0 to
OK, I see that gnome-vfs2-libs were separated, so one must do
gnome-vfs2-2.13.91-4 marks hal-fstab-sync-0.5.6-6 (cap storage-methods)
hal-fstab-sync-0.5.6-6 marks hal-0.5.6-6 (cap hal = 0.5.6-6)
error: hal-0.5.6-6: req udev >= 1:079-2 not found
I don't have udev and don't use gnome, just need libgnomevfs-2.so.0 to
run some prog
On Tuesday 14 February 2006 01:10, Fryderyk Dziarmagowski wrote:
> I don't see any breakage, sabotage, ... (write your favorite word here)
> in my commits.
look once more initial email.
the script used $UDEVSTARTER which was not initalized and .rpmnew was not
merged, thefore the /sbin/start_udev
--- Jan Rekorajski <[EMAIL PROTECTED]> wrote:
> On Mon, 13 Feb 2006, Fryderyk Dziarmagowski wrote:
>
> > --- Andrzej Krzysztofowicz <[EMAIL PROTECTED]> wrote:
> >
> > > > > grrr
> > > > >
> > > > > udev-079-2.amd6
On Mon, 13 Feb 2006, Fryderyk Dziarmagowski wrote:
> --- Andrzej Krzysztofowicz <[EMAIL PROTECTED]> wrote:
>
> > > > grrr
> > > >
> > > > udev-079-2.amd64
> > > >
> > > > cmon, is adding trigger really so hard?
&
--- Andrzej Krzysztofowicz <[EMAIL PROTECTED]> wrote:
> > > grrr
> > >
> > > udev-079-2.amd64
> > >
> > > cmon, is adding trigger really so hard?
> > [cut]
> >
> > take it easy. if you need a feature implement it. Don
Fryderyk Dziarmagowski wrote:
>
> --- "Elan Ruusamäe" <[EMAIL PROTECTED]> wrote:
>
> > grrr
> >
> > udev-079-2.amd64
> >
> > cmon, is adding trigger really so hard?
> [cut]
>
> take it easy. if you need a feature implemen
--- "Elan Ruusamäe" <[EMAIL PROTECTED]> wrote:
> grrr
>
> udev-079-2.amd64
>
> cmon, is adding trigger really so hard?
[cut]
take it easy. if you need a feature implement it. Don't expect from
people to do something what they don
grrr
udev-079-2.amd64
cmon, is adding trigger really so hard?
hints:
1. missing trigger for $UDEV_STARTER
2. missing default value (fallback) for UDEV_STARTER
outcome:
# sh /sbin/start_udev
* Starting udev...
[ BUSY ]/sbin/start_udev[223
d to the fact that after
> >>>> booting i
> >>>> got on screen message "starting udev" and it stays there forever
> >>>> stopping
> >>>> maching bootup. can't even kill it with SAK.
> >>> Shouldn't but
Jan Rekorajski napisał(a):
> On Thu, 05 Jan 2006, Fryderyk Dziarmagowski wrote:
>
>> --- Jakub Piotr Cłapa <[EMAIL PROTECTED]> wrote:
>>
>>>> is the hotplug issue by any chance related to the fact that after booting
>>>> i
>>>> got
on ro filesystem for whole
> > > > > sysinit phase (no tmpfs)
> > > >
> > > > Was called by kernel.
> > >
> > > And how its possible udev works as a hotplug with this value set to
> > > /sbin/hotplug (without the symlink) on kernel
On Thu, 05 Jan 2006, Fryderyk Dziarmagowski wrote:
> --- Jakub Piotr Cłapa <[EMAIL PROTECTED]> wrote:
>
> > > is the hotplug issue by any chance related to the fact that after booting
> > > i
> > > got on screen message "starting udev" and it s
On Thu, Jan 05, 2006 at 11:30:37AM +0200, Elan Ruusamäe wrote:
> and it does make those nodes, plus some more if MAKEDEV is installed, which i
> didn't have there.
>
> btw it copies /etc/udev/devices also only if makedev installed, but doing cp
> -a can be acomlished with
et
> > > > something here. And why this does not affect hotplug package itself
> > > > where /sbin/hotplug exists and /dev/ is on ro filesystem for whole
> > > > sysinit phase (no tmpfs)
> > >
> > > Was called by kernel.
> >
> > An
On Thu, Jan 05, 2006 at 08:15:21PM +0100, Jakub Piotr Cłapa wrote:
> > the trick was:
> > replacing
> > [ -x /sbin/start_udev ] && run_cmd "Starting udev" /sbin/start_udev
> > with
> > /sbin/start_udev
> > in /etc/rc.d/rc.sysinit
>
&g
Fryderyk Dziarmagowski napisał(a):
> --- Jakub Piotr Cłapa <[EMAIL PROTECTED]> wrote:
>
>>> is the hotplug issue by any chance related to the fact that after booting i
>>> got on screen message "starting udev" and it stays there forever stopping
>>
--- Jakub Piotr Cłapa <[EMAIL PROTECTED]> wrote:
> > is the hotplug issue by any chance related to the fact that after booting i
> > got on screen message "starting udev" and it stays there forever stopping
> > maching bootup. can't even kill it with SAK.
> > where /sbin/hotplug exists and /dev/ is on ro filesystem for whole
> > > sysinit phase (no tmpfs)
> >
> > Was called by kernel.
>
> And how its possible udev works as a hotplug with this value set to
> /sbin/hotplug (without the symlink) on kernels 2.6.12-2
--- "Elan Ruusamäe" <[EMAIL PROTECTED]> wrote:
> > > > > but today this trick didn't work because i couldn't send any input to
> > > > > started shell!!!, i guess this is because my /dev is empty and no
> > > > > udev st
t; > > > started shell!!!, i guess this is because my /dev is empty and no
> > > > udev started.
> > >
> > > Your dev should not be empty (there are at least static /dev/null and
> > > /dev/console from the udev rpm package)
> >
> > it&
On Thursday 05 January 2006 00:18, Elan Ruusamäe wrote:
> On Wednesday 04 January 2006 23:04, Jakub Piotr Cłapa wrote:
> > > but today this trick didn't work because i couldn't send any input to
> > > started shell!!!, i guess this is because my /dev is
On Wednesday 04 January 2006 23:04, Jakub Piotr Cłapa wrote:
> > but today this trick didn't work because i couldn't send any input to
> > started shell!!!, i guess this is because my /dev is empty and no udev
> > started.
>
> Your dev should not be empty (there
efault kernel hotplug handler". Why? This package is
>>> PLD specific and our rc-scripts set this to /sbin/hotplug so for us its
>>> default.
>> Symlink was wrong because was called after / is mounted and before udev
>> was ready to start. That was leading to propag
Elan Ruusamäe napisał(a):
> is the hotplug issue by any chance related to the fact that after booting i
> got on screen message "starting udev" and it stays there forever stopping
> maching bootup. can't even kill it with SAK.
Shouldn't but who knows...
There wa
lesystem for whole
> > sysinit phase (no tmpfs)
>
> Was called by kernel.
And how its possible udev works as a hotplug with this value set to
/sbin/hotplug (without the symlink) on kernels 2.6.12-2.6.14?
> Why should it affects hotplug package? Hotplug is
> not responsible
is the hotplug issue by any chance related to the fact that after booting i
got on screen message "starting udev" and it stays there forever stopping
maching bootup. can't even kill it with SAK.
usually (happened before too), i boot with init=/bin/sh and run 'start_udev&
for now it cant stay this way. What was wrong in this
> > > symlink? Cause i dont really get the "it can't be done this way until
> > > /sbin/hotplug is a default kernel hotplug handler". Why? This package is
> > > PLD specific and our rc-scripts set this t
ve it from
> > rc-scripts) but for now it cant stay this way. What was wrong in this
> > symlink? Cause i dont really get the "it can't be done this way until
> > /sbin/hotplug is a default kernel hotplug handler". Why? This package is
> > PLD specific and our rc-
ay until
> /sbin/hotplug is a default kernel hotplug handler". Why? This package is
> PLD specific and our rc-scripts set this to /sbin/hotplug so for us its
> default.
Symlink was wrong because was called after / is mounted and before udev
was ready to start. That was leading to propaga
havner napisał(a):
> Revision 1.137 2005/11/16 15:35:22 freetz
> - removed hotplug symlink (it can't be done this way until /sbin/hotplug
> is
> a default kernel hotplug handler), added cleaned up hotplug_map.rules
> (instead of creating it with script at build time), rel.1
>
> So how shou
Revision 1.137 2005/11/16 15:35:22 freetz
- removed hotplug symlink (it can't be done this way until /sbin/hotplug
is
a default kernel hotplug handler), added cleaned up hotplug_map.rules
(instead of creating it with script at build time), rel.1
So how should it be done? Cause now we end u
On Fri, Nov 11, 2005 at 05:39:28PM +0200, Elan Ruusamäe wrote:
> ey. in english too please!
k, will try to do this later this evening.
--
.. :: http://www.pomocdladominiki.com.pl/ -- możesz pomóc :: ..
http://www.mysza.eu.org/ | Everybody needs someone sure, someone true,
PLD Linux develo
ey. in english too please!
On Friday 11 November 2005 11:43, dzeus wrote:
> Author: dzeusDate: Fri Nov 11 09:43:05 2005 GMT
> Module: PLD-doc Tag: HEAD
> Log message:
> - udev FAQ from pld-users-pl
>
> Files affected:
&
93 matches
Mail list logo
