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

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 full

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 lilo's

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) 0xfff) |

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

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

2013-01-01 Thread Jonathan Nieder
gabriel wrote: Stephen Powell zlinux...@wowway.com 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

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

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

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 command

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 this