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.
--
Tomasz
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
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 y
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}=="usb_device"
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}=="*Smart*Card*Reader
On 01.08.2016 11:07, Tomasz Pala wrote:
# service --status-all
S:[+] allowlogin: running
S:[+] console: running
S:[+] cpusets: running
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 nothin
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 Pala <go.
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
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
udev-208-11.x86_64
And how
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
use static /dev
--
glen
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: that /dev/null
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 been merged
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 required by some packages, like gnome-bluetooth
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 do
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
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.
--
Łukasz Maśko
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
devtmpfs,
as does systemd.
So
[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
nodes anymore. Current rc.sysinit (rc
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 Maśko
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.ipipan.waw.pl/~ed/udev_devtmpfs2.jpg
I
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.
It is not, kind of error has changed (sorry for picture quality
/ 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).
--
Łukasz Maśko_o)
Lukasz.Masko(at)ipipan.waw.pl
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 with start_udev from HEAD again? i.e is the initial error
also back?
--
glen
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 | PLD
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 mounted
happiness, but udev = 181 _requires_ devtmpfs.
That's why it has still rel 0.1.
You both obviously didn't read the changelogs for udev, udev.spec and
rc-scripts.
--
Jan Rękorajski | PLD/Linux
SysAdm | http://www.pld-linux.org
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 udev, udev.spec and
rc-scripts.
Actually all that talk doesn't matter as our udev requires 2.6.32
for older kernels?
Files affected:
packages/udev:
start_udev (1.40 - 1.41)
Diffs:
Index: packages/udev/start_udev
diff -u packages/udev/start_udev:1.40 packages/udev/start_udev:1.41
--- packages/udev
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 initialize
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 configure.ac. See:
http
On Sat, 08 Aug 2009 13:33:28 +0200
arekm ar...@pld-linux.org 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:
bluez.init
On Saturday 08 of August 2009, Fryderyk Dziarmagowski wrote:
On Sat, 08 Aug 2009 13:33:28 +0200
arekm ar...@pld-linux.org wrote:
Author: arekmDate: Sat Aug 8 11:33:28 2009 GMT
Module: packages Tag: HEAD
Log message:
- use udev
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
From
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: SPECS (UDEV-124): udev.spec - added
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 what
udev.spec has this inside:
# needed on kernels 2.6.25
cat EOF $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 (tested; dunno about 2.6.25 itself) this line
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
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-devel-en mailing list
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 device nodes). This may be fixed by using
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 (just commited
small
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 starting udev I
suspect
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:
- up to udev-100
- 60-cdrom_id.rules added
--- 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 rules and break
nodes permissions
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
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 programs; I don't believe
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
--- 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't need.
--
Fryderyk Dziarmagowski
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 implement it. Don't expect from
people to do something what they don't need.
glen is right
--- 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't expect from
people to do something what they don't need.
glen is right. Breakage
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?
[cut]
take it easy. if you need a feature implement it. Don't expect from
people to do
--- Jan Rekorajski [EMAIL PROTECTED] wrote:
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?
[cut]
take it easy. if you need
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 empty and no udev
started.
Your dev should
--- 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 started.
Your dev should not be empty (there are at least static /dev/null 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.6.14?
It is possible because start_udev will be called from init scripts.
--
Fryderyk
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
maching bootup. can't even kill it with SAK.
Shouldn't
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
And what's the real difference between this two?
run_cmd creates a pipe
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 should it
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 propagating device nodes on
readonly filesystem.
I can't speak about rc-srcipts. I don't know why (cruft?) it is set
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 propagating device nodes on
readonly filesystem.
Was called by what? Existance of a file means
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'
once from commandline
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 propagating device nodes
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 are at least static /dev/null and
/dev
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
71 matches
Mail list logo
