[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#697017: An improved patch over Jonathan's



On Tue, 01 Jan 2013 10:18:06 -0500 (EST), Gabriel Klawitter wrote:
> 
> sorry for the ambiguity. I did't mean cases like 0xffff and 0xFFFF but
> the cases for which this function is being used.  These are, as far as
> I've understood your post correctly, the case where root equals
> something like 08:02 and root equals a hex decimal numer with at most 4
> digits like abcd.

What confused me was that you seemed to think that upper case vs.
lower case made a difference.  It doesn't.  Not to the shell hex
conversion function anyway.
> 
> The evaluation a=$((0xcompute)) might leave the value of the variable
> intact but the script fails and init dies.(http://pastebin.com/7BJAY1Wj)

Yes, that was precisely my point.  That's why Jonathan wrote his patch
(and I made a slight correction to it).
> 
> Your patch will sort out cases like 08:02 but not the case where root
> equals 'facade', 'added' or 'dead01'.
> I'm using the root= parameter for giving the name of the boot profile,
> which might differ from 'compute'.

Hmm.  I'm not familiar with the term "boot profile".  Either my
ignorance is showing, or you are using the "root=" kernel boot parameter
for something for which it was not intended.

Here is a comment from the kernel source code (init/do_mounts.c) which
explains the supported uses of the "root=" kernel boot parameter

   We accept the following variants:

      1) device number in hexadecimal represents itself
      2) /dev/nfs represents Root_NFS (0xff)
      3) /dev/<disk_name> represents the device number of disk
      4) /dev/<disk_name><decimal> represents the device number
         of partition - device number of disk plus the partition number
      5) /dev/<disk_name>p<decimal> - same as the above, that form is
         used when disk name of partitioned disk ends on a digit.
      6) PARTUUID=00112233-4455-6677-8899-AABBCCDDEEFF representing the
         unique id of a partition if the partition table provides it.
      7) PARTUUID=<UUID>/PARTNROFF=<int> to select a partition in relation to
         a partition with a known unique id.

      If name doesn't have fall into the categories above, we return (0,0).

So unless I'm missing something, it appears that you are attempting to use
the "root" kernel boot parameter in a non-standard way.
> 
> With your patch 'dead01' would still
> be interpreted as a hex number which would be parsed correctly this
> time, but the function would evaluate it as a hex number that'd be
> changed for lilo compatibility.  This is a rare case and I could
> circumvent it by requiring that the root string shouldn't contain only
> hex digits.

That is true.  We could maybe add the restriction that the hex number
must be less than or equal to four characters, as in lilo's case it always
will be.  But that still leaves things like "dead", "fade", and "ace"
as valid hexadecimal numbers that you might want to use as "boot profile"
names.
> 
> I haven't tested your patch yet, as I'm convinced that it'll work fine
> for root=compute but not for root=facade01.

Again, it appears to me that you are using the "root" kernel boot
parameter in a non-standard way, in which case you are on your own.
There is a legitimate bug in the parse_numeric function which has
been discovered as the result of your bug report, and it appears to
me that this proposed patch fixes that problem.  But adding support
for "boot profiles", whatever that may be, is something that you will
need to submit to the Linux kernel team (and initramfs-tools upstream
development) as an enhancement request.

-- 
  .''`.     Stephen Powell    
 : :'  :
 `. `'`
   `-


Reply to: