All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: Bug#785116: util-linux: blkid -s returns too much information
       [not found] <20150512132634.1127.8640.reportbug@hex.shelbyville.oz>
@ 2015-05-13  6:36 ` Andreas Henriksson
  2015-05-13 10:37   ` Karel Zak
  0 siblings, 1 reply; 5+ messages in thread
From: Andreas Henriksson @ 2015-05-13  6:36 UTC (permalink / raw)
  To: Ron, 785116; +Cc: util-linux

Hello Ron!

On Tue, May 12, 2015 at 10:56:34PM +0930, Ron wrote:
> Package: util-linux
> Version: 2.25.2-6
> Severity: important
> 
> Hi, 
> 
> Sometime between wheezy and jessie, it appears blkid -s got broken.
> In jessie it now does this:
> 
>  # blkid -s UUID -o export /dev/sdb1
>  DEVNAME=/dev/sdb1
>  UUID=fb936a62-4a21-4cc5-a55e-da21aa3f6685

The reason DEVNAME is printed is because you're using the export
output format.

This behaviour was introduced in:

commit dab33573876270fec7550252bcc29c34e9ad3889
Author: Karel Zak <kzak@redhat.com>
Date:   Fri Mar 2 14:05:26 2012 +0100

    blkid: add DEVNAME= to export output format
    
    Reported-by: Balamurugan Arumugam <barumuga@redhat.com>
    Signed-off-by: Karel Zak <kzak@redhat.com>

diff --git a/misc-utils/blkid.c b/misc-utils/blkid.c
index b0524ca..dfdb8b9 100644
--- a/misc-utils/blkid.c
+++ b/misc-utils/blkid.c
@@ -310,6 +310,8 @@ static void print_value(int output, int num, const char *devname,
                print_udev_format(name, value);
 
        } else if (output & OUTPUT_EXPORT_LIST) {
+               if (num == 1 && devname)
+                       printf("DEVNAME=%s\n", devname);
                fputs(name, stdout);
                fputs("=", stdout);
                safe_print(value, valsz);

Apparently this behaviour is established since a very long time:
$ git describe dab33573876270fec7550252bcc29c34e9ad3889
v2.21-40-gdab3357
Possibly changing the output format now could be risky.
It's very unfortunate that Debian has lagged so long with updating
util-linux which means we notice these things so long after they
appeared.

> 
> Which is a bit unfortunate when the reason for doing that was to get
> the UUID for an fstab entry in an installer preseed file :)

Lets ask upstream if DEVNAME is considered a tag which should
be included in the tag filtering.... CCed.

Regards,
Andreas Henriksson

^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: Bug#785116: util-linux: blkid -s returns too much information
  2015-05-13  6:36 ` Bug#785116: util-linux: blkid -s returns too much information Andreas Henriksson
@ 2015-05-13 10:37   ` Karel Zak
  2015-05-13 21:20     ` Ron
  0 siblings, 1 reply; 5+ messages in thread
From: Karel Zak @ 2015-05-13 10:37 UTC (permalink / raw)
  To: Andreas Henriksson; +Cc: Ron, 785116, util-linux

On Wed, May 13, 2015 at 08:36:04AM +0200, Andreas Henriksson wrote:
> Possibly changing the output format now could be risky.

 Yes. Ron is right, the current behaviour is strange, but I'm not sure
 if we want to fix it after 3 years.
 
 And I'm also not sure it the current behavior is so big problem. If you 
 want just one value than it makes more sense to use

    # blkid  -s UUID -o value /dev/sdb1
    f0710187-82bf-4646-b2e3-11b017e31218

 and if you ask for more tags by "-o export" than you cannot rely on 
 order of the lines, so DEVNAME= in the output cannot be a problem.

> Lets ask upstream if DEVNAME is considered a tag which should
> be included in the tag filtering.... CCed.

 I have a patch to fix it, but now when I think about it it's probably
 better to keep the current behavior than fix one regression by
 another regression ;-)

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Bug#785116: util-linux: blkid -s returns too much information
  2015-05-13 10:37   ` Karel Zak
@ 2015-05-13 21:20     ` Ron
  2015-05-14  6:30       ` Karel Zak
  2015-05-15  9:35       ` Andreas Henriksson
  0 siblings, 2 replies; 5+ messages in thread
From: Ron @ 2015-05-13 21:20 UTC (permalink / raw)
  To: Karel Zak; +Cc: Andreas Henriksson, Ron, 785116, util-linux

On Wed, May 13, 2015 at 12:37:06PM +0200, Karel Zak wrote:
> On Wed, May 13, 2015 at 08:36:04AM +0200, Andreas Henriksson wrote:
> > Possibly changing the output format now could be risky.
> 
>  Yes. Ron is right, the current behaviour is strange, but I'm not sure
>  if we want to fix it after 3 years.

Hmm.  Being that old complicates things a bit more, yeah.  I guess Wheezy
missed out on getting that update, because in the case of Debian stable
releases at least, right now it's a regression that's still only about
a month old :)

>  And I'm also not sure it the current behavior is so big problem. If you 
>  want just one value than it makes more sense to use
> 
>     # blkid  -s UUID -o value /dev/sdb1
>     f0710187-82bf-4646-b2e3-11b017e31218

The use case I have for it that bit me here was using it for installer
preseeding for pxe booting new VMs, where I do something like:

 echo "$(blkid -s UUID -o export /dev/sdb1) none swap sw,discard,nofail 0 0" >> /target/etc/fstab;

and for which the export format with UUID= was perfect out of the box.
Changing that to use -o value isn't a huge problem, but getting the
extra DEVNAME in there kind of was.

>  and if you ask for more tags by "-o export" than you cannot rely on 
>  order of the lines, so DEVNAME= in the output cannot be a problem.

Right, in the situation where you *do* want multiple values, caring
about the order should be less of a problem, since you'd just access
the variables being set rather than trying to parse or interpret
them literally.  If for some reason you did care about the order,
you'd run that multiple times with one value for each invocation.

Which, right now if you do that, you'll end up with something like:

 # blkid -s UUID -o export /dev/sda2; blkid -s TYPE -o export /dev/sda2
 DEVNAME=/dev/sda2
 UUID=9621a7e3-14a1-4d03-8250-b4fbeb79999b
 DEVNAME=/dev/sda2
 TYPE=ext4

I guess the other case where that might bite you is if you were already
using DEVNAME as a local variable for something else ...

Or if you'd run the first one of those, changed the value of DEVNAME in
some way, and then run the second somewhere later in a script.


> > Lets ask upstream if DEVNAME is considered a tag which should
> > be included in the tag filtering.... CCed.
> 
>  I have a patch to fix it, but now when I think about it it's probably
>  better to keep the current behavior than fix one regression by
>  another regression ;-)

Yeah, I completely sympathise with the pain in that line of thinking.
I guess the question for me would be is there really any use case
where someone might actually be relying on this (mis)behaviour?
One where they aren't already explicitly passing -s DEVNAME as one
of the tags they want exported (which really is what you should be
doing if that's what you want).

I'm weighing up the damage that changing it again might do relative to
the damage of having this behave oddly forever more.  Leaving it like
this sort of means you can't ever really use 'export' with -s at all,
it only makes sense to let it output everything (since you'll get some
subset of everything regardless of what you ask for anyway).

If the risk of changing it is too great, because there is some existing
user or use case that reasonably depends on it, that would sort of mean
we now need to add a -o export-just-what-i-asked-for-really-i-mean-it
format, which does the job that export was originally intended for.


In my particular case this time, a workaround to use -o value will be
ok (and I'll need to do that for the next few years now whatever we
do, to be compatible with things that are in the wild), but it seems
like there is value in doing *something* to fix this in the long term,
whether that is changing what export does again, or adding a new
export-strict or some such to provide that function in a forward safe
way.

  Thanks!
  Ron



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Bug#785116: util-linux: blkid -s returns too much information
  2015-05-13 21:20     ` Ron
@ 2015-05-14  6:30       ` Karel Zak
  2015-05-15  9:35       ` Andreas Henriksson
  1 sibling, 0 replies; 5+ messages in thread
From: Karel Zak @ 2015-05-14  6:30 UTC (permalink / raw)
  To: Ron; +Cc: Andreas Henriksson, 785116, util-linux

On Thu, May 14, 2015 at 06:50:52AM +0930, Ron wrote:
> Right, in the situation where you *do* want multiple values, caring
> about the order should be less of a problem, since you'd just access
> the variables being set rather than trying to parse or interpret
> them literally.  If for some reason you did care about the order,
> you'd run that multiple times with one value for each invocation.
> 
> Which, right now if you do that, you'll end up with something like:
> 
>  # blkid -s UUID -o export /dev/sda2; blkid -s TYPE -o export /dev/sda2
>  DEVNAME=/dev/sda2
>  UUID=9621a7e3-14a1-4d03-8250-b4fbeb79999b
>  DEVNAME=/dev/sda2
>  TYPE=ext4
> 
> I guess the other case where that might bite you is if you were already
> using DEVNAME as a local variable for something else ...

I'd like to keep blkid as very basic command line interface to
libblkid and as the library test program. For standard use cases 
and scripts it's better to use lsblk(8) command which provides 
more information and better control on output format:

        # lsblk --pairs -o FSTYPE,UUID /dev/sda2
        FSTYPE="ext4" UUID="c5490147-2a6c-4c8a-aa1b-33492034f927"

        # lsblk --pairs -o UUID,FSTYPE /dev/sda2
        UUID="c5490147-2a6c-4c8a-aa1b-33492034f927" FSTYPE="ext4"

and it reads information from udev db or from libblkid.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Bug#785116: util-linux: blkid -s returns too much information
  2015-05-13 21:20     ` Ron
  2015-05-14  6:30       ` Karel Zak
@ 2015-05-15  9:35       ` Andreas Henriksson
  1 sibling, 0 replies; 5+ messages in thread
From: Andreas Henriksson @ 2015-05-15  9:35 UTC (permalink / raw)
  To: Ron, 785116; +Cc: Karel Zak, util-linux

Hello!

On Thu, May 14, 2015 at 06:50:52AM +0930, Ron wrote:
[...]
> Yeah, I completely sympathise with the pain in that line of thinking.
> I guess the question for me would be is there really any use case
> where someone might actually be relying on this (mis)behaviour?
> One where they aren't already explicitly passing -s DEVNAME as one
> of the tags they want exported (which really is what you should be
> doing if that's what you want).
[...]

I'm willing to bet that noone explicitly uses "-s DEVNAME" already, as
that simply does not work (because DEVNAME is not a tag).

Hacking the code to make DEVNAME a tag looked trivial to me but changing
things (again) will be risk ending up in a neverending back-and-forth
dance between people wanting/relying on different behaviours. Thats
why I wanted to ask for input from upstream as soon as possible in
this matter, even before producing the patch.

Regards,
Andreas Henriksson

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2015-05-15  9:35 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20150512132634.1127.8640.reportbug@hex.shelbyville.oz>
2015-05-13  6:36 ` Bug#785116: util-linux: blkid -s returns too much information Andreas Henriksson
2015-05-13 10:37   ` Karel Zak
2015-05-13 21:20     ` Ron
2015-05-14  6:30       ` Karel Zak
2015-05-15  9:35       ` Andreas Henriksson

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.