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 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 source code, > particularly the MKDEV, MAJOR, and MINOR functions, and now I > understand what you are talking about. And you're right. The current > initramfs-tools code, particularly the parse_numeric function, can > handle major device numbers up to 4095 and minor device numbers up to > 255. Whether lilo itself, in actual fact, can correctly handle major > and minor device numbers outside this range, I don't know. I didn't > dig deeply enough to verify that. But given that the above three > functions understand the format, I suspect that it will. If you want > to enhance the code to correctly handle the full 16-hex-digit composite > device number, go ahead. As you say, it's trivial. And that would > once again make you the author of the final patch, which is fine. Is anyone still interested in getting this issue resolved? 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. Myself not being a lilo user and not seeing any real progress in this issue for more than 1,5 years am tending to close this report otherwise. Thanks for any input. regards, -mika-
signature.asc
Description: Digital signature
