Bug#606806: initramfs-tools: Handling of numeric root= arguments is not udev-friendly
tags 606806 pending stop On Sat, 11 Dec 2010, Evan Broder wrote: I see. I wasn't aware of BUSYBOX=no. But looking at this again, I think I actually want to take a different approach in order to maintain the current semantics of setting root=X:Y. Ok great, applied in maks/num_root branch in http://git.debian.org/?p=kernel/initramfs-tools.git;a=summary could you please have a look that i didn't botch the commit as I had to hand apply due to the attached patch, beeing against latest Ubuntu and having a strange patch level? pending review it will hit master which is scheduled for post squeeze fixes. thank you. -- maks -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101214174203.gd18...@stro.at
Processed: Re: Bug#606806: initramfs-tools: Handling of numeric root= arguments is not udev-friendly
Processing commands for cont...@bugs.debian.org: tags 606806 pending Bug #606806 [initramfs-tools] initramfs-tools: Handling of numeric root= arguments is not udev-friendly Added tag(s) pending. stop Stopping processing here. Please contact me if you need assistance. -- 606806: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606806 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.129234852832421.transcr...@bugs.debian.org
Bug#606806: initramfs-tools: Handling of numeric root= arguments is not udev-friendly
On Tue, Dec 14, 2010 at 9:42 AM, maximilian attems m...@stro.at wrote: Ok great, applied in maks/num_root branch in http://git.debian.org/?p=kernel/initramfs-tools.git;a=summary could you please have a look that i didn't botch the commit as I had to hand apply due to the attached patch, beeing against latest Ubuntu and having a strange patch level? pending review it will hit master which is scheduled for post squeeze fixes. thank you. Patch looks good to me. Thanks for everyone's help. - Evan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimmegq09br84dd9x=dnevm2ukm7s-vngdjcg...@mail.gmail.com
Bug#606806: initramfs-tools: Handling of numeric root= arguments is not udev-friendly
Hello! On Dec 11, Evan Broder wrote: On Sat, Dec 11, 2010 at 1:34 PM, Ben Hutchings b...@decadent.org.uk wrote: On Sat, 2010-12-11 at 13:14 -0800, Evan Broder wrote: Package: initramfs-tools Version: 0.98.1 Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu natty ubuntu-patch If you pass a root= argument with a numeric device number (i.e. root=0806), that's currently resolved by running mknod to create a /dev/root device with an appropriate major/minor number and setting ROOT=/dev/root (the parse_numeric function in scripts/functions). [...] Maybe this feature should simply be deprecated. What do you use it for? I strongly object as long as GRUB and especially GRUB2 are such a mess that they either forcefully invade the MBR and/or need additional undocumented sector space in track 0 (which destroys e.g. recovery mechanisms on notebooks) or refuse to go into (only) a partition boot sector at all (GRUB2)! This is also the answer to you question what I use 'it' for, namely simply LILO. I don't use the feature myself; I was fixing the bug on behalf of a user that reported it in Ubuntu, since it seemed simple to fix with a low chance of regressing other behavior. I've CC'd him to find out. Ruediger, can you expand on why you're using root=0806 instead of root=/dev/sda6 or a UUID or some other means of specifying the root device? Of course, and I'm glad to. Because I actually use 'root=/dev/sda6' in LILO's /etc/lilo.conf - and have always done so. It is from there, that the problems arise, 'root=0806' was just used to demonstrate how(!) wait-for-root fails. The following is how I 'believe', but have not tested(!), that the problem arises: LILO transfers the 'root=/dev/sda6' into its 'map' or bootparameter section for the next start by analyzing the 'root'-device and then stores its minor and major number there. With the next start it just transfers the 'root=0806' information to the kernel and no '/dev/sda6'; from there parse_numeric picks up the information and (previously) mknod'ed a /dev/root device. This is(/was) what wait-for-root isn't(/wasn't) able to handle. In principle it is wait-for-root that is to blame for the problem, but modifying parse_numeric seems ok for me, as it doesn't seem to break the structure. You can still do both, mknod a /dev/root and set some variable to a udev-friendly information. Please keep in mind, that accuracy goes before(!) accelleration or cutting features. I've seen so many /dev-mechanisms come and go, that I don't want to sacrifice the - at least to my knowledge - o n l y non-intruding boot-method (for an i386-system), LILO, to some pseudo accelleration mechanism that might go away with the next distribution version. Thanks and best regards, Ruediger Oberhage -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101213083144.ga20...@lx24.zim.uni-duisburg-essen.de
Bug#606806: initramfs-tools: Handling of numeric root= arguments is not udev-friendly
On Mon, Dec 13, 2010 at 09:31:44AM +0100, H.-R. Oberhage wrote: On Dec 11, Evan Broder wrote: On Sat, Dec 11, 2010 at 1:34 PM, Ben Hutchings b...@decadent.org.uk wrote: Maybe this feature should simply be deprecated. What do you use it for? It is used by LILO. I strongly object as long as GRUB and especially GRUB2 are such a mess that they either forcefully invade the MBR No, you have to explicitely install it. need additional undocumented sector space in track 0 (which destroys e.g. recovery mechanisms on notebooks) This is unallocated space, so free for use. In case of GPT, this area is already filled completely with information and you need a real entry for the bootloader data. or refuse to go into (only) a partition boot sector at all (GRUB2)! It does? This is also the answer to you question what I use 'it' for, namely simply LILO. We never talked about deprecating LILO. It just needs to stop mangling the information. Bastian -- The sight of death frightens them [Earthers]. -- Kras the Klingon, Friday's Child, stardate 3497.2 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101213093218.ga2...@wavehammer.waldi.eu.org
Bug#606806: initramfs-tools: Handling of numeric root= arguments is not udev-friendly
On Mon, 13 Dec 2010 03:31:44 -0500 (EST), H. R. Oberhage wrote: This is also the answer to you question what I use 'it' for, namely simply LILO. As I suspected. First of all, as Ben is well aware, I am not a maintainer for initramfs-tools, udev, or any other Debian package. I'm just a fellow lilo user, and therefore, an interested party. The translation of a root specification from user-space notation (root=/dev/whatever) to kernel-space notation (root=, where is a three- or four-digit hexadecimal number representing the major and minor number of the device) is something that lilo has always done. There is nothing new here. Adding udev to the mix is what has complicated things. There may be other boot loaders which do the same thing. I also am opposed to deprecating the ability of initramfs-tools to handle a hexadecimal numeric root specification. While the powers that be figure out how best to handle this type of root specification, I would like to call your attention to a work-around for the problem that will get you up and running in the meantime: use a UUID specification. For example, on my system I use ... boot=/dev/disk/by-uuid/055d446a-977d-4aa6-877d-62c716f5e85a ... root=UUID=055d446a-977d-4aa6-877d-62c716f5e85a in /etc/lilo.conf. In this example, the lilo stage 1 boot loader is installed in the boot sector of a primary partition, which is also the root partition. (It happens to correspond to /dev/sda2 on my system.) Note that boot must be a block special device or a symbolic link to a block special device, as above, but root can be a quoted UUID specification, as supported by /etc/fstab. When the root device is specified this way, lilo does not do any translation. The kernel command line sees ... root=UUID=055d446a-977d-4aa6-877d-62c716f5e85a ... which gets you around the problem for now. Respectfully submitted, -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2056035689.1026734.1292241127784.javamail.r...@md01.wow.synacor.com
Bug#606806: initramfs-tools: Handling of numeric root= arguments is not udev-friendly
Thanks, ... On Dec 13, Stephen Powell wrote: [...] specification. For example, on my system I use ... boot=/dev/disk/by-uuid/055d446a-977d-4aa6-877d-62c716f5e85a ... root=UUID=055d446a-977d-4aa6-877d-62c716f5e85a in /etc/lilo.conf. .. for a very valuable hint (to me, at least). This probably means, that a disk LABEL will do, too?! [I don't trust the UUID :-). They can change so often (reformatting swap) and are not so 'unique' at all, e.g. in the case of (physical) snap shots :-).] I like to be consistent using either /dev/sdaX (or whatever), or UUIDs, or LABELs and with LILO always had the problem to specify the boot-device properly, when not using /dev/sd...; I just missed the idea of specifying it via (e.g.) by-label. So thanks again for that nice tip! Best regards, Ruediger -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101213124833.ga31...@lx24.zim.uni-duisburg-essen.de
Bug#606806: initramfs-tools: Handling of numeric root= arguments is not udev-friendly
On Mon, 2010-12-13 at 13:48 +0100, H.-R. Oberhage wrote: Thanks, ... On Dec 13, Stephen Powell wrote: [...] specification. For example, on my system I use ... boot=/dev/disk/by-uuid/055d446a-977d-4aa6-877d-62c716f5e85a ... root=UUID=055d446a-977d-4aa6-877d-62c716f5e85a in /etc/lilo.conf. .. for a very valuable hint (to me, at least). This probably means, that a disk LABEL will do, too?! [I don't trust the UUID :-). They can change so often (reformatting swap) and are not so 'unique' at all, e.g. in the case of (physical) snap shots :-).] [...] Yes, labels work too. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Bug#606806: initramfs-tools: Handling of numeric root= arguments is not udev-friendly
Package: initramfs-tools
Version: 0.98.1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu natty ubuntu-patch
If you pass a root= argument with a numeric device number
(i.e. root=0806), that's currently resolved by running mknod to create
a /dev/root device with an appropriate major/minor number and setting
ROOT=/dev/root (the parse_numeric function in scripts/functions).
However, this /dev/root device is completely unknown to udev. On
Ubuntu, this leads to problems because we use udev to wait for the
root device to appear. Since /dev/root isn't in udev's database, the
boot hangs forever (well, it hangs until rootdelay passes).
udev's standard configuration creates /dev/block/N:N symlinks for
every block device in its database (see the first non-comment line of
/lib/udev/rules.d/50-udev-default.rules). Setting ROOT to the
/dev/block/N:N symlink instead of creating a new /dev/root device and
setting ROOT to that solves Ubuntu's problem.
See https://bugs.launchpad.net/bugs/576429 for more discussion.
We've applied a patch (attached) to do this, and thought you might be
interested in doing the same.
Thanks.
-- System Information:
Debian Release: squeeze/sid
APT prefers maverick-updates
APT policy: (500, 'maverick-updates'), (500, 'maverick-security'), (500,
'maverick')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.35-23-generic (SMP w/1 CPU core)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
=== modified file 'scripts/functions'
--- scripts/functions 2010-10-04 22:34:10 +
+++ scripts/functions 2010-11-27 02:56:12 +
@@ -364,8 +364,8 @@
return
;;
[0-9]*:[0-9]*)
- minor=${1#*:}
- major=${1%:*}
+ minor=$(echo ${1#*:} | sed -e 's/^0*//')
+ major=$(echo ${1%:*} | sed -e 's/^0*//')
;;
[A-Fa-f0-9]*)
value=$(( 0x${1} ))
@@ -377,8 +377,7 @@
;;
esac
- mknod -m 600 /dev/root b ${major} ${minor}
- ROOT=/dev/root
+ ROOT=/dev/block/${major}:${minor}
}
# Parameter: device node to check
Bug#606806: initramfs-tools: Handling of numeric root= arguments is not udev-friendly
On Sat, 2010-12-11 at 13:14 -0800, Evan Broder wrote: Package: initramfs-tools Version: 0.98.1 Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu natty ubuntu-patch If you pass a root= argument with a numeric device number (i.e. root=0806), that's currently resolved by running mknod to create a /dev/root device with an appropriate major/minor number and setting ROOT=/dev/root (the parse_numeric function in scripts/functions). [...] Maybe this feature should simply be deprecated. What do you use it for? Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Bug#606806: initramfs-tools: Handling of numeric root= arguments is not udev-friendly
On Sat, Dec 11, 2010 at 1:34 PM, Ben Hutchings b...@decadent.org.uk wrote: On Sat, 2010-12-11 at 13:14 -0800, Evan Broder wrote: Package: initramfs-tools Version: 0.98.1 Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu natty ubuntu-patch If you pass a root= argument with a numeric device number (i.e. root=0806), that's currently resolved by running mknod to create a /dev/root device with an appropriate major/minor number and setting ROOT=/dev/root (the parse_numeric function in scripts/functions). [...] Maybe this feature should simply be deprecated. What do you use it for? I don't use the feature myself; I was fixing the bug on behalf of a user that reported it in Ubuntu, since it seemed simple to fix with a low chance of regressing other behavior. I've CC'd him to find out. Ruediger, can you expand on why you're using root=0806 instead of root=/dev/sda6 or a UUID or some other means of specifying the root device? Thanks -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikw0fu2ube9kh7ztmfeysaraytfryoolu1fv...@mail.gmail.com
Bug#606806: initramfs-tools: Handling of numeric root= arguments is not udev-friendly
On Sat, Dec 11, 2010 at 01:14:42PM -0800, Evan Broder wrote:
If you pass a root= argument with a numeric device number
(i.e. root=0806), that's currently resolved by running mknod to create
a /dev/root device with an appropriate major/minor number and setting
ROOT=/dev/root (the parse_numeric function in scripts/functions).
However, this /dev/root device is completely unknown to udev. On
Ubuntu, this leads to problems because we use udev to wait for the
root device to appear. Since /dev/root isn't in udev's database, the
boot hangs forever (well, it hangs until rootdelay passes).
udev's standard configuration creates /dev/block/N:N symlinks for
every block device in its database (see the first non-comment line of
/lib/udev/rules.d/50-udev-default.rules). Setting ROOT to the
/dev/block/N:N symlink instead of creating a new /dev/root device and
setting ROOT to that solves Ubuntu's problem.
See https://bugs.launchpad.net/bugs/576429 for more discussion.
We've applied a patch (attached) to do this, and thought you might be
interested in doing the same.
Thanks.
thank you for submitting, I had seen it and had a question to the patch.
=== modified file 'scripts/functions'
--- scripts/functions 2010-10-04 22:34:10 +
+++ scripts/functions 2010-11-27 02:56:12 +
@@ -364,8 +364,8 @@
return
;;
[0-9]*:[0-9]*)
- minor=${1#*:}
- major=${1%:*}
+ minor=$(echo ${1#*:} | sed -e 's/^0*//')
+ major=$(echo ${1%:*} | sed -e 's/^0*//')
I had wondered why you remove leading nulls, but now thanks
to your aboves desc I do not understand.
Now the trouble is the implementation, please use shell parameter
expansion. sed assumes busybox in the initramfs, which might not be
with the case with BUSYBOX=no for small initramfs or mem constraint
boxes. something like ${minor#0}, not sure if we need to account for more
then 2 prefixed zeroes, in this case shell guru's can give a hint.
;;
[A-Fa-f0-9]*)
value=$(( 0x${1} ))
@@ -377,8 +377,7 @@
;;
esac
- mknod -m 600 /dev/root b ${major} ${minor}
- ROOT=/dev/root
+ ROOT=/dev/block/${major}:${minor}
}
# Parameter: device node to check
this assumes udev running in initramfs for the symlink.
together with devtmpfs and force loading one can built one without,
but I agree that this may now be very special case.
thank you for the feedback.
--
maks
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101211214632.ga17...@vostochny.stro.at
Bug#606806: initramfs-tools: Handling of numeric root= arguments is not udev-friendly
On Sat, 11 Dec 2010 16:34:56 -0500 (EST), Ben Hutchings wrote: On Sat, 2010-12-11 at 13:14 -0800, Evan Broder wrote: If you pass a root= argument with a numeric device number (i.e. root=0806), that's currently resolved by running mknod to create a /dev/root device with an appropriate major/minor number and setting ROOT=/dev/root (the parse_numeric function in scripts/functions). Maybe this feature should simply be deprecated. What do you use it for? Pardon me for butting in here, gentlemen, but I think I know the answer to Ben's question. This is done by a number of boot loaders. I know lilo does it, and I think zipl (part of s390-tools) does it also. If, for example, in /etc/lilo.conf one identifies the root device as root=/dev/sda6 then lilo's map installer converts this specification into a four-digit hexadecimal number, where the first two hex digits are the major number of the device and the last two hex digits are the minor number of the device. Thus, /dev/sda6 becomes 0806, meaning the device with major number 8 and minor number 6. At boot time, lilo passes a kernel command line to the kernel that says ... root=806 ... (the leading zero is suppressed). Chances are, the user is not directly specifying the root device as a hexadecimal number anywhere. The boot loader makes this substitution. lilo has done this forever, and zipl was patterned after lilo. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2011415305.1003437.1292106009163.javamail.r...@md01.wow.synacor.com
Bug#606806: initramfs-tools: Handling of numeric root= arguments is not udev-friendly
On Sat, Dec 11, 2010 at 1:46 PM, maximilian attems m...@stro.at wrote:
thank you for submitting, I had seen it and had a question to the patch.
=== modified file 'scripts/functions'
--- scripts/functions 2010-10-04 22:34:10 +
+++ scripts/functions 2010-11-27 02:56:12 +
@@ -364,8 +364,8 @@
return
;;
[0-9]*:[0-9]*)
- minor=${1#*:}
- major=${1%:*}
+ minor=$(echo ${1#*:} | sed -e 's/^0*//')
+ major=$(echo ${1%:*} | sed -e 's/^0*//')
I had wondered why you remove leading nulls, but now thanks
to your aboves desc I do not understand.
Now the trouble is the implementation, please use shell parameter
expansion. sed assumes busybox in the initramfs, which might not be
with the case with BUSYBOX=no for small initramfs or mem constraint
boxes. something like ${minor#0}, not sure if we need to account for more
then 2 prefixed zeroes, in this case shell guru's can give a hint.
I see. I wasn't aware of BUSYBOX=no. But looking at this again, I
think I actually want to take a different approach in order to
maintain the current semantics of setting root=X:Y.
In particular, if the user passes in a value that has a prefixed 0,
that will get passed directly to mknod, which would treat the number
as octal. So root=010:0 would actually create a device with major
number 8. Instead of trying to resolve this directly, we can use the
shell's arithmetic expansion to get a decimal number back.
;;
[A-Fa-f0-9]*)
value=$(( 0x${1} ))
@@ -377,8 +377,7 @@
;;
esac
- mknod -m 600 /dev/root b ${major} ${minor}
- ROOT=/dev/root
+ ROOT=/dev/block/${major}:${minor}
}
# Parameter: device node to check
this assumes udev running in initramfs for the symlink.
together with devtmpfs and force loading one can built one without,
but I agree that this may now be very special case.
I think that's reasonable to address. udev is only priority:
important, so it's not inconceivable to imagine initramfs's without
it. It's easy enough to check for it and fall back on the old behavior
if udev isn't there.
thank you for the feedback.
Thank you for yours. I appreciate the consideration of these edge
cases; I probably wouldn't have come up with them myself.
I've attached a new patch that incorporates your suggestions.
- Evan
udev-friendly-parse_numeric.diff
Description: Binary data
