notfound 622309 168-1
notfound 622309 168-2
thanks
You are right, I'm sorry.
It looks more like #624469 now. I will present my findings there.
Am Mittwoch, 11. Mai 2011 schrieb Marco d'Itri:
So it obviously cannot be the same bug.
--
To UNSUBSCRIBE, email to
This bug still exists in the latest unstable version of udev on my
system.
At boot time, it gives the following output (transcribed from a photo
taken with my cellphone camera):
Starting the hotplug events dispatcher: udevdudevd[435]: error:
directory '/run/udev/ not writable, for now falling
On May 12, Rens Houben sha...@systemec.nl wrote:
This bug still exists in the latest unstable version of udev on my
system.
No, it does not. This is about #624469:
udevd[435]: bind failed: Address already in use
error binding udev control socket
udevd[435]: error binding control socket
found 622309 168-1
found 622309 168-2
thanks
I have the same problem again with both versions 168-1 and 168-2. And I double
checked there is no /run. There must be yet another trigger.
Downgrading to 167-3 from snapshot ensures a working computer again.
Regards, Matthias
--
To UNSUBSCRIBE,
On May 11, Matthias Dellweg 2...@gmx.de wrote:
I have the same problem again with both versions 168-1 and 168-2. And I
double
checked there is no /run.
So it obviously cannot be the same bug.
There must be yet another trigger.
Then find out what it is.
--
ciao,
Marco
signature.asc
I have installed the 168-1 and it broke my X input.
I did not have /run directory but it was still broken.
I have downgrade to 161-1 following babilen i cthuluh guides this packages:
libgudev-1.0-0_161-1_amd64.deb libudev0_161-1_amd64.deb udev_161-1_amd64.deb
And that fixed the problem for
On Tue, Apr 19, 2011 at 03:37:50PM +0200, Marco d'Itri wrote:
On Apr 19, rleigh rle...@codelibre.net wrote:
(eth0 is configured here after changing the config to force it to use
dhcp). Since the interface is already up, maybe that's the reason
the events aren't generated. So I guess the
On Tue, Apr 19, 2011 at 03:37:50PM +0200, Marco d'Itri wrote:
On Apr 19, rleigh rle...@codelibre.net wrote:
(eth0 is configured here after changing the config to force it to use
dhcp). Since the interface is already up, maybe that's the reason
the events aren't generated. So I guess the
On Apr 18, Marco d'Itri m...@linux.it wrote:
As a result, I am still unconvinced that the udev logic is correct.
You can test your theory by rebuilding udev without the use_run_tmpfs
patch, I cannot reproduce your problem and apparently nobody else can.
Are there any news?
The current status
On Tue, Apr 19, 2011 at 12:48:06PM +0200, Marco d'Itri wrote:
On Apr 18, Marco d'Itri m...@linux.it wrote:
As a result, I am still unconvinced that the udev logic is correct.
You can test your theory by rebuilding udev without the use_run_tmpfs
patch, I cannot reproduce your problem and
On Tue, Apr 19, 2011 at 01:53:19PM +0100, Roger Leigh wrote:
On Tue, Apr 19, 2011 at 12:48:06PM +0200, Marco d'Itri wrote:
On Apr 18, Marco d'Itri m...@linux.it wrote:
As a result, I am still unconvinced that the udev logic is correct.
You can test your theory by rebuilding udev
On Apr 19, rleigh rle...@codelibre.net wrote:
(eth0 is configured here after changing the config to force it to use
dhcp). Since the interface is already up, maybe that's the reason
the events aren't generated. So I guess the question now is, what's
bringing up the interface before ifupdown
On Sun, Apr 17, 2011 at 08:50:23PM +0200, Marco d'Itri wrote:
On Apr 16, rleigh rle...@codelibre.net wrote:
Maybe your initramfs was not rebuilt to include the code which
mounts /run?
Why would that be required? /run is mounted by mountkernfs,
before udevd is started.
On Apr 18, rleigh rle...@codelibre.net wrote:
(In the case of /dev/shm, we can make this happen at the point /run/shm
is mounted unlike for the other filesystems; it looks like for
dependency-based boot, this might be required. But on my system, this
is /not/ the cause of the networking
On Sun, Apr 17, 2011 at 01:37:27AM +0200, Marco d'Itri wrote:
On Apr 16, rleigh rle...@codelibre.net wrote:
Whether or not /run is a tmpfs or not is *irrelevant* to whether or
not udev should use it. The choice of filesystem is entirely up to
the admin, and while the default is to use
On Apr 17, rleigh rle...@codelibre.net wrote:
The tradeoff here is that if /run is present, udev is broken. That
It is not supposed to, and so far you are the only one who reported this.
Are you sure that you do not have a /run/udev on the underlying root
filesystem?
But you can not use /run
On Sun, Apr 17, 2011 at 01:16:49PM +0200, Marco d'Itri wrote:
On Apr 17, rleigh rle...@codelibre.net wrote:
The tradeoff here is that if /run is present, udev is broken. That
It is not supposed to, and so far you are the only one who reported this.
Are you sure that you do not have a
On Apr 16, rleigh rle...@codelibre.net wrote:
Maybe your initramfs was not rebuilt to include the code which
mounts /run?
Why would that be required? /run is mounted by mountkernfs,
before udevd is started.
Because if /run in the initramfs does not exist or is not a tmpfs then
On Tue, Apr 12, 2011 at 11:06:46AM +0200, Marco d'Itri wrote:
On Apr 12, Krzysztof Krzyżaniak e...@wikia-inc.com wrote:
- after boot there is /run folder, it's regular filesystem not tmpfs.
Then rm -rf /run/udev/ and everything will work fine, this behaviour is
expected.
This is resulting
On Apr 16, rleigh rle...@codelibre.net wrote:
Not sure why udev is broken; it's using both locations from the
look of things. Maybe something it needs has been written to
one and it's not present in the other or something?
rm -rf /run/udev/ ffs!
It will not be created again by -2 unless /run
On Sat, Apr 16, 2011 at 02:34:02PM +0200, Marco d'Itri wrote:
On Apr 16, rleigh rle...@codelibre.net wrote:
Not sure why udev is broken; it's using both locations from the
look of things. Maybe something it needs has been written to
one and it's not present in the other or something?
rm
On Apr 16, rleigh rle...@codelibre.net wrote:
Not sure why udev is broken; it's using both locations from the
look of things. Maybe something it needs has been written to
Maybe your initramfs was not rebuilt to include the code which
mounts /run?
Either way, please fix udev to work with the
On Sat, Apr 16, 2011 at 03:15:33PM +0200, Marco d'Itri wrote:
On Apr 16, rleigh rle...@codelibre.net wrote:
Not sure why udev is broken; it's using both locations from the
look of things. Maybe something it needs has been written to
Maybe your initramfs was not rebuilt to include the code
On Apr 16, rleigh rle...@codelibre.net wrote:
Maybe your initramfs was not rebuilt to include the code which
mounts /run?
Why would that be required? /run is mounted by mountkernfs,
before udevd is started.
Because if /run in the initramfs does not exist or is not a tmpfs then
/dev/.udev/
On Sat, Apr 16, 2011 at 06:01:20PM +0200, Marco d'Itri wrote:
On Apr 16, rleigh rle...@codelibre.net wrote:
Maybe your initramfs was not rebuilt to include the code which
mounts /run?
Why would that be required? /run is mounted by mountkernfs,
before udevd is started.
Because if
On Apr 16, rleigh rle...@codelibre.net wrote:
Whether or not /run is a tmpfs or not is *irrelevant* to whether or
not udev should use it. The choice of filesystem is entirely up to
the admin, and while the default is to use tmpfs, it is not udev's
business to alter its behaviour depending on
On Tuesday, 12 April 2011 at 4:45, Marco d'Itri wrote:
It makes a difference if you have a /run directory.
Do you have one *now*? If you do, rm -rf /run/udev/ and reboot.
Removing /run completely helped. I'm not sure why it was there, but since just
by existing it breaks udev, maybe whatever
I can confirm bug and can give you more details if you tell me how to do
this. So far:
- ii udev 167-2 /dev/ and hotplug management daemon
- after reboot on first phase of boot there is information that
/etc/init.d/udev can't write into /run/
- after boot there is /run folder, it's
On Apr 12, Krzysztof Krzyżaniak e...@wikia-inc.com wrote:
- after boot there is /run folder, it's regular filesystem not tmpfs.
Then rm -rf /run/udev/ and everything will work fine, this behaviour is
expected.
--
ciao,
Marco
signature.asc
Description: Digital signature
On 12.04.2011 11:06, Marco d'Itri wrote:
On Apr 12, Krzysztof Krzyżaniake...@wikia-inc.com wrote:
- after boot there is /run folder, it's regular filesystem not tmpfs.
Then rm -rf /run/udev/ and everything will work fine, this behaviour is
expected.
confirmed.
eloy
--
To UNSUBSCRIBE,
Package: udev
Version: 166-1
Severity: critical
Justification: breaks unrelated software
Hello,
after updating my system to udev 167-2 and rebooting, things stopped working.
Sound and network were completely dead, X input (ps2 keyboard and usb mouse)
was dead until I dis- and reconnected the
On Apr 12, Christian Ohm chr@gmx.net wrote:
Possibly this is the same problem as in #621036, except that is marked as
being
fixed in 167-2, which didn't work here.
Then looks like you will have to find out why, because so far it is
working for everybody else.
Do you have a run? Is it a
On Tuesday, 12 April 2011 at 4:07, Marco d'Itri wrote:
Then looks like you will have to find out why, because so far it is
working for everybody else.
Do you have a run? Is it a tmpfs? Does it contain anything?
I have to admit that I am not very keen on experimenting much with my main
system
On Apr 12, Christian Ohm chr@gmx.net wrote:
I have to admit that I am not very keen on experimenting much with my main
system (and my second one is not working atm). Do you have anything specific
to
look for?
And I have to admit that I have no time to waste with reticent bug
reporters.
On Tuesday, 12 April 2011 at 4:45, Marco d'Itri wrote:
There was a /run on the harddisk after running 167-2, which had iirc five
subdirectories. Reading the other bugreport I deleted it though. In case it
makes a difference, I updated from 166-1 to 167-1 and without rebooting to
167-2.
35 matches
Mail list logo
