From mboxrd@z Thu Jan  1 00:00:00 1970
From: Maxim Levitsky <maximlevitsky@gmail.com>
Date: Sun, 20 Sep 2009 21:28:29 +0000
Subject: Re: [BUG] udev doesn't run blkid on cdroms with one session
Message-Id: <1253482109.4941.7.camel@maxim-laptop>
List-Id: <linux-hotplug.vger.kernel.org>
References: <1253411352.3791.14.camel@maxim-laptop>
In-Reply-To: <1253411352.3791.14.camel@maxim-laptop>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
To: linux-hotplug@vger.kernel.org

On Sun, 2009-09-20 at 06:00 +0200, Kay Sievers wrote:=20
> On Sun, Sep 20, 2009 at 03:49, Maxim Levitsky <maximlevitsky@gmail.com> w=
rote:
> > A line in 60-persistent-storage.rules states:
> >
> > KERNEL=3D"sr*", ENV{ID_CDROM_MEDIA}=3D"?*", IMPORT{program}=3D"/sbin/bl=
kid -o udev -p -u noraid -O $env{ID_CDROM_MEDIA_SESSION_LAST_OFFSET} $tempn=
ode"
> >
> > It seems to assume that ID_CDROM_MEDIA_SESSION_LAST_OFFSET is always
> > set, since otherwise blkid fails:
> >
> > maxim@maxim-laptop:~$ /sbin/blkid -o udev -p -u noraid -O  /dev/sr0
> > The low-probe option requires a device
>=20
> In vol_id it was an optional parameter, and worked fine with an empty
> option, at least when long options are used:
>    { "offset", optional_argument, NULL, 'o' },
>=20
> We could also make cdrom_id print the "0", that might be the simplest.

Indeed,
I have reported this bug at
https://bugs.launchpad.net/ubuntu/+source/udev/+bug/431055

Martin Pitt, has commited now a fix for this problem by splitting the
rule in two according to value existence of
ID_CDROM_MEDIA_SESSION_LAST_OFFSET



>=20
> > maxim@maxim-laptop:~$ /sbin/blkid -o udev -p -u noraid   /dev/sr0
> > ID_FS_LABEL=CDROM
> > ID_FS_LABEL_ENC=CDROM\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20
> > ID_FS_VERSION=3DJoliet\x20Extension
> > ID_FS_TYPE=3Diso9660
> > ID_FS_USAGE=3Dfilesystem
> >
> > Maybe this is a change in blkid
> > (btw, you notice obvious bug, the label is 'padded' with spaces, I will
> > report that to util-linux package maintainers)
>=20
> Maybe this is expected in the *_ENC version of the string, I'm not sure.
>=20

Do you know where to report the util-linux bugs?

There was a fork, util-linux-ng, but ubuntu seems to use util-linux
naming, but it seems to be based on -ng.

As usual, filling a lanchpad bug didn't really help.

I think that _ENC means that non printable chars are printed as \xNNN,
and indeed, here I see the long row of spaces after the volume name.

I am sure this is trivial to fix, but I want to know where to report
that (launchpad sadly doesn't count...)


Best regards,
Maxim Levitsky