[Bug 1347776]
(In reply to comment #1) Note that, due to a firmware change, the m400 rule should use gpio_keys instead of gpio-keys. Here is the new rule: SUBSYSTEM==input, KERNEL==event*, SUBSYSTEMS==platform, KERNELS==gpio_keys.6, PROGRAM=/bin/grep '^HP ProLiant m400 Server Cartridge$' /proc/device-tree/model, TAG+=power-switch That's a neat hack, but in no way upstreamable. Upstream udev dev will not read the device information from /proc, and will also not call any external tools like grep. This all needs to be solved properly on the kernel side, to export real devices and allow efficient and reliable matching from userspace tools. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1347776 Title: shutdown trigger on gpio_keys.X for armhf hardware To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1347776/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1354306]
(In reply to comment #1) Note that, due to a firmware change, the m400 rule should use gpio_keys instead of gpio-keys. Here is the new rule: SUBSYSTEM==input, KERNEL==event*, SUBSYSTEMS==platform, KERNELS==gpio_keys.6, PROGRAM=/bin/grep '^HP ProLiant m400 Server Cartridge$' /proc/device-tree/model, TAG+=power-switch That's a neat hack, but in no way upstreamable. Upstream udev dev will not read the device information from /proc, and will also not call any external tools like grep. This all needs to be solved properly on the kernel side, to export real devices and allow efficient and reliable matching from userspace tools. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1354306 Title: gpio shutdown trigger for ProLiant m400 cartridges To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1354306/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 396957] Re: udevd segfault after worker did not accept message and worker unexpectedly returned with 0
Does it work fine otherwise, and you just get the message? Or does it still fail? -- udevd segfault after worker did not accept message and worker unexpectedly returned with 0 https://bugs.launchpad.net/bugs/396957 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 396957] Re: udevd segfault after worker did not accept message and worker unexpectedly returned with 0
Great. Thanks for the tests. I'll fix the warning, as status 0x suggests, it isn't an unexpected failure. -- udevd segfault after worker did not accept message and worker unexpectedly returned with 0 https://bugs.launchpad.net/bugs/396957 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 396957] Re: udevd segfault after worker did not accept message and worker unexpectedly returned with 0
Hopefully all fixed now: http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=bc113de9a4dc1229f7533acd41310a56d60fbe7e Thanks again. -- udevd segfault after worker did not accept message and worker unexpectedly returned with 0 https://bugs.launchpad.net/bugs/396957 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 396957] Re: udevd segfault after worker did not accept message and worker unexpectedly returned with 0
Care to try this on top? http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=adda4c682ad2c56fc091222be3bd94fa817013b9 If that works for you, I'll put out a new release to fix this issue. Thanks! -- udevd segfault after worker did not accept message and worker unexpectedly returned with 0 https://bugs.launchpad.net/bugs/396957 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 396957] Re: udevd segfault after worker did not accept message and worker unexpectedly returned with 0
I think I've found it. It likely happens only on new installations because udev writes out the network config rule, which triggers a reload of the rules. This needs to kill all old worker processes to get the new config active. There's a bug how the config-reload is handled while the workers are busy. I'll fix that tomorrow. Thanks for the data, it was really helpful to find that. -- udevd segfault after worker did not accept message and worker unexpectedly returned with 0 https://bugs.launchpad.net/bugs/396957 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 396957] Re: udevd segfault after worker did not accept message and worker unexpectedly returned with 0
The list corruption I think I've found, and the fix is simple. Seems, udev tried to handle the event associated with the worker twice, if it killed the worker itself. The interesting question is why a worker will not accept messages. We will get there when the wrong kill handling is fixed. :) Thanks for the debugging! -- udevd segfault after worker did not accept message and worker unexpectedly returned with 0 https://bugs.launchpad.net/bugs/396957 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 396957] Re: udevd segfault after worker did not accept message and worker unexpectedly returned with 0
The settle will time out? And you can log in? Does udevadm settle on the running system work? It seems to work all fine here. -- udevd segfault after worker did not accept message and worker unexpectedly returned with 0 https://bugs.launchpad.net/bugs/396957 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 396957] Re: udevd segfault after worker did not accept message and worker unexpectedly returned with 0
Any chance to strace a udevadm settle call? It sounds strange, that the daemon is receiving the message but does not send the signal back. During installation, is there anything that might kill udev processes? Like with a package installation/update script? -- udevd segfault after worker did not accept message and worker unexpectedly returned with 0 https://bugs.launchpad.net/bugs/396957 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 369817] Re: udev rules for raw1394 video1394 not working
Added the missing '-' to the 1394 rules. Right, the raw stuff is for block devices, not for firewire. Btw, isn't the old ieee1394 stack fully replaced by the firewire drivers? -- udev rules for raw1394 video1394 not working https://bugs.launchpad.net/bugs/369817 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 369817] Re: udev rules for raw1394 video1394 not working
I suppose the rule: KERNEL==raw1394, GROUP=disk I think, that has been removed for security reasons, because you could loopback the cable and the video user could get access the random hardware through the firewire interface. -- udev rules for raw1394 video1394 not working https://bugs.launchpad.net/bugs/369817 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 368109] Re: rfcomm nodes should be created with dialout group
Applied to upstream git. -- rfcomm nodes should be created with dialout group https://bugs.launchpad.net/bugs/368109 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 356631] Re: CD-ROM tray closes automatically after eject due to random session/track count
On Thu, Apr 23, 2009 at 09:35, Martin Pitt martin.p...@ubuntu.com wrote: Kay Sievers [2009-04-23 0:16 +0200]: Hmm, so we need to find a more reliable way to check for a media. We probably need to ask the kernel with some cdrom ioctl() instead of just talking SG_IO here. Indeed I was wondering about that; do you plan to use the CDROM_DISC_STATUS ioctl? I found that quite reliable, and it would keep the fiddly bits in one place in the kernel. Ok, let's try: http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=d6f0b22d574c6a5e5f3430be3fc619d4b2f46cd5 to check the DRIVE, if we should look for a media at all. If that's still not enough, we will need to try the DISC ioctl. Thanks a lot, Kay -- CD-ROM tray closes automatically after eject https://bugs.launchpad.net/bugs/356631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 356631] Re: CD-ROM tray closes automatically after eject due to random session/track count
On Wed, Apr 22, 2009 at 15:34, Martin Pitt martin.p...@ubuntu.com wrote: We changed it yesterday to use an ID_CDROM_MEDIA key: http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=f907449eee3f58fafafee0658e80578b1dbb2722 Would be good to know, if that works in the case you see the wrong values. I got a reply from two testers, unfortunately it doesn't see to help at all. With the patch, he gets this on eject: UDEV [1240402978.959576] change /devices/pci:00/:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr1 (block) ACTION=change SUBSYSTEM=block DEVTYPE=disk ID_CDROM=1 ID_CDROM_DVD=1 ID_CDROM_MEDIA=1 Hmm, so we need to find a more reliable way to check for a media. We probably need to ask the kernel with some cdrom ioctl() instead of just talking SG_IO here. In the hope, the ioctls do more checks, to support broken hardware like this. Kay -- CD-ROM tray closes automatically after eject https://bugs.launchpad.net/bugs/356631 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 356631] Re: CD-ROM tray closes automatically after eject due to random session/track count
On Tue, Apr 21, 2009 at 09:25, Martin Pitt martin.p...@ubuntu.com wrote:
However, this rule (and the corresponding code in cdrom_id [1]) relies
on the track/session counts being zero if there is no CD in the drive.
However, at least with kernel 2.6.28.8 the affected people get
something like
ID_CDROM_MEDIA_STATE=blank
ID_CDROM_MEDIA_SESSION_NEXT=2894
ID_CDROM_MEDIA_SESSION_COUNT=19194
ID_CDROM_MEDIA_TRACK_COUNT=47323
In other words, if ID_CDROM_MEDIA_STATE=blank, the session/track
counts are not reliable.
Nice hardware! :)
Arguably this could/should be fixed in the kernel, to fix these values
to 0 if there is no CD in the drive, or it is blank. However, I
wondered if the udev rules should be more robust in that regard, and
not even ask for the number of tracks if there is no/empty CD.
Affected people verified that adding this rule before the one from
above makes things work:
KERNEL==sr*, ENV{ID_CDROM_MEDIA_STATE}==blank,
GOTO=persistent_storage_end
The problem is that there are other devices which report a blank media
for non-blank ones, so this rule would break these.
We changed it yesterday to use an ID_CDROM_MEDIA key:
http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=f907449eee3f58fafafee0658e80578b1dbb2722
Would be good to know, if that works in the case you see the wrong
values.
Thanks,
Kay
--
CD-ROM tray closes automatically after eject
https://bugs.launchpad.net/bugs/356631
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 362315] Re: udev fails to identify crypt_LUKS swap partition by uuid
Sorry, nothing to prove here. You totally miss the point. Fix your broken metadata. -- udev fails to identify crypt_LUKS swap partition by uuid https://bugs.launchpad.net/bugs/362315 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 362315] Re: udev fails to identify crypt_LUKS swap partition by uuid
There is not much to add to the explanation. Volume autodetection has to refuse to return any results for conflicting signatures. It will get even more picky in the future, we expect. There is no way to resolve such conflicts automatically. We would risk serious data loss. Be happy, that the system did not recognize one of your data partitions as swap and corrupted it. It could be discussed, if a tool other than the scary dd should be provided to resolve such problems, but that is outside the scope of this bug. Thanks, Kay -- udev fails to identify crypt_LUKS swap partition by uuid https://bugs.launchpad.net/bugs/362315 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 337015] Re: vol_id uuid detection regression
Sure, any time. No problem, just let me know. -- vol_id uuid detection regression https://bugs.launchpad.net/bugs/337015 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 337015] Re: vol_id uuid detection regression
Hope this fixes it: http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=1597517c9effc275b8b89c8722c808777c17173f Thanks! -- vol_id uuid detection regression https://bugs.launchpad.net/bugs/337015 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 317430] Re: udev missing rule to get group video on /dev/dri/card0
Fixed in the upstream udev tree. Thanks! -- udev missing rule to get group video on /dev/dri/card0 https://bugs.launchpad.net/bugs/317430 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 289465] Re: initramfs can't find dmraid device (VIA VT6421)
Applied to upstream udev. Thanks! -- initramfs can't find dmraid device (VIA VT6421) https://bugs.launchpad.net/bugs/289465 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 298835] Re: wacom intuos 2 not recognized as mouse (udev)
On Thu, Nov 20, 2008 at 14:25, Scott James Remnant [EMAIL PROTECTED] wrote: Is there a useful way to match the MODALIAS of the wacom device? The modalias match looks crazy. :) The logic behind it should be: joystick == (ABS_X || ABS_WHEEL || ABS_THROTTLE) !BTN_TOUCH Maybe we can switch to the capabilities values, which might look a bit more maintainable. Can we get the output of: grep . /sys/class/input/*/capabilities/* ? -- wacom intuos 2 not recognized as mouse (udev) https://bugs.launchpad.net/bugs/298835 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 298835] Re: wacom intuos 2 not recognized as mouse (udev)
On Wed, Nov 19, 2008 at 15:30, Scott James Remnant [EMAIL PROTECTED] wrote: Kay: suggested change to the persistent input rules There is no actual patch or suggested change attached to the bug, right? -- wacom intuos 2 not recognized as mouse (udev) https://bugs.launchpad.net/bugs/298835 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 255903] Re: DEVTYPE is not being set for disk/partition devices.
It is in the environment, but not stored in the udev database if supplied by the kernel. Currently no value supplied by the kernel will be stored, because it is available when reading the uevent file. What do you need it for? -- DEVTYPE is not being set for disk/partition devices. https://bugs.launchpad.net/bugs/255903 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 255903] Re: DEVTYPE is not being set for disk/partition devices.
What I mean is, we could make udevadm info import the keys from the uevent file, if that helps. -- DEVTYPE is not being set for disk/partition devices. https://bugs.launchpad.net/bugs/255903 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 255903] Re: DEVTYPE is not being set for disk/partition devices.
Right, HAL does not depend on this value. DEVNAME was added later as the HAL logic. I'll go add code to libudev to import the uevent file when we read the udev database. Libudev will be the base for udevadm info soon, so this should be fine in the future. Thanks! -- DEVTYPE is not being set for disk/partition devices. https://bugs.launchpad.net/bugs/255903 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 192794] Re: vol_id not run for entire-disk device breaks LVM across entire disk
On Fri, 2008-04-11 at 09:23 +, Scott James Remnant wrote: Kay: you only get stale db entries and symlinks if the entire-disk changes? Does that happen often? Assumedly the db entries and symlinks get removed if the disk is removed? Yes, every time you change the media, the disk changes and no data will be updated. Try any USB card reader, or cdrom drive, for the simplest devices with this behavior. Kay -- vol_id not run for entire-disk device breaks LVM across entire disk https://bugs.launchpad.net/bugs/192794 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 192794] Re: [gutsy|hardy alpha4] `/etc/init.d/lvm2' missing
On Thu, 2008-04-10 at 15:33 +, Scott James Remnant wrote:
Kay, the addition of ENV{DEVTYPE}==partition before calling vol_id in
persistent-storage.rules breaks LVM when the LVM PV is made across the
entire disk.
What was the rationale for adding that?
Removable media devices will never update the data/links/db if the media
is changed, even when the device is polled, as we never see events again
for the disk device. We can not do that for disks today, only for
partitions.
It will be partly fixed by new change events we added to the kernel
recently, but it's work-in-progress and still a lot of work to do.
2.5.25 will have scsi_device events for sr*/sd* devices, so we can
enable non-formatted disk probing for the most commonly used stuff soon.
Kay
--
vol_id not run for entire-disk device breaks LVM across entire disk
https://bugs.launchpad.net/bugs/192794
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 192794] Re: vol_id not run for entire-disk device breaks LVM across entire disk
On Thu, 2008-04-10 at 23:59 +, Scott James Remnant wrote: So what's the ENV check actually guarding against, if there are no events in the first place? There are add events at creation/hotplug/coldplug time, which would result in stale db entries/symlinks which would never be updated again, on possible media changes. So, we will get there, but not with the currently released kernel. Kay -- vol_id not run for entire-disk device breaks LVM across entire disk https://bugs.launchpad.net/bugs/192794 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 192794] Re: vol_id not run for entire-disk device breaks LVM across entire disk
On Fri, 2008-04-11 at 00:16 +, Brendan Dahl wrote:
Another idea while the kernel change events are still being worked out; what
about this line being added below the partition rule in
65-persistent-storage.rules:
ENV{DEVTYPE}==disk, ATTR{removable}==0, IMPORT{program}=vol_id --export
$tempnode
this only exports disk vol_id if it isn't not a removable disk, hack I
know but might work until changes are finished to the kernel event
thing?
This could work fine in the most common cases, yeah.
After 2.6.25 is released, we will update udev to use the new change
events and always read all volumes. So, in the near future that should
all work.
Kay
--
vol_id not run for entire-disk device breaks LVM across entire disk
https://bugs.launchpad.net/bugs/192794
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 156184] Re: vol_id takes way too long to finish on unavailable SCSI devices
Made a 118 release. -- vol_id takes way too long to finish on unavailable SCSI devices https://bugs.launchpad.net/bugs/156184 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 156184] Re: vol_id takes way too long to finish on unavailable SCSI devices
Ah, ok. Let's add the check to probe_all() too. This should fix it: http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=73ff769c90307e9ef2947c7ba013626fb65c1478 Thanks! -- vol_id takes way too long to finish on unavailable SCSI devices https://bugs.launchpad.net/bugs/156184 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 156184] Re: vol_id takes way too long to finish on unavailable SCSI devices
Scott, can you build a test package with this patch for Tore? http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=2bb4dd9766479348a2829ceb8ef583a788bfd840 So Tore can test, if it makes the timing acceptable on his box. Thanks! -- vol_id takes way too long to finish on unavailable SCSI devices https://bugs.launchpad.net/bugs/156184 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 132546] Re: fd zero byte node left after boot as /dev/.tmp-2-0
Oh, the crappy create_floppy_devices uses the argument only as a string to compose the names for the additional nodes, you should not pass a tempnode at all to that thing, just use $root/%k. -- fd zero byte node left after boot as /dev/.tmp-2-0 https://bugs.launchpad.net/bugs/132546 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 154834] Re: UUID's not correctly allocated for DMRAID devices in Gutsy
Thanks, that's looks like the same data offered by two different kernel devices.
The fix will probably prevent the wrong detection, because the striping of
volumes
make the data we check for unreachable by the scsi device. But there might still
be setups where we can get exactly the same data from both devices.
We need to bump the symlink priority of dmraid symlinks. Let's see what:
ls -l /dev/.udev/names/*B080F3DA80F3A54E*
prints?
Are there the two devices competing about the same name? Then we need to
add something like: ENV{DM_UUID}==dmraid-*, OPTIONS=link_priority=50
to the device-mapper rules.
--
UUID's not correctly allocated for DMRAID devices in Gutsy
https://bugs.launchpad.net/bugs/154834
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 154834] Re: UUID's not correctly allocated for DMRAID devices in Gutsy
What does: udevmonitor print, when you do: echo add /sys/block/dm-1/uevent Does the environment contain DM_UUID? Prefixed with dmraid-? -- UUID's not correctly allocated for DMRAID devices in Gutsy https://bugs.launchpad.net/bugs/154834 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 154834] Re: UUID's not correctly allocated for DMRAID devices in Gutsy
Oops, sorry, please add --env :) udevmonitor --env -- UUID's not correctly allocated for DMRAID devices in Gutsy https://bugs.launchpad.net/bugs/154834 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 154834] Re: UUID's not correctly allocated for DMRAID devices in Gutsy
Oh, we have a patch in dmraid, we thought that would be already merged. The plain version of dmraid misses the uuids in the dm tables: http://www.redhat.com/archives/ataraid-list/2006-September/msg1.html Scott, we may give dm-* volumes by default a higher priority than plain disks? What do you think? Now that EVMS, which did silly things here, is dead. :) -- UUID's not correctly allocated for DMRAID devices in Gutsy https://bugs.launchpad.net/bugs/154834 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 154834] Re: UUID's not correctly allocated for DMRAID devices in Gutsy
Sure, what you really want is the kernel not to create the (invalid) partitions at all for a raid device. We are working to get media change events for the disk, and we can start probing for raid setups (currently media changes are not reported, and probing a main device would store wrong information at media changes). Then we will see the raid tag at the disk database entry, which is imported into the partition event, and we can entirely ignore the partitions. -- UUID's not correctly allocated for DMRAID devices in Gutsy https://bugs.launchpad.net/bugs/154834 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 154834] Re: UUID's not correctly allocated for DMRAID devices in Gutsy
Maybe a left-over signature again, we seem to miss the version information. We should add more consistency checks to NTFS then. What does: dd if=/dev/sda1 count=2 | hexdump -C and dd if=/dev/mapper/nvidia_effeccbe1 count=2 | hexdump -C print? -- UUID's not correctly allocated for DMRAID devices in Gutsy https://bugs.launchpad.net/bugs/154834 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 154834] Re: UUID's not correctly allocated for DMRAID devices in Gutsy
I've added a fix to the git tree, which may prevent the wrong NTFS recognition. Please still provide the hexdump, so we can be sure to have the right fix. I also wonder if the nvidia dmraid metadata is recognized. What does: sudo vol_id /dev/sda print? Thanks! -- UUID's not correctly allocated for DMRAID devices in Gutsy https://bugs.launchpad.net/bugs/154834 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 147807] Re: vol_id: does not recognise FAT* partitions with sector size 8192
Sounds good, let's just add these values. -- vol_id: does not recognise FAT* partitions with sector size 8192 https://bugs.launchpad.net/bugs/147807 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 147807] Re: vol_id: does not recognise FAT* partitions with sector size 8192
Comitted a fix to the udev git tree. I have no idea how a value of 256k fit into a 16bit value. :) -- vol_id: does not recognise FAT* partitions with sector size 8192 https://bugs.launchpad.net/bugs/147807 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 93921] Re: vol_id: detects crypto_LUKS instead of ext3 UUID
As pointed out several times, just reordering the probing without adding additional checks to the probers, just moves the problems from one user the other. We've been there several times, and stopped doing this. If /lib/udev/vol_id --probe-all device returns more than one filesystem, the disk was formatted with a broken tool. Sane formatting applications wipe out all known signatures before applying a new filesystem. That's what we should fix, and possibly add more checks if the actual filesystem really exists and is still valid. -- vol_id: detects crypto_LUKS instead of ext3 UUID https://bugs.launchpad.net/bugs/93921 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 118292] Re: vol_id: detects vfat instead of ext3 UUID
Same as: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/93921/comments/11 We need to fix the formatting applications to wipe out the first few hundred kilobytes, and the last few hundred kilobytes at the end of the device before applying any new format. -- vol_id: detects vfat instead of ext3 UUID https://bugs.launchpad.net/bugs/118292 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 147807] Re: vol_id: does not recognise FAT* partitions with sector size 8192
The FAT spec says: sector size must still be less than or equal to 4096. Which tool did you use to format the volume? -- vol_id: does not recognise FAT* partitions with sector size 8192 https://bugs.launchpad.net/bugs/147807 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
