Bug#343042: [Yaird-devel] Bug#343042: #343042: linux-image-2.6.14-2-686: Boot aborts with message '/bin/cat
On Wed, Dec 14, 2005 at 10:42:58AM +, Richard Antony Burton wrote: Package: yaird Version: 0.0.12-1 Followup-For: Bug #343042 FYI the above workaround does not work for machines with SATA drives. I couldn't find a combination of modules that would get it to boot. Switching back to previous yaird (0.0.11-12) fixes the problem on both PATA SATA systems. Hmm, you're the first to report problems with SATA, and considering what was changed between 0.0.11 and 0.0.12, I would not expect any problems in this area. To help debugging, could you post your version of /etc/yaird/Default.cfg, plus the output of yaird -v for the working version and the broken version? Thanks, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343048: linux-image-2.6.14-2-686: ide fails to initialize (patch results, amended)
On Tue, Dec 13, 2005 at 12:48:41PM -0200, Paulo Marcel Coelho Aragao wrote: Paulo Marcel Coelho Aragao wrote on Dec, 13: http://arch.debian.org/arch/yaird/[EMAIL PROTECTED]/yaird/yaird--devo/yaird--devo--0.1/patch-131/ Could you give it a try and let me know if it actually works? Bingo ! Flawless boot: all IDE devices recognized. In haste, I didn't notice: DMA is turned off for all IDE devices. I followed the workaround suggested in another thread: explicitly include pixx in Default.cfg. That's odd. The patch is designed to load piix before ide-generic, so that you get working DMA. Perhaps in your test you did not remove 'MODULE ide-generic' from your /etc/yaird/Default.cfg, so that it gets loaded too early? If that's not the case, could you post your config files plus the output of yaird -d, so that I can debug further? Thanks, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343048: linux-image-2.6.14-2-k7: same proble, kernel fails to load ide drive.. in my case the drive is under /sys/block/hdb/dev
On Tue, Dec 13, 2005 at 01:44:34PM -0500, Scott James Williamson wrote: FYI: if you use a nvidia nforce 2 based motherboard, to get DMA on your drives, add the following MODULE amd74xx after evdev and before ide-generic to the /etc/yaird/Default.cfg file: MODULE evdev MODULE amd74xx MODULE ide-generic MODULE ide-disk Thanks, this is new information. There have been piix users that report non-boot and no DMA with the latest yaird version, but you are the first to report this for an amd74xx motherboard. Just to avoid misunderstandings: did you add the ide-generic to repair a non-booting system, or just by way of prevention? If the amd74xx also fails to boot without ide-generic, I'll need to prepare a modified yaird patch. Regards, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343048: linux-image-2.6.14-2-686: ide fails to initialize, additional information
On Mon, Dec 12, 2005 at 08:47:30PM +0200, Aapo Rista wrote:
On Mon, 12 Dec 2005, Erik van Konijnenburg wrote:
To help pin down the cause, could you post the output of:
yaird -v -o crap.img 2.6.14-4-686
yaird -v -o crap.img 2.6.14-5-686
(assuming these are the last kernel that boots and the first that works)
yaird: goal: mountdir, / (/etc/yaird/Default.cfg:143)
yaird: action: insmod,
/lib/modules/2.6.14-1-686/kernel/drivers/ide/ide-core.ko {optionList=-- }
yaird: action: insmod,
/lib/modules/2.6.14-1-686/kernel/drivers/ide/pci/piix.ko {optionList=-- }
yaird: action: insmod,
/lib/modules/2.6.14-1-686/kernel/drivers/ide/pci/generic.ko {optionList=-- }
yaird: action: insmod,
/lib/modules/2.6.14-1-686/kernel/drivers/ide/ide-disk.ko {optionList=-- }
yaird: hardware: completed pci:00/:00:1f.1/ide0/0.0
Hi Aapo, Cesare,
Thanks for your feedback. There's a patch at the following location:
http://arch.debian.org/arch/yaird/[EMAIL
PROTECTED]/yaird/yaird--devo/yaird--devo--0.1/patch-131/
This should add ide-generic if you have piix controller without the need
to add it explicitly in the /etc/yaird/Default.cfg file.
Could you give it a try and let me know if it actually works?
Thanks,
Erik
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343048: linux-image-2.6.14-2-686: ide fails to initialize (applying the patch)
On Mon, Dec 12, 2005 at 09:18:01PM -0200, Paulo Marcel Coelho Aragao wrote: Erik van Konijnenburg wrote on Dec, 12: http://arch.debian.org/arch/yaird/[EMAIL PROTECTED]/yaird/yaird--devo/yaird--devo--0.1/patch-131/ Could you give it a try and let me know if it actually works? Apologies for the more than basic question: how do I apply the patch ? None needed, my description was rather cryptic ... Step by step: ** Decide if you want to go ahead with this test. Only try this if you know how to recover from a non-booting kernel ( if I'm correct you've just done that) ** Save the attached patch. ** Make backup: $ cp /usr/lib/yaird/perl/Hardware.pm just-in-case.pm ** Apply patch: $ sudo patch /usr/lib/yaird/perl/Hardware.pm /dat/tmp/Hardware.pm.patch patching file /usr/lib/yaird/perl/Hardware.pm Hunk #1 succeeded at 216 (offset -18 lines). $ (the offset is a normal warning in this case) ** Comment out any work-arounds (MODULE ide-generic) you may have made in /etc/yaird/Default.cfg This is an important bit: you would not want to report success with the patch if actually your edit in Default.cfg is what makes the system boot. ** Use the patched version to make a new initrd.img. A quick way to do this is $ sudo apt-get install linux-image-2.6.14-2-686-smp but only if you don't actually have an SMP system. This should leave your normal single-cpu kernel in place and install an smp kernel, with new initrd.img, next to it. ** reboot into new kernel; report success; undo if you don't like the effect. Regards, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343048: linux-image-2.6.14-2-686: ide fails to initialize (applying the patch)
On Tue, Dec 13, 2005 at 07:23:41AM +0100, Erik van Konijnenburg wrote:
**Save the attached patch.
Oops, patch attached for real now.
--- orig/perl/Hardware.pm
+++ mod/perl/Hardware.pm
@@ -234,7 +234,10 @@
# The above error persists in 2.6.12, and is solved
# in 2.6.14.
#
+ # Similar error seems to exist in 2.6.14 for piix.
+ #
$result = [ map { $_ eq via82cxxx ? ($_, ide-generic) : $_ }
@{$result} ];
+ $result = [ map { $_ eq piix ? ($_, ide-generic) : $_ } @{$result}
];
return $result;
}
Bug#343042: linux-image-2.6.14-2-686: Boot aborts with message '/bin/cat: /sys/block/hda/hda1/dev: No such file or directory'
On Mon, Dec 12, 2005 at 12:34:11AM -0200, Paulo Marcel Coelho Aragao wrote: Package: linux-image-2.6.14-2-686 Version: 2.6.14-5 Severity: critical Justification: breaks the whole system Right after I upgraded linux-image-2.6.14-2-686 to 2.6.14-5 and rebooted, boot is interrupted with repeated messages: /bin/cat: /sys/block/hda/hda1/dev: No such file or directory until it finally stops completely, with message: Device /sys/block/hda/hda1/dev seems to be down I'm having to reboot with 2.6.12. To help pin down the cause, could you post the output of: uname -a dpkg -l yaird yaird -v -o crap.img 2.6.14-2-686 yaird -v -o crap.img 2.6.14-5-686 (assuming these are the last kernel that boots and the first that works) Thanks, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343042: [Yaird-devel] Bug#343042: linux-image-2.6.14-2-686: Boot aborts with message '/bin/cat: /sys/block/hda/hda1/dev: No such file or directory'
On Mon, Dec 12, 2005 at 04:33:29AM +0100, Cesare Leonardi wrote: Paulo Marcel Coelho Aragao wrote: Package: linux-image-2.6.14-2-686 Version: 2.6.14-5 Severity: critical Justification: breaks the whole system Right after I upgraded linux-image-2.6.14-2-686 to 2.6.14-5 and rebooted, boot is interrupted with repeated messages: /bin/cat: /sys/block/hda/hda1/dev: No such file or directory until it finally stops completely, with message: Device /sys/block/hda/hda1/dev seems to be down I'm having to reboot with 2.6.12. This happened to me too. I followed more or less the same steps as Paulo: - upgrade linux-image-2.6.14-2-686 from 2.6.14-4 to 2.6.14.5; - fail to reboot with the error messages above that appears 4 times with increasing delay, saying: Waiting X second for /sys/block/hda/dev to show up; - reboot with kernel 2.4.27 then download and install linux-image-2.6.12-1-686 to have a system fully functional. To help pin down the cause, could you post the output of: uname -a dpkg -l yaird yaird -v -o crap.img 2.6.14-2-686 yaird -v -o crap.img 2.6.14-5-686 (assuming these are the last kernel that boots and the first that works) Thanks, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343048: linux-image-2.6.14-2-686: ide fails to initialize, additional information
On Mon, Dec 12, 2005 at 08:07:21AM +0200, Aapo Rista wrote: Package: linux-image-2.6.14-2-686 Version: 2.6.14-5 Followup-For: Bug #343048 After upgrading linux-image-2.6.14-2-686 from 2.6.14-4 to 2.6.14-5, IBM Thinkpad X40 fails to boot. Last lines before the end of initializing process are here: To help pin down the cause, could you post the output of: uname -a dpkg -l yaird yaird -v -o crap.img 2.6.14-4-686 yaird -v -o crap.img 2.6.14-5-686 (assuming these are the last kernel that boots and the first that works) Thanks, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337479: yaird: should use /usr/bin/perl, not /usr/local/bin/perl
On Wed, Nov 09, 2005 at 08:16:08PM +0100, Laurent Bonnaud wrote: On sam, 2005-11-05 at 16:31 +0100, Mattia Dongili wrote: and you probably have /usr/local/bin before /usr/bin in your path Yes as on all unmodified Debian systems. I'd say this is a problem in the submitter's build host. Having a /usr/local/bin/perl symlink is very useful to run many perl scripts without having to modify them. I's like configuring a package with silly ./configure options and pretending it works everywhere. :) I did not intervene in the build process. I used this command: apt-get -b source yaird With this command I expect to get a working package as long as I do not mess up the system. And putting files in /usr/local/ is clearly allowed and does not count as messing up the system. I'm not sure whether you're supposed to do that. However, yaird uses an extremely boring GNU autoconf and Debian CDBS setup, the build is as standard as it can be made, so the behaviour described here is not specific to yaird, and a patch (if this is indeed a bug) should not be part of the yaird build rules file, but of the underlying infrastructure. Perhaps it's possible to reset $PATH to some standard value without /usr/local in the dpkg build utility, but I'm uncertain about possible side effects. Could you reassign this report to the package dpkg-dev? Regards, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336598: cannot parse /etc/fstab file with SMB share
On Mon, Oct 31, 2005 at 06:19:56PM +0100, Mattia Dongili wrote: merge 336585 336598 thanks On Mon, Oct 31, 2005 at 12:45:25PM +, Martin Michlmayr wrote: Package: yaird Version: 0.0.11-10 Severity: grave yaird fails when /etc/fstab contains a SMB share, such as: \\mlpc-serv-fs1.eng.cam.ac.uk\homes /srv/mlpc-serv-fs1 smbfs noauto,user,uid=tbm,gid=tbm,credentials=/etc/samba/private/msm34 this is actually the same as #336585: The fs_freq and fs_passno fields in /etc/fstab are optional Just tested with the patch for 336585: agreed. No odd interference from the octal escape unmangling found. --erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333858: initrd/initramfs: we discussed enough, let's take some action now :)
On Sat, Oct 15, 2005 at 06:15:04PM +0200, Jonas Smedegaard wrote: On Sat, 15 Oct 2005 16:34:57 +0200 Erik van Konijnenburg [EMAIL PROTECTED] wrote: On Sat, Oct 15, 2005 at 08:57:31AM +0200, Sven Luther wrote: On Sat, Oct 15, 2005 at 08:47:57AM +0200, Erik van Konijnenburg wrote: On Fri, Oct 14, 2005 at 12:53:41PM +0200, Jonas Smedegaard wrote: I believe -n means nonzero string (not null string), and the oppposite of -z (not a geeky variation of -z). At least that's the explanation in the manpage of test in Debian sid currently. You're right of course, but note how plausible the -n lie was; With [ $aap = ] notation, you don't have to think about -n vs -z... With a bit of hand-waving, there are two broad approaches: * require the user to upgrade to 2.6 *somehow* before upgrading to yaird * extend yaird with a universal-boot mode. The first option is really a ignore the issue and hope someone else deals with it. One of the reasons I find yaird interesting is exactly that it is an alternative. If a problem shows with a kernel, you can try installing a different kernel to see if the problem goes away. Similarly if a ramdisk-generator lacks a feature you can switch to an alternative generator that handles this particular feature. As Jeff explained earlier, initramfs-tools aims to being stupid[1] and just provide a framework for other packages to hook script snippets onto. Yaird seems to aim at being smart and contain enough intelligence itself about all features it wants to support. I would really like to have the choice of both approaches, also for less common tasks like switching from 2.4 or preparing an alien bootup (either for different hardware or for diskless clients). Good argument for separate implementations, but note that for the universal boot image, both mkinitramfs and yaird need to come up with an initscript that does udev and then mdadm, lvm and what have you. For this use case, the only difference is whether the cpio file is written by a perl script or by a shell script; all the intelligence is at boot time, not at build time. This makes the difference between the two approaches too small to be of much interest to Debian. For yaird, on the other hand, adding an udev-based template would make it a much more complete package. Oh, and btw, Erik: Please have a look at http://wiki.debian.org/InitrdReplacementOptions and consider improving it. :-) Good overview; I added some datapoints to it. Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#301560: Bug#273182: a possible fix/workaround
On Sun, May 22, 2005 at 02:58:04AM -0700, Steve Langasek wrote: On Sat, May 21, 2005 at 07:17:21PM +0200, Erik van Konijnenburg wrote: Mdadm is of course perfectly capable of creating it's own /dev/md0, provided auto=md is given for the relevant device in /etc/mdadm/mdadm.conf. Which doesn't help the fact that mdadm -A -s --auto doesn't work, since the whole point of mdadm -A -s is to make this work without needing to populate mdadm.conf... Hmm, we could have a nice long discussion here about whether the unpatched behaviour is actually broken or whether it just needs some more explaining to the user community, but it's clear that changing the behaviour will ease migration towards sarge. More importantly: do we want the MAKEDEV behaviour or the proposed patch? For the long term, I would prefer the patch since it is more precise in what devices are generated. However, if an unconditional MAKEDEV speeds up sarge, I'd say go for it. Regards, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#294404: Bug#273182: a possible fix/workaround
On Sun, May 22, 2005 at 12:06:27PM +0200, Marco d'Itri wrote: On May 22, martin f krafft [EMAIL PROTECTED] wrote: Erik said that if initrd brings up /dev/md0, partitions from other software RAID devices (e.g. /dev/md7) cannot be brought up since the above code skips the MAKEDEV call in the case of presence of /dev/md0. I do not know how the initrd work, but does it actually do this? Quoting Maks from #304483: I can't try this right now but I doubt this would help. The reason is that when the system boots initrd would not know how to assemble /dev/md1 because .../initrimg/script does not contain mdadm -A record for /dev/md1. This is the root of the problem. no it is not! initrd-tools enables the root partition for the pivot_root, and if existing the swap partition, everything else need to be done by mdadm init scripts. I guess that means it actually does this; this matches with what the code says. For what it's worth, I think that's proper behaviour for mkinitrd. 1 check for another device node, e.g. /dev/md5 and hope that the initrd only ever configures /dev/md0 I think that this is the best solution. If the initrd only activates the / array then you can check for md1 and md/1. Users can dedicate any partition to swap, and it will be activated by initrd. In 304483, user has md2 and md3 as root and swap, these are activated, md1 is /boot and remains inactive. If you have to pick just one device, use /dev/md15. That's generated by MAKEDEV but not terribly likely to be in use. Regards, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#301560: Bug#273182: a possible fix/workaround
On Sat, May 21, 2005 at 07:29:55PM +0200, martin f krafft wrote: also sprach Erik van Konijnenburg [EMAIL PROTECTED] [2005.05.21.1917 +0200]: - echo Starting raid devices: + if [ -d /dev/.udevdb -a ! -e /dev/md0 -a ! -e /dev/md/0 ]; then +echo -n Creating raid device nodes: +cd /dev WRITE_ON_UDEV=1 ./MAKEDEV md +echo done. + fi + echo -n Starting raid devices: I suspect this will not work if /dev/md0 is activated by the initrd, and the user wants to mount /dev/md7 which is not touched by initrd. At the moment, I can't test suspicion, so please feel free to ignore the following ramblings if testers are happy. What makes you suspicious? Whether the initrd has created device nodes or not, the above should just create all the missing ones for minors 0 through 15. What happens is the following: * initrd creates devices needed for boot: root and swap, /boot is omitted. * these devices become visible in sysfs * after pivotroot, udevstart walks /sys at S04, and feeds /sys/block/md0 to udev; udev creates /dev/md0. * at S40 or so, you come along, see that /dev/md0 exists, and decide not to do MAKEDEV * now we don't have /dev/md7, and mdadm fails. * (unless you're an LVM user, but that's another story) The attached patch changes this, so that --auto works regardless of command line settings, like so: This is of course a much nicer solution. I am indifferent as to which one is preferable, given the closeness to the release. Understood. I'm not a Debian maintainer, so none of the release pressure is on me; if you don't have room to work on this option, the alternative is fine with me. This patch is intended as a fallback in case your earlier upload does not make it through testing. As a worst case scenario, you can degrade the bug to wishlist and claim that users should do the auto thing in the config file. I do want to note that your patch could be improved further, but we need some discussion about how to do this: - mdfd = open_mddev(devlist-devname, array_ident-autof); + mdfd = open_mddev(devlist-devname, (autof ? autof : array_ident-autof)); so if auto=mdp appears in the config, and --auto=md is passed, which one should take priority? Right now, the command line option does so. Isn't --auto=yes intended to enable this but read the actual setting from the configuration file? I am not sure that your patch still allows this. You're right that we should look at this, for now that's completely untested in this patch. I'll dive in and see if I can find out what's supposed to happen. Regards, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#294404: Bug#273182: a possible fix/workaround
On Sat, May 21, 2005 at 08:58:46PM +0200, martin f krafft wrote: (taking unrelated bugs out of the loop.) also sprach Erik van Konijnenburg [EMAIL PROTECTED] [2005.05.21.1957 +0200]: * at S40 or so, you come along, see that /dev/md0 exists, and decide not to do MAKEDEV No, I come along at S25 and I do not give a flying food for whether /dev/md0 exists or not. I just create all /dev/md* nodes, regardless of whether some or all already exist, iff udev is being used. Quoting from the patch you mailed earlier today: + if [ -d /dev/.udevdb -a ! -e /dev/md0 -a ! -e /dev/md/0 ]; then +echo -n Creating raid device nodes: +cd /dev WRITE_ON_UDEV=1 ./MAKEDEV md +echo done. + fi + echo -n Starting raid devices: that looks like you're skipping MAKEDEV is /dev/md0 exists, but my bash is a bit rusty, so correct me if I'm wrong. Understood. I'm not a Debian maintainer, so none of the release pressure is on me; if you don't have room to work on this option, the alternative is fine with me. This patch is intended as a fallback in case your earlier upload does not make it through testing. It's intended to make it through testing. sarge will not release without mdadm, or when mdadm has an RC bug. As a worst case scenario, you can degrade the bug to wishlist and claim that users should do the auto thing in the config file. No, that's not an option. This is Debian, after all. :) bugs.debian.org: it's RC if the maintainer says so, or if it renders the system unusable. Since there is a workaround (just do the documented thing in the config file), you have the option of changing your mind about this being RC, should that become necessary. Perhaps we should move this issue to debian-legal :-) Isn't --auto=yes intended to enable this but read the actual setting from the configuration file? I am not sure that your patch still allows this. You're right that we should look at this, for now that's completely untested in this patch. I'll dive in and see if I can find out what's supposed to happen. Thanks! I think it would be best if you could file a new (wishlist) bug against mdadm and attach the patch to that, so that we can treat the two as separate issues. OK. BTW, you were correct in suspecting the auto=mdp interaction is not optimal; I'll make it a wishlist report after testing. Regards, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#294404: Bug#273182: a possible fix/workaround
The reworked patch is in wishlist #310126, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=310126 Regards, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#288150: multipath-tools: initrd script breaks booting lvm root
Package: multipath-tools
Version: 0.4.1-1
Severity: critical
Justification: breaks the whole system
Tags: patch
If multipath-tools-0.4.1-1 is installed, the initrd generated by
initrd-tools-0.1.76 is non-bootable for systems using an LVM
root device.
Symptoms: pivot_root: no such file or directory; sbin/init not found;
panic: attempting to kill init.
The cause: multipath adds a script /etc/mkinitrd/scripts/01_udev; this
mounts a new /dev and lets udevstart run on it. This happens after
/script is executed, which is where the LVM command vgchange -a y vg0
is executed to create LVM devices. Unfortunately, udevstart has no way
of creating the /dev/mapper nodes required by LVM, so the root device
/dev/mapper/vg0 stays missing.
One possible fix would be not to mount an empty /dev in 01_udev, so that
the LVM devices remain visible. However, mounting a new /dev protects
against a possible read-only prior /dev, and the prior /dev is indeed
read-only. (it is part of the initrd image and contains some symlinks
to ../devfs)
So the attached patch instead copies the contents of the old /dev to the
new /dev. It's possible that a similar problem would occur for other
virtual devices such as MD; these too are not created by hotplugging
but by an init.d script. I have not tested this, but the patch should
cover such cases.
The patch was tested on a PC with LVM devices on a SATA disk but no
actual multipath devices: I only installed multipath-tools to take a
look at the documentation ...
I'm including #288150 (initrd no longer works unless busybox is
installed) on the Cc list. That report mentions /bin/sleep missing
from initrd image. The missing sleep is still missing after attached
patch, but it does not seem to harm anything. No claim that this
patchs solves #288150, but the symptoms seem similar enough to justify
a cross reference.
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-1-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Versions of packages multipath-tools depends on:
ii debconf [debconf-2.0]1.4.41 Debian configuration management sy
ii hotplug 0.0.20040329-16 Linux Hotplug Scripts
ii initscripts 2.86.ds1-1 Standard scripts needed for bootin
ii libc62.3.2.ds1-20GNU C Library: Shared libraries an
ii libdevmapper1.00 2:1.00.20-1 The Linux Kernel Device Mapper use
ii libsysfs11.1.0-1 Interface library to sysfs
ii makedev 2.3.1-75Creates device files in /dev
ii udev 0.050-4 /dev/ management daemon
-- no debconf information
--- 01_udev.org 2005-01-12 10:57:58.0 +0100
+++ 01_udev.works 2005-01-12 22:51:22.0 +0100
@@ -4,8 +4,9 @@
cp /sbin/udevstart $INITRDDIR/sbin/
cp /bin/mountpoint $INITRDDIR/bin/
cp /bin/readlink $INITRDDIR/bin/
+cp /bin/cp $INITRDDIR/bin/
-PROGS=/sbin/udev /sbin/udevstart /bin/mountpoint /bin/readlink
+PROGS=/sbin/udev /sbin/udevstart /bin/mountpoint /bin/readlink /bin/cp
LIBS=`ldd $PROGS | grep -v linux-gate.so | sort -u | \
awk '{print $3}'`
for i in $LIBS
@@ -33,10 +34,15 @@
cat EOF | $INITRDDIR/scripts/10_udev.sh
cd /
+mount -n --bind /dev /mnt
mount -nt proc proc proc
mount -nt sysfs sysfs sys
mount -nt tmpfs tmpfs dev || mount -nt ramfs ramfs dev
mount -nt tmpfs tmpfs tmp || mount -nt ramfs ramfs tmp
+# preserve old /dev contents, since udev does not make
+# eg LVM nodes.
+cp -a /mnt/* /dev
+umount -n /mnt
#modprobe dm-mod
#modprobe dm-multipath
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
