I had similar trouble, removing 'watch' didn't change a thing for me
(can't seem to get any of these updates while in jaunty_beta?). I
realize therefore my problem is not related to this bug, still I realize
that more people will find this bug when searching for heir answer
later; let me explain
Is there a reason why there is no new lvm2 package for amd64?
On Mon, Feb 23, 2009 at 11:30 PM, Launchpad Bug Tracker
332...@bugs.launchpad.net wrote:
This bug was fixed in the package lvm2 - 2.02.39-0ubuntu7
---
lvm2 (2.02.39-0ubuntu7) jaunty; urgency=low
*
On Tue, Feb 24, 2009 at 07:34:12PM EST, Francisco Borges wrote:
Is there a reason why there is no new lvm2 package for amd64?
Not that I know of, it built successfully, so should be getting out to
mirrors.
--
udev repeatedly generates change events for the same block device(s)
The Updates appear to work on my laptop
Disk
|-Swap
|-Boot
|-LVM
|-lv-Crypto-Root
|-lv-Crypto-Home
|-lv-Crypto-Other
--
udev repeatedly generates change events for the same block device(s)
https://bugs.launchpad.net/bugs/332270
You received this bug notification because you are a member of
There is no need to confirm that the update works; it just generates
email to everyone subscribed to the bug. Please only comment if the
update does not fix this specific issue for you. Thanks.
--
udev repeatedly generates change events for the same block device(s)
If watch is the problem, what is it supposed to be doing anyway?
--
udev repeatedly generates change events for the same block device(s)
https://bugs.launchpad.net/bugs/332270
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
Having left the problem alone overnight it occurred to me this morning
that maybe the issue here is the *multiple* watches being created by
similar devices (block + lvm, block +md) in the same event run that is
at the heart of this. This would explain why only systems with some
combination of LVM,
TJ if that's the case then this is probably a flaw of the entire block
IO system design.
In my mind, the ideal solution would be to have an abstraction which
eventually reduces to a list of raw devices and block-ranges of action
per device. When a watch or event occurs it would only be within
I have only lvm and md no crypt. For testing i removed mdadm and md
device, so it make no difference. After start udev create four instances
, the first one use 100% CPU. I attach strace of this process.
For other test i removed 85-lvm2.rules on booted system. Now udev
starting normally with
Yeah, Fishor if TJ is correct then what's happening is this.
Udev adds watches on any of these devices which you have...
disk/partition
lvm
crypto
raid
(any other device-mapper things)
Only, unfortunately, two or more of those are the same real device. A
race condition (which would probably be
Only, unfortunately, two or more of those are the same real device. A
race condition (which would probably be aggravated by SMP systems) can
then occur where a potentially infinite loop of self-chaining change
events starts. I would presume that at some point it either overflows
or bogs
Another workaround -might- be possible within grub then.
During menu-selection hit e to edit
arrow over the kernel line
e to edit the line
add (after a space) to the end 'maxcpus=1' and it might boot.
I'll see if I can test that.
--
udev repeatedly generates change events for the same block
Unfortunately that does not seem to work on my test setup.
--
udev repeatedly generates change events for the same block device(s)
https://bugs.launchpad.net/bugs/332270
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs
I'm getting what appears to be this problem on my eee running jaunty
with an encrypted disk. Using the -7 kernel it will boot, using -8 it
won't. If I boot using -7 then restart udev the CPU utilisation reduces
for a while, but then goes back up later on. The volume was created
using the alternate
same problem here. Using raid+cryptsetup+lvm
Could boot kernel 2.6.28-7-server without changing anything. Booting up
needs approximately 5min.
After ~10 hours /dev seems to be full?! Checked it using df :
df
Dateisystem 1K‐Blöcke Benutzt Verfügbar Ben% Eingehängt auf
I have repeating messages like this one at boot (after switching to console),
after Friday's updates:
/sys/devices/virtual/block/dm-0 ($NR)
as noted in a previous comment. $NR is a decreasing number.
I was able to perform an upgrade on Saturday after botting into a
previous kernel recovery
On Mon, 2009-02-23 at 11:32 +, MichaelEvans wrote:
Only, unfortunately, two or more of those are the same real device. A
race condition (which would probably be aggravated by SMP systems) can
then occur where a potentially infinite loop of self-chaining change
events starts. I would
Scott, you have a strongly supported hypothesis, a problem domain of LVM
and -any- of the other watch rulesets.
Looking over every comment in this bug and everyone that mentions system
setup also seems to be running LVM in one way or another.
The topic in #ubuntu+1 should be updated to help
udev 138 introduced new watch option. I just disabled it and every
thing working fine now.
vi /lib/udev/rules.d/60-persistent-storage.rules
comment
#KERNEL!=sr*, OPTIONS+=watch
and probobly in 65-dmsetup.rules too:
#OPTIONS+=watch
--
udev repeatedly generates change events for the same block
** Description changed:
+ SYMPTOMS
+
+ Early in the boot process (during initial ram-disk script processing)
+ the PC appears to stop although there may be a lot of repeated disk
+ activity, possibly accompanied by messages to screen of the form:
+
+ UEVENT[1235217664.944992] change
+
** Also affects: lvm2 (Ubuntu)
Importance: Undecided
Status: New
--
udev repeatedly generates change events for the same block device(s)
https://bugs.launchpad.net/bugs/332270
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
There are two parts to this bug.
The actual bug is being caused by lvm vgscan opening all block devices
on the system writable and then closing them again, which triggers the
inotify event. There seems to be no reason they cannot be opened
readonly, since the only thing it does is call fstat()
** Attachment added: udev patch to add inotify watch after processing RUN
rules
http://launchpadlibrarian.net/23011626/udev.inotify.patch
--
udev repeatedly generates change events for the same block device(s)
https://bugs.launchpad.net/bugs/332270
You received this bug notification because
On Mon, Feb 23, 2009 at 04:45:18PM -, Scott James Remnant wrote:
There are two parts to this bug.
The actual bug is being caused by lvm vgscan opening all block devices
on the system writable and then closing them again, which triggers the
inotify event. There seems to be no reason they
It's also worth trying it without any vgscans at all - it ought to
cope without nowadays provided all commands access VGs by name
i.e. 'vgchange -ay vg1' and never 'vgchange -ay'.
It'll trigger a vgscan internally if it can't find a VG that
was explicitly named.
Alasdair
--
a...@redhat.com
--
On Mon, 2009-02-23 at 17:44 +, Alasdair G. Kergon wrote:
It's also worth trying it without any vgscans at all - it ought to
cope without nowadays provided all commands access VGs by name
i.e. 'vgchange -ay vg1' and never 'vgchange -ay'.
It'll trigger a vgscan internally if it can't find
I have this one too! I have LVM over RAID (mdadm). I will post my
details tomorrow.
--
udev repeatedly generates change events for the same block device(s)
https://bugs.launchpad.net/bugs/332270
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
This bug was fixed in the package udev - 138-2
---
udev (138-2) jaunty; urgency=low
* Fix inotify watch code to remove any existing watch before beginning rule
processing, and not to add the watch until the rule processing is
complete. This stops us chasing our own tail if
Please note that the above upload is a _partial_ fix.
If you have only a single LVM PV, it should fix things for you. After
upgrading, if you've copied the persistent storage rules to
/etc/udev/rules.d, you should remove that file. If you just edited the
file in /lib/udev/rules.d, it will be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Scott James Remnant wrote:
If you have multiple LVM PVs, you will still see the problem; though the
effect should be somewhat lessened.
Is there a fix for this in sight?
- --
Cheers,
Daniel
http://daniel.hahler.de/
-BEGIN PGP SIGNATURE-
This bug was fixed in the package lvm2 - 2.02.39-0ubuntu7
---
lvm2 (2.02.39-0ubuntu7) jaunty; urgency=low
* debian/patches/open-readonly.patch:
- Generally we don't need to write to every single block device we open,
in fact if we do that when scanning we'll make udev
Alasdair: patch for LVM2 attached - this makes functions that only read
from a block device open with O_RDONLY instead of writable-if-they-can.
If another function comes along and needs it writable, dev_open_flags()
already does the right thing and reopens it anyway.
** Attachment added: Patch
The LVM2 upload constitutes the complete fix.
udev no longer receives inotify events for the specific block device
it's processing the rules for (thus guarding against RUN rules causing
them).
LVM no longer opens all block devices for writing when invoked with
vgscan by udev, so no longer
This bug was fixed in the package udev - 138-2
For those who may be wondering why they can't install this fix, it's
because https://edge.launchpad.net/ubuntu/jaunty/+source/udev/138-2
shows that it's still waiting to build on all architectures.
--
udev repeatedly generates change events for
I just built lvm2 and udev from the new sources and indeed, Jaunty boots
again.
Thank you! :-)
--
udev repeatedly generates change events for the same block device(s)
https://bugs.launchpad.net/bugs/332270
You received this bug notification because you are a member of Ubuntu
Bugs, which is
I can confirm that with only the udev update from jaunty, my laptop
with a single lvm-on-dmcrypt pv works again.
--
Martin http://launchpad.net/~mbp/
--
udev repeatedly generates change events for the same block device(s)
https://bugs.launchpad.net/bugs/332270
You received this bug
Can confirm the bug was fixed by installing the package udev-138-2 and
the new lvm2, but somehow leaves bug #325690 The conf/conf.d/cryptroot
isn't created by update-initramfs anymore.
Don't know, if this is also caused by the last udev updates. Also my
other hdds are not mounted - I can't sent
Installation of package udev-138-2 fixed my problems. Thanks a lot.
--
udev repeatedly generates change events for the same block device(s)
https://bugs.launchpad.net/bugs/332270
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
My eee is now booting with the -8 kernel after the latest updates.
Thanks!
--
udev repeatedly generates change events for the same block device(s)
https://bugs.launchpad.net/bugs/332270
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
I've put together the following test system:
two disks, sda and sdb
sda1 + sdb1 are an mdadm RAID-1 mirror, containing an ext3 filesystem
mounted as /boot
sda2 + sdb2 are an mdadm RAID-1 mirror, configured as a dm-crypt device,
containing a swap partition
sda3 + sdb3 are an mdadm RAID-1
I also do have this problem. At the moment I am unable to boot, because
I do not have an alternate kernel.
sda and sdb do two md-devices. md0 is static /boot, while md1 is lvm. On
the lvm there is lv_root, lv_home, lv_swap and lv_data.
I did not find any tricks to interrupt the disc activity.
Reducing Importance.
This bug so far seems to affect a very small number of people, and is
not replicable by installing with a configuration involving a
combination of MD, LVM and encrypted swap. It's therefore likely to be
a problem caused by some people's existing configuration, which may not
But do track for the release
** Changed in: udev (Ubuntu)
Target: None = jaunty-alpha-5
--
udev repeatedly generates change events for the same block device(s)
https://bugs.launchpad.net/bugs/332270
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Scott,
I would respectfully suggest that not even be a configuration our
installer can create is not a helpful condition for downgrading a bug;
the fact remains that a number of users here have Ubuntu systems, with
configurations that in my case have been valid for many years, and now
no longer
@Tj: thx. The sed fix worked for me
--
udev repeatedly generates change events for the same block device(s)
https://bugs.launchpad.net/bugs/332270
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
Peoples can't use their computers... And it's not critical... What's
next?
--
udev repeatedly generates change events for the same block device(s)
https://bugs.launchpad.net/bugs/332270
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
According to https://wiki.ubuntu.com/Bugs/Importance, the definition
of a Critical priority bug is one which “has a severe impact on a large
portion of Ubuntu users”. A High priority bug “has a severe impact on a
small portion of Ubuntu users” or “makes a default Ubuntu installation
generally
(where of course by “priority” I mean “importance”. Silly me.)
http://web.mit.edu/andersk/Public/lp-332270/udev_rules.tar.gz
http://web.mit.edu/andersk/Public/lp-332270/dev.tar.gz
--
udev repeatedly generates change events for the same block device(s)
https://bugs.launchpad.net/bugs/332270
You
I've finally managed to catch the event storm in the act in a log.
First, I built udev 138-1 with --enable-debug. I had to apply a fix to
the udev/Makefile.in and udev/lib/Makefile.in because both were failing
to pass $(DEBUG_CFLAGS) to the compiler and linker.
With the package installed on the
I can also confirm that my system is unbootable until I comment out the
watch line in /lib/udev/rules.d/60-persistent-storage.rules and re-
create the initramfs.
Hardware config:
hda - / /boot /home
sda - LVM
sdb - LVM
sdc - LVM
sdd - blank, unused
I am NOT using any RAID, or encryption.
I have the same problem. My system is booting without the watch Option
now.
My config:
sda1 = /boot
sda2 = crypt-swap
sda3 = crypt-lvm-root
On boot i have seen also a lot of /sys/devices/virtual/block/dm-0 lines.
--
udev repeatedly generates change events for the same block device(s)
Further analysis of event storm log.
The crux of the problem is when the LVM VG partition is detected. A
cascade of duplicate synthesised 'change' events begins. This is where
it starts. This sequence is the first. I've cut-out the intervening log
messages:
run
More analysis. I grep-ed out just the handle_inotify reports. In this
5-minute log there were 777. Analysing them for uniqueness I get:
sort boot-udev-storm-handle_inotify.log | uniq -c
1 [829] handle_inotify: [1385] util_run_program: '/lib/udev/watershed'
(stdout) ' Reading all physical
ctrl-alt-sysrq-E seems to work to get me in to the 2.6.28-8 kernel when
udev is locked in a loop
YMMV
--
udev repeatedly generates change events for the same block device(s)
https://bugs.launchpad.net/bugs/332270
You received this bug notification because you are a member of Ubuntu
Bugs, which
Attached are the requested tar files. I used the modified
60-persistent-storage.rules from comment 49 to be able to boot.
Somehow this feels like I won the lottery today. Only a handful of
systems is affected, but yet, I have two of those
There is a difference though: my laptop (Intel ICH8 /
A me too for this bug. I run root-on-LVM.
--
udev repeatedly generates change events for the same block device(s)
https://bugs.launchpad.net/bugs/332270
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
A maybe-helpful note: disabling the watch options in /etc/udev/rules.d/
(60-persistent-storage.rules, 65-dmsetup.rules) seems to cut boot time
from ~90mins to 40mins. So it seems to at least reduce the impact of
the bug.
I'd experiment more with boot time measurements, but I'm actually using
the
Scott, I have this issue o a fresh install of jaunty from Saturday's
daily alternate amd64 image, so I don't think its a user configuration
issue, since I have not touched any udev rules.
One thing I did do to get my desktop booting at a normal speed, was to
remove calls to the udevadm settle
** Attachment added: /sys/block
http://launchpadlibrarian.net/22992005/sysblock.log
--
udev repeatedly generates change events for the same block device(s)
https://bugs.launchpad.net/bugs/332270
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
** Attachment added: lvm vgs
http://launchpadlibrarian.net/22992007/lvm-vgs.log
--
udev repeatedly generates change events for the same block device(s)
https://bugs.launchpad.net/bugs/332270
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
** Attachment added: lvm pvs
http://launchpadlibrarian.net/22992009/lvm-pvs.log
--
udev repeatedly generates change events for the same block device(s)
https://bugs.launchpad.net/bugs/332270
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
I confirm that I'm also seeing this problem here on a system with
root+swap on crypt LVM as set up using the Ubuntu alternate 8.10
installer; so it's definitely a configuration that our installer can
create. 'high' is fine for urgency, regardless.
--
udev repeatedly generates change events for
I have two machines with this issue, both using LVM2 plus 3ware raid
card. One of the machines don't have any alternative way to boot then I
install a fresh jaunty to another hard disk from my internal mirror
using usb netboot, initially I can boot into the new jaunty because I
forgot to enable
I'm also seeing this in what was originally 333073. This machine's
configuration was made by fairly straightforward use of gutsy (iirc)
installer options, nothing too exotic.
--
udev repeatedly generates change events for the same block device(s)
https://bugs.launchpad.net/bugs/332270
You
64 matches
Mail list logo
