Bug#457804: multipath-tools-boot gets started before module-init-tools, making modules useless
Hi Josip, On Fri, Dec 28, 2007 at 01:39:09AM +0100, Josip Rodin wrote: > There's S10checkroot.sh, but it should be safe to assume that if the system > has already booted from the root partition, multipath can't change it We must ensure the partition mappings (from kpartx) are already there but that's the case since udev is already running and the block device the rootfs resides on has been "discovered" by the initramfs already. > Strange thing is, checkroot.sh also activates the swap devices found in > /etc/fstab. I can't imagine a reason why someone would have the swap > partition(s) behind a device which requires multipath, though. That's a not an uncommon setup since you might be running without _any_ local disks. And if you swap over your SAN you certainly want to coalesce the paths but it seems swapon gets called with "-e" and we do another swapon in S35mountall so this should be save here too. > I don't think we should be missing anything, because I can't think of any > extra packages that should mess with the priority space this early (<20) > and yet need multipath. The closest are ocfs2-tools and cman, which > are at 60 in this runlevel (should be near 40, but that's another matter). Yes, I checked the cluster-manager already, they're quiet late in the game - not that we would have a working redhat-cluster manager at all in Lenny, let alone clvm - but that's a different story. [..snip..] > Well, supporting kernel modules isn't generally considered a special > requirement, they've been around since forever :) No, but so is initramfs and you can always have the "early boot modules" loaded by the initramfs, that's what /etc/initramfs-tools/modules is for. Anyways, it looks save enough to move the module-init-tools script to S21. Cheers, -- Guido signature.asc Description: Digital signature
Bug#457804: multipath-tools-boot gets started before module-init-tools, making modules useless
On Thu, Dec 27, 2007 at 09:59:15AM +0100, Guido Guenther wrote: > On Wed, Dec 26, 2007 at 10:34:35PM +0100, Josip Rodin wrote: > > I suppose, although that's a much more general change that would have many > > more consequences. How was the current priority for multipath-tools-boot > > selected, is there a rationale for it being as high as 3 (now 4)? > > I can't say I can see the reason offhand. I suppose you want it to be > > before S30checkfs.sh and S35mountall.sh so that people can put multipath'd > > drives into fstab, but why would it run as early as 3 or 4? > It was moved that early because it had to be started _before_ udev. > Basti was maintaining the package back then (0.4.5-2) and the changelog > doesn't give a reason why this was done. > > I moved it to start _after_ udev so the /dev/mapper entries get created > correctly on the tmpfs (0.4.7-3). > > We can probably move it even later in the boot process but not after LVM > cryptdisks and mdadm which would mean [21,24] if we also want to have it > after module-init tools. But there might very well be something earlier > that also wants access to block devices, who knows? There's S10checkroot.sh, but it should be safe to assume that if the system has already booted from the root partition, multipath can't change it anyway... right? Strange thing is, checkroot.sh also activates the swap devices found in /etc/fstab. I can't imagine a reason why someone would have the swap partition(s) behind a device which requires multipath, though. I don't think we should be missing anything, because I can't think of any extra packages that should mess with the priority space this early (<20) and yet need multipath. The closest are ocfs2-tools and cman, which are at 60 in this runlevel (should be near 40, but that's another matter). > 21 looks like a good choice but I wonder if we gain that much - you > could always load necessary modules with > > modprobe || treue > > in /etc/default/multipath-tools for your special requirements. In other > cases an initramfs makes much more sense. Well, supporting kernel modules isn't generally considered a special requirement, they've been around since forever :) /etc/modules is used for specifying which kernel modules should be loaded at system boot time, it doesn't make sense from a maintenance standpoint for multipath to require a separate module loading method. Another point is the fact that the script multipath-tools-boot runs modprobe dm-multipath by default. We are already allowing for the idea that the multipath functionality exists as a kernel module, so there's no point in not allowing the idea that whatever is behind the device mapper can also be a kernel module. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#457804: multipath-tools-boot gets started before module-init-tools, making modules useless
On Wed, Dec 26, 2007 at 10:34:35PM +0100, Josip Rodin wrote: > I suppose, although that's a much more general change that would have many > more consequences. How was the current priority for multipath-tools-boot > selected, is there a rationale for it being as high as 3 (now 4)? > I can't say I can see the reason offhand. I suppose you want it to be > before S30checkfs.sh and S35mountall.sh so that people can put multipath'd > drives into fstab, but why would it run as early as 3 or 4? It was moved that early because it had to be started _before_ udev. Basti was maintaining the package back then (0.4.5-2) and the changelog doesn't give a reason why this was done. I moved it to start _after_ udev so the /dev/mapper entries get created correctly on the tmpfs (0.4.7-3). We can probably move it even later in the boot process but not after LVM cryptdisks and mdadm which would mean [21,24] if we also want to have it after module-init tools. But there might very well be something earlier that also wants access to block devices, who knows? 21 looks like a good choice but I wonder if we gain that much - you could always load necessary modules with modprobe || treue in /etc/default/multipath-tools for your special requirements. In other cases an initramfs makes much more sense. Cheers, -- Guido signature.asc Description: Digital signature
Bug#457804: multipath-tools-boot gets started before module-init-tools, making modules useless
On Wed, Dec 26, 2007 at 05:17:44PM +0100, Guido Guenther wrote: > Hi Josip, > On Wed, Dec 26, 2007 at 01:11:18AM +0100, Josip Rodin wrote: > > S0(3|4)multipath-tools-boot needs to be moved to something like > > S21multipath-tools-boot, and after this, things work all right > > because /etc/modules loads qla2xxx and multipath runs fine. > Wouldn't it make more sense to move module-init-tools more to the front? > I can see other scripts with priorities <20 that might benefit from > that. I suppose, although that's a much more general change that would have many more consequences. How was the current priority for multipath-tools-boot selected, is there a rationale for it being as high as 3 (now 4)? I can't say I can see the reason offhand. I suppose you want it to be before S30checkfs.sh and S35mountall.sh so that people can put multipath'd drives into fstab, but why would it run as early as 3 or 4? -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#457804: multipath-tools-boot gets started before module-init-tools, making modules useless
Hi Josip, On Wed, Dec 26, 2007 at 01:11:18AM +0100, Josip Rodin wrote: > S0(3|4)multipath-tools-boot needs to be moved to something like > S21multipath-tools-boot, and after this, things work all right > because /etc/modules loads qla2xxx and multipath runs fine. Wouldn't it make more sense to move module-init-tools more to the front? I can see other scripts with priorities <20 that might benefit from that. The init scripts system (and Debian's missing dependency ordering in particular) sucks noodles when it comes to these kind of things. -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#457804: multipath-tools-boot gets started before module-init-tools, making modules useless
Package: multipath-tools Version: 0.4.7-1.1, 0.4.8-5 Hi, The package installs the multipath-tools-boot init script in the S runlevel at the position 03 (etch) or 04 (sid). However, module-init-tools is started at position 20 in the S runlevel, which means that the kernel modules which aren't detected by udev aren't yet loaded at the time multipath is run. In my specific situation, the necessary module is qla2xxx. I don't want to compile this module into the kernel, both because of an inherent opposition to in-kernel PCI card drivers, and because this module is replaceable by another one (HP's supported qla2300 driver), and because the module requires /lib/firmware/ql2300_fw.bin, which would mean I have to use an initrd. It would simply be an unnecessary complication to have to compile this rather than use a module. S0(3|4)multipath-tools-boot needs to be moved to something like S21multipath-tools-boot, and after this, things work all right because /etc/modules loads qla2xxx and multipath runs fine. Please fix this. TIA. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
