Bug#697017: root=compute fails at parse_numeric() for lilo compatibility

2014-08-30 Thread Michael Prokop
Hi everyone, while going through the list of initramfs-tools bugs I stumbled upon this one. * Stephen Powell [Sat Jan 05, 2013 at 09:57:08AM -0500]: > On Thu, 03 Jan 2013 01:49:14 -0500 (EST), Jonathan Nieder wrote: > > Less than or equal to 4095 and 255 respectively, technically. ;-) > > The f

Bug#697017: root=compute fails at parse_numeric() for lilo compatibility

2014-08-31 Thread Stephen Powell
On Sat, 30 Aug 2014 18:36:34 -0400 (EDT), Michael Prokop wrote: > > If someone would provide an up2date patch (against current git > master would be awesome) which resolves this issue (without possibly > breaking anything else :)) I'm absolutely willing to accept it. Here is what I am currently u

Bug#697017: root=compute fails at parse_numeric() for lilo compatibility

2012-12-30 Thread Gabriel Klawitter
Package: initramfs-tools Version: 0.109 Dear Maintainer, I'm using your package to set up a netboot environment where I use a script at local-bottom to retrieve a image to extract it into a tmpfs. The kernel command line looks as follows: rw rootfstype=tmpfs root=compute imgurl=http://10.0.0.2

Bug#697017: root=compute fails at parse_numeric() for lilo compatibility

2012-12-30 Thread Stephen Powell
On Sun, 30 Dec 2012 15:58:14 -0500 (EST), Gabriel Klawitter wrote: > > Package: initramfs-tools > Version: 0.109 > > Dear Maintainer, > > I'm using your package to set up a netboot environment where I use a > script at local-bottom to retrieve a image to extract it into a tmpfs. > The kernel com

Bug#697017: root=compute fails at parse_numeric() for lilo compatibility

2012-12-30 Thread Jonathan Nieder
Hi, Stephen Powell wrote: > The pattern in question, [A-Fa-f0-9]*, will match any string of characters of > arbitrary length (at least one character long) whose first character is a > valid hex digit (0-9, a-f, or A-F). Remember, this is a shell pattern, not > a regular expression. How about th

Bug#697017: root=compute fails at parse_numeric() for lilo compatibility

2012-12-31 Thread Stephen Powell
On Sun, 30 Dec 2012 21:28:33 -0500 (EST), Jonathan Nieder wrote: > > How about this patch? > ... I like your patch better. It is more general and solves the more general problem of non-numeric strings being treated like numeric strings. Whenever I see something which includes a bracketed expre

Bug#697017: root=compute fails at parse_numeric() for lilo compatibility

2013-01-01 Thread Jonathan Nieder
gabriel wrote: > Stephen Powell schrieb am Tue, Jan 01, 2013 at > 11:56:00AM -0500: >>We accept the following variants: >> >> 1) device number in hexadecimal represents itself > > I haven't read that kernel source code before and therefore didn't know that > the root parameter may be

Bug#697017: root=compute fails at parse_numeric() for lilo compatibility

2013-01-02 Thread Stephen Powell
On Tue, 01 Jan 2013 13:50:07 -0500 (EST), Jonathan Nieder wrote: > > Technically the current code only makes sense for 5 hexdigits. > > After that, something more complicated could work: > > # 16 hexdigits: 0xMmmMMMmm > devno=$(( 0x${1} )) > > major=$(( (($devno >> 8)

Bug#697017: root=compute fails at parse_numeric() for lilo compatibility

2013-01-02 Thread Jonathan Nieder
Stephen Powell wrote: > The current code works the way that lilo works, and I doubt that > the lilo code in question will ever change its algorithm. It currently > assumes that both the major and minor device numbers of the root file > system are less than or equal to 255, and that is what the pa

Bug#697017: root=compute fails at parse_numeric() for lilo compatibility

2013-01-05 Thread Stephen Powell
On Thu, 03 Jan 2013 01:49:14 -0500 (EST), Jonathan Nieder wrote: > > Less than or equal to 4095 and 255 respectively, technically. ;-) > > The full formula was just trivia. (stat's st_dev and lilo's MKDEV() > macro use it, for what it's worth.) Well I rolled up my sleeves and took a look at lil