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#329319: yaird: swsusp not all that hard
On Fri, Dec 09, 2005 at 11:12:05AM -0500, C. Scott Ananian wrote: Package: yaird Version: 0.0.11-12 Followup-For: Bug #329319 It's not all that hard to prevent log replay: just don't mount the file systems! Resume should happen *after* the modules required to access the swap partition are installed (ide, piix, etc), but *before* the root partition is mounted. Mounting read-only is bad, too, because that causes journal replay. Just load the modules and transfer to the resume code, which will take care of the rest. The more interesting question is: how do I tell which partition I need to resume from? yaird needs to know this so that it can make sure the right modules are loaded (otherwise resume will complain device not found). swsusp uses resume=/dev/hda# and suspend2 uses resume2=swap:/dev/hda# on the command-line, but it would really be preferable to use a mount option in /etc/fstab instead. After all, yaird is good at figuring out things like that; grub/lilo are not. For standard swsusp, cat /sys/block/hda/hda5/dev /sys/power/resume (for example) at initramfs-time will both initialize the 'resume=' option (avoiding the need for a command-line argument) and also perform the resume if appropriate. I don't know if suspend2 has a similar mechanism. So it should be pretty straight-forward for yaird to: 1) look in /etc/fstab for a swap partition with the 'resume' option. 2) add a target just before filesystem mount (MKSWAP or some such) which loads the modules needed to access that partition 3) if there isn't a noresume or noresume2 option on the command-line, performs the swsusp or suspend2-appropriate resume action. (or both, since only one or the other will actually work). Everything else should be handled by the resume. --scott Hi, Just a quick thank-you note for your input patch; your stuff really helps in getting a clear picture of what we need here. The issue of where to resume from is indeed the most important for end-users; your idea of using a 'resume' option is interesting, but I'm not yet sure it's what we want. Two points to consider: * what do other tools do? We would not want people that convert to or from initrd-tools or mkinitramfs to have to change their grub of fstab configuration to keep their swsusp working. Only be incompatible if it can't be avoided. Ideally, avoid incompatibility even among distros. * Could we avoid configuration altogether? We could simply always do the resume code for all swap devices, if swsusp or swsusp2 is enabled in the kernel config. If the distro has swsusp in the kernel, this would mean users could start using swsusp without having to regenerate the initramfs; downside is they would have to edit the grub/lilo menu. Attached some notes on swsusp I made earlier; untested so far. I've started testing dmraid, and have only a limited supply of boxes to play with (and limited time to play in ...) so it will be a while before I can test the swsusp. Regards, Erik Sat Oct 22 18:22:51 CEST 2005 Supporting Software Suspend Linux comes with a feature that makes it possible to suspend operations: write all RAM that is in use to swap device and then shutdown; then on booting to read the RAM back from the swap device. The nett result is that after reboot the system is back in the state where it was just before the shutdown, including all running processes and everything on screen: you can resume work immediately. The nice thing is that you can use a deamon, acpid, to watch the system and issue the suspend command automatically if the machine has been idle for a few minutes. Swsusp is implemented in the context of power management: depending on how long the system has been idle, you may want to bring devices to a less active state, with reduced noise and reduced power consumption. Blanking the screen is a possibility at one end of the spectrum, saving the whole system to disk is at the other end. Power management needs kernel support, in part to be informed when the system has been idle for a while, but also to negotiate with peripherals to what extent they can cut down on their power consumption. There are issues of course: some device drivers don't know how to hold still while the system is being suspended, and network connections can be interrupted if you save yourself to disk and just stop talking for a while. There is a 'hibernate' package which manages this by having a configuration directory where packages can place scripts that need to be invoked just before or after a suspend, and by have a list of modules that need to be unloaded before suspending. There used to be three different implementations of this idea, but currently (2.6.14-rc4) two of these have been merged into mainline as 'swsusp'. There are indications that 'swsusp2', an out-of-mainline implementation, will also be merged back in. www.suspend2.net But note that a new and different approach is in
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#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#342905: [Yaird-devel] Bug#342905: yaird: barfs when dpkg tries to recover after earlier failure
On Sun, Dec 11, 2005 at 05:12:28PM +0100, Frans Pop wrote: When configuration of a package fails, dpkg in some cases tries to recover by running the postinst scripts again. For yaird this resulted in the following error: yaird error: destination /boot/initrd.img-2.6.14-2-sparc64.new already exists (fatal) This probably also indicates that yaird fails to clean up after itself when it fails. Thanks, fixed in: http://arch.debian.org/arch/yaird/[EMAIL PROTECTED]/yaird/yaird--devo/yaird--devo--0.1/patch-127/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342904: [Yaird-devel] Bug#342904: yaird: Error creating initrd on Sparc64
On Sun, Dec 11, 2005 at 06:54:02PM +0100, Frans Pop wrote: On Sunday 11 December 2005 17:12, Frans Pop wrote: During installation of linux-image-2.6.14-2-sparc64 (2.6.14-5), yaird failed with the following error: yaird error: unrecognised legacy device: /sys/devices/serio1 Additional info: I also had 2.6.14-4 installed and experienced no problems installing that version using yaird. There's a lot of cleaning up going on in the input layer, this is quite likely some fallout from that. Anyway, could you test the workaround provided at following location? http://arch.debian.org/arch/yaird/[EMAIL PROTECTED]/yaird/yaird--devo/yaird--devo--0.1/patch-129/ Thanks, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342904: [Yaird-devel] Bug#342904: yaird: Error creating initrd on Sparc64
On Sun, Dec 11, 2005 at 08:11:57PM +0100, Frans Pop wrote: On Sunday 11 December 2005 19:57, Erik van Konijnenburg wrote: http://arch.debian.org/arch/yaird/[EMAIL PROTECTED]/yaird/yaird --devo/yaird--devo--0.1/patch-129/ Thanks for the quick reaction. With the patch applied, I get the following result. $ sudo dpkg-reconfigure linux-image-2.6.14-2-sparc64 Running depmod. Finding valid ramdisk creators. Using mkinitrd.yaird to build the ramdisk. yaird warning: unrecognised legacy device: /sys/devices/serio1; trying sunkbd yaird error: Could not read output for /sbin/modprobe -v -n --show-depends --set-version 2.6.14-2-sparc64 sunkbd (fatal) Failed to create initrd image. Hoi Frans, Sounds like a driver that is compiled into the kernel; the following patch makes the relevant defines known to yaird; note that it only applies if you also have all earlier patches over 0.0.12. Regards, Erik http://arch.debian.org/arch/yaird/[EMAIL PROTECTED]/yaird/yaird--devo/yaird--devo--0.1/patch-130 The core of the patch: --- orig/perl/KConfig.pm +++ mod/perl/KConfig.pm @@ -104,9 +104,11 @@ i8042 = [ 'SERIO_I8042' ], usbhid = [ 'USB_HID' ], atkbd = [ 'KEYBOARD_ATKBD' ], + sunkbd = [ 'KEYBOARD_SUNKBD' ], mousedev = [ 'INPUT_MOUSEDEV' ], evdev = [ 'INPUT_EVDEV' ], psmouse = [ 'MOUSE_PS2' ], + sermouse = [ 'MOUSE_SERIAL' ], # file systems ext2 = [ 'EXT2_FS' ], -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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#342652: yaird missed support for CRYPTO_AES_586 and CRYPTO_AES_X86_64
On Fri, Dec 09, 2005 at 12:05:10PM +0100, Stefan Schmidt wrote: Since kernel version 2.6.8 there are also config option CRYPTO_AES_586. With version 2.6.13 CRYPTO_AES_X86_64 was added. So it would be good to add support also to perl/KConfig.pm Otherwise you have a problem with compiled in support for CRYPTO_AES_586 and a yaird dm-crypt setup. Good idea, this is now included in the development version here: http://arch.debian.org/arch/yaird/[EMAIL PROTECTED]/yaird/yaird--devo/yaird--devo--0.1/patch-126/ Thanks, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341273: Doesn't understand install and remove directives in modprobe.conf
On Thu, Dec 08, 2005 at 04:42:51PM -0500, Norbert Veber wrote: On Sat, Dec 03, 2005 at 07:46:34PM +0100, Erik van Konijnenburg wrote: The reason is that install lines in the modprobe configuration are complete shell scripts: they can invoke every executable, access every file. Oh I see. How does the old mkinitrd handle this? Ignore the install lines and hope for the best. quoting mkinitrd: sed -n 's%^insmod \([^ ]\+\).*%\1%p' --erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341738: linux-image-2.6.14-2-686: Could not read output for /sbin/modprobe -v -n --show-depends --set-version 2.6.14-2-686 auto (fatal)
On Tue, Dec 06, 2005 at 02:28:01PM +0200, Jari Aalto wrote:
Following my other posts: Here is install report from another machine,
with exactly the same results. I've tried to reproduce as much debug
as I know. Let me know how can I help more.
Thanks, very clear report.
/dev/hda7 / ext3,autodefaults,errors=remount-ro,noat\
Bingo! We know about lists of file system types, we know about the 'auto'
file system type, but you're the first to actually test the combination of
the two.
Could you try the attached patch? Note that the patch is relative to
development;
there's an offset when applying to the debian version.
Regards,
Erik
=== modified file 'perl/Plan.pm'
--- perl/Plan.pm
+++ perl/Plan.pm
@@ -614,41 +614,43 @@
addDevicePlan ($actions, $abd, []);
+ #
+ # Do the file system type. This may be a list of types, to be tried
+ # in turn, and the list can contain 'auto': look at the block device
+ # to determine type.
+ #
my $fsType = $root-type;
-
- if ($fsType eq auto) {
- #
- # Let's guess the fstype using /sbin/blkid.
- #
- my ($rc, $guess) = Base::runCmd (missingOk = 1,
- cmd = ['/sbin/blkid', $rootDevName]);
- if (!defined ($guess)) {
- my $origin = $root-origin;
- Base::fatal (the command /sbin/blkid is not found, so
file system type 'auto' for '$rootDevName' is not supported; use an explicit
file system type ($origin));
- }
- if (@{$guess} != 1) {
- my $origin = $root-origin;
- Base::fatal (the command /sbin/blkid $rootDevName did
not give exactly one line of output, so file system type 'auto' for
'$rootDevName' is not supported; use an explicit file system type ($origin));
- }
-
- if (${$guess}[0] !~ /\sTYPE=([a-zA-Z0-9]+)/) {
- my $origin = $root-origin;
- Base::fatal (the command /sbin/blkid $rootDevName did
not have TYPE=\fstype\ in the output, so file system type 'auto' for
'$rootDevName' is not supported; use an explicit file system type ($origin));
- }
- $fsType = $1;
- Base::debug (blkid $rootDevName = $fsType);
- }
-
- #
- # Actually, fsType may be a comma-separated list of types,
- # to be tried in turn
- #
my @types = grep {$_ ne ''} split (',', $fsType);
if (@types == 0) {
my $origin = $root-origin;
Base::fatal (no file system type given for '$rootDevName'; use
an explicit file system type ($origin));
}
- ModProbe::addModules ($actions, [ @types ]);
+
+ for my $type (@types) {
+ if ($type eq auto) {
+ #
+ # Let's guess the fstype using /sbin/blkid.
+ #
+ my ($rc, $guess) = Base::runCmd (missingOk = 1,
+ cmd = ['/sbin/blkid', $rootDevName]);
+ if (!defined ($guess)) {
+ my $origin = $root-origin;
+ Base::fatal (the command /sbin/blkid is not
found, so file system type 'auto' for '$rootDevName' is not supported; use an
explicit file system type ($origin));
+ }
+ if (@{$guess} != 1) {
+ my $origin = $root-origin;
+ Base::fatal (the command /sbin/blkid
$rootDevName did not give exactly one line of output, so file system type
'auto' for '$rootDevName' is not supported; use an explicit file system type
($origin));
+ }
+ if (${$guess}[0] !~ /\sTYPE=([a-zA-Z0-9]+)/) {
+ my $origin = $root-origin;
+ Base::fatal (the command /sbin/blkid
$rootDevName did not have TYPE=\fstype\ in the output, so file system type
'auto' for '$rootDevName' is not supported; use an explicit file system type
($origin));
+ }
+ $type = $1;
+ Base::debug (blkid $rootDevName = $fsType);
+ }
+
+ ModProbe::addModules ($actions, [ $type ]);
+ }
my $yspecial = $abd-yspecial();
my $opts = $root-opts-cmdLineVersion();
Bug#341738: linux-image-2.6.14-2-686: Could not read output for /sbin/modprobe -v -n --show-depends --set-version 2.6.14-2-686 auto (fatal)
On Sun, Dec 04, 2005 at 10:38:37AM +0200, Jari Aalto wrote: Erik van Konijnenburg [EMAIL PROTECTED] writes: | -- hack /usr/sbin/mkinitrd.yaird to echo the yaird command line | and its own arguments to some scratch file, then do | dpkg-reconfigure linux-image-2.6.14-2-686 | and see if there's a difference from the yaird call you did | just now. Hm. That worked? [4] Hope the logs help to solve this. If you need more information, I can try more tests. Looks like the bug silently went away: if I understand your mail correctly, when you dpkg-reconfigure a kernel, you get a new /boot/initrd.img and you have the sh -x output to prove it. Lets close this bug report. Just to be safe, you may want to keep the 'set -x' in your mkinitrd.yaird: that way you can show detailed debug info if the issue should reappear. Regards, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341738: linux-image-2.6.14-2-686: Could not read output for /sbin/modprobe -v -n --show-depends --set-version 2.6.14-2-686 auto (fatal)
On Sat, Dec 03, 2005 at 10:18:53AM +0200, Jari Aalto wrote: Erik van Konijnenburg [EMAIL PROTECTED] writes: | On Fri, Dec 02, 2005 at 06:36:41PM +0200, Jari Aalto wrote: | Setting up linux-image-2.6.14-2-686 (2.6.14-4) ... | Using /usr/sbin/mkinitrd.yaird to build the ramdisk. | Full list of probed ramdisk generating tools : /usr/sbin/mkinitrd /usr/sbin/mkinitrd.yaird /usr/sbin/mkinitramfs. | yaird error: Could not read output for /sbin/modprobe -v -n --show-depends --set-version 2.6.14-2-686 auto (fatal) | | Could you post the output of yaird -d -o /tmp/junk.img 2.6.14-2-686? | and dpkg -l yaird? ii yaird 0.0.11-12 Yet Another mkInitRD OK, that's the most recent. [EMAIL PROTECTED]:~# yaird -d -o /tmp/junk.img 2.6.14-2-686 Output that follows looks correct: it seems you have fstype 'auto' in your /etc/fstab entry for root, and yaird determines that the filesystem is reisrfs. Versions prior to 0.0.11-12 had the problem you show in parsing auto in fstab. That suggests the problem is in how yaird is invoked. Perhaps the kernel install script invokes a broken copy of yaird? Things to check: -- debsums -a yaird if it says a anything other than ok ok ok, reinstall yaird. -- hack /usr/sbin/mkinitrd.yaird to echo the yaird command line and its own arguments to some scratch file, then do dpkg-reconfigure linux-image-2.6.14-2-686 and see if there's a difference from the yaird call you did just now. Or, if getting the new kernel running is more interesting to you than finding out the cause, replace the 'auto' keyword in your fstab with the appropriate file system type. Regards, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341273: Doesn't understand install and remove directives in modprobe.conf
On Tue, Nov 29, 2005 at 01:57:32PM -0500, Norbert Veber wrote: yaird error: modprobe psmouse requires install /sbin/modprobe mousedev /sbin/modprobe --ignore-install psmouse (fatal) Failed to create initrd image. from my modprobe configuration: alias /dev/psaux psmouse install psmouse /sbin/modprobe mousedev /sbin/modprobe --ignore-install psmouse remove psmouse /sbin/modprobe -r --ignore-remove psmouse /sbin/modprobe -r mousedev Thanks for reporting this. Now for the bad news: this is not a bug, this is a feature. The reason is that install lines in the modprobe configuration are complete shell scripts: they can invoke every executable, access every file. That makes it impossible to find out what should be included on the initial boot image to make the install line successful. Rather than silently ignoring the line and producing an image that may or may not boot, we throw an error, so that you can clean up the configuration. In your situation, you can clean up by removing psmouse from your modprobe configuration: if you have a mouse, the default yaird configuration will load mousedev anyway. If you need backward compatibility with old kernels, consider adding mousedev to /etc/modules; it will be loaded unconditionally then. The error message you got sucks though. The development version has a reworded message (bzr revision nr 15). Regards, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341738: linux-image-2.6.14-2-686: Could not read output for /sbin/modprobe -v -n --show-depends --set-version 2.6.14-2-686 auto (fatal)
On Fri, Dec 02, 2005 at 06:36:41PM +0200, Jari Aalto wrote: Setting up linux-image-2.6.14-2-686 (2.6.14-4) ... Using /usr/sbin/mkinitrd.yaird to build the ramdisk. Full list of probed ramdisk generating tools : /usr/sbin/mkinitrd /usr/sbin/mkinitrd.yaird /usr/sbin/mkinitramfs. yaird error: Could not read output for /sbin/modprobe -v -n --show-depends --set-version 2.6.14-2-686 auto (fatal) Could you post the output of yaird -d -o /tmp/junk.img 2.6.14-2-686? and dpkg -l yaird? Thanks, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340344: yaird: Fail to create initrd on s390/s390x
On Thu, Dec 01, 2005 at 12:03:58PM +0100, Ivan Warren wrote: 1) Hardware.pm was missing load CcwDev and load CcwMap (easy fix) Oops, thanks for the fix, is in the repo now. 2) The initramfs gets built : OK, looks normal. 3) Boot fails : Device /sys/block/dasda/dev seems to be down. Debugging opportunity, type ^D to continue. So there's something extra we need to figure out ... Possible explanation : dasd_mod won't autodetect dasds unless specifically requested to do so ! Apparently, the appropriate parameter would be : dasd=autodetect (based on drivers/s390/block/dasd_devmap.c) Possibly. If you do echo options dasd_mod /etc/modprobe.d/test123 and rerun yaird, the parameter should be added to the image (you can see this happening in the -v and -d output) However, I'm curious why this would be necessary now and not for your old kernel. Lets see if we can get this to work without needing changes to your modprobe configuration. If I'm correct, you're running under 2.6.11 with initrd-tools, trying to get 2.6.14 to boot with yaird. Could you extract the /sbin/init script from a 2.6.11 initrd and post it? If it's convenient to place the whole content of initrd somewhere online that could also be usefull, but mostly i'm after the /sbin/init. Is there any difference in kernel command line parameters when booting? However, this would mean guaranteed failure on some dasd configuration changes (this requires a small explanation of the S/390 and z/Arch I/O architecture : Each device is known by 2 ids : A subchannel number and a device number. The device number represents the 'physical' connection (ex : 010A means device 0A on channel 01).. The subchannel number is a sequence number in the configuration, and *THAT* is what is used to perform I/O operations (a device cannot be addressed directly by its device number - ONLY by its subchannel number).. Furthermore, any autodetection scheme would most probably use that subchannel numbering to name devices (or more exactly to assign minor numbers). If 0108 is your 1st dasd device it will most probably be named 'dasda'.. If a new dasd is inserted at 0100, chances are 0108 will now be called 'dasdb' - *however* if dasd_mod is passed a specific list of dasd devices, the naming will probably remain unchanged - regardless of any configuration change - the 1st device listed will be named 'dasda'). The sequence numbering is also model dependent. on IBM real iron, they are usually related to the order in which they appear in the IOCDS (a microcode configuration file that describes the system's I/O configuration). On z/VM (IBM's virtualization solution) the numbering is related to the order in which the devices are declared in the CP directory (The virtual machines definition file). On hercules (an open source S/370, S/390 and z/Arch emulator, which I am using for these tests) the subchannels are numbered based on the order in which they appear in the hercules configuration file... However, the architecture makes *NO* guarantee whatsoever as to the actual order and even whether that number remains identical between each POR (Power On Reset) - The only architectural guarantee is that the numbering is contiguous (no holes). There's a known issue that if the hardware changes, the yaird image will not automatically cope with that. However, for the case you describe the path in /sys/devices may change, but the path in /sys/block should remain stable. Otherwise your initrd would need to use /dev/disk/by-label/ to boot reliably, and I don't think support for that is in initrd-tools. For now, lets look at differences between initrd and yaird-generated image, and keep the sequence numbering in mind as a possible alternative lead. Thanks, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341559: yaird: fails to create initrd
On Thu, Dec 01, 2005 at 11:25:34PM +0100, Hans Ekbrand wrote: On Thu, Dec 01, 2005 at 01:52:34PM +0100, Sven Luther wrote: On Thu, Dec 01, 2005 at 01:10:39PM +0100, Hans Ekbrand wrote: On Thu, Dec 01, 2005 at 12:54:34PM +0100, Sven Luther wrote: Attached is a patch that made it match the two problematic lines: /sys/devices/pci:00/:00:10.0/0.f300:ohare /sys/devices/pci:00/:00:10.0/0.f300:ohare/0.0002:ATA With the patch applied, the initrd was successfully created, and the kernel booted without any problems. Thanks, applied to development repository, revno 14. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340344: yaird: Fail to create initrd on s390/s390x
On Wed, Nov 23, 2005 at 12:00:31AM +0100, Ivan Warren wrote: # yaird -o /tmp/a 2.6.14-2-s390x yaird error: unsupported device required: dasda (fatal) Could you post .. Most certainly... Thanks, that helps. After looking at your output and a debian kernel for s390 it seems that the kernel uses a module mapping table similar to that used for usb and pci; the modules listed in that table match closely with what you describe in your note. Perhaps you could test the version that is now in the development tree? Instructions: apt_get install bzr http_proxy=http://whatever.domain:port/ export http_proxy bzr get http://www.xs4all.nl/~ekonijn/yaird.bzr/ cd yaird.bzr sh bootstrap.sh ./configure --prefix=$HOME/local make install cd $HOME/local/etc ln -s Debian.cfg Templates.cfg cd /tmp sudo $HOME/local/sbin/yaird -v -o junk.img You're the first one to use this temporary, throw-away, bazaar-NG repository, so you may find suprises. Let me know if you need a tarball instead of this repository. The code is untested and will probably break. If this happens and the cause is not immediately obvious, could you add a load of Base::debug statements to Ccw*.pm and post the diffs and output? Note that the repository also contains EVMS support and ide-generic stuff; the differences are a bit much for a patch. Lets get this working first, sort out the packaging afterwards ... Regards, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336688: ide-generic in yaird
After further testing: the issue that ide-generic creates /sys/devices/ide0/0.0, which leads to ide-generic being selected as appropriate driver by yaird, instead of a faster via82cxxx is real. Workaround for old versions of yaird is to place via82cxxx early in Default.cfg. The point that via82cxxx only becomes active after ide-generic is loaded is also real. This is a bug that was present in 2.6.12 and fixed in or before 2.6.14. I reworked yaird to avoid ide-generic as far as possible. Perhaps you could test the version that is now in the development tree? Instructions: apt_get install bzr http_proxy=http://whatever.domain:port/ export http_proxy bzr get http://www.xs4all.nl/~ekonijn/yaird.bzr/ cd yaird.bzr sh bootstrap.sh ./configure --prefix=$HOME/local make install cd $HOME/local/etc ln -s Debian.cfg Templates.cfg cd /tmp sudo $HOME/local/sbin/yaird -v -o junk.img You're the (almost) first one to use this temporary, throw-away, bazaar-NG repository, so you may find suprises. Let me know if you need a tarball instead of this repository. Note that this tree also contains other changes, and that it does not have the debian packaging. That means you cannot use it as a drop in replacement during kernel installs. Regards, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340344: yaird: Fail to create initrd on s390/s390x
On Thu, Dec 01, 2005 at 02:49:03AM +0100, Ivan Warren wrote:
The build went ok.. however, here is what I get :
deb390-1:/tmp# /home/ivan/local/sbin/yaird -v -o junk.img
yaird: goal: template, prologue (/home/ivan/local/etc/yaird/Default.cfg:52)
yaird: action: prologue, {}
yaird: goal: module, fbcon (/home/ivan/local/etc/yaird/Default.cfg:56)
yaird: goal: mountdir, / (/home/ivan/local/etc/yaird/Default.cfg:143)
yaird error: unsupported device required: dasda (fatal)
Could you test a corrected version?
- cd yaird.bzr
- bzr pull # get update
- grep dasd perl/Plan.pm# oops, that was missing
- make install # rest as before
Thanks,
Erik
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340344: yaird: Fail to create initrd on s390/s390x
On Tue, Nov 22, 2005 at 09:39:50PM +0100, Ivan S. Warren wrote: # yaird -o /tmp/a 2.6.14-2-s390x yaird error: can't open /proc/bus/input/devices (fatal) I therefore removed the INPUT goal from /etc/yaird/Default.cfg (since input devices on S/390 z/Arch is irrelevant) as well as anything relating to mouse, etc.. OK, manageable so far ... The following then occurs : # yaird -o /tmp/a 2.6.14-2-s390x yaird error: unsupported device required: dasda (fatal) As a consequence, I am unable to upgrade to the 2.6.14 kernel (since linux-image-2.6.14-3-s390x and linux-image-2.6.14-3-s390 both insist on only using yaird). Could you post * output of yaird --debug -o blah.img * output of yaird --test * output of ls -lR /sys under your old kernel * advice as to what modules you expect to be loaded to get dasda operational You may also want to look at initramfs-tools. Thanks, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336688: yaird also add [permanent] ide-generic
On Wed, Nov 23, 2005 at 12:02:17AM +0100, Mau wrote: Frederik Schueler wrote: On other boxes, notably amd74xx and piix based ones I have access to, this was not needed. Probably it wasn't needed because in those setups the piix module was correctly detected as needed for access to the root device: in my case piix is not strictly needed, as my root partition resides on an hard disk connected to a HPT-370 pci add-on card. I think that the problem is only related with the mandatory presence of the generic module. Sorry about via troubles but, in my opinion, if a way to load an emergency module can't be found here (i.e., loading ide-generic as the last chance when the root device is not accessible after loading the specific module), we'd have to resolve the issues related with yaird. The via issue is probably a kernel related issue, as probably is the choice to mark a module as permanent... but yaird shouldn't add unnecessary modules to initrd or, if this is not possible, it should include the specific modules too. Erik, you asked 'yaird -v' output: did you mean 'yaird -v --test [version]'? The output is about 163kB, should I attach it here? Please don't. Your Frederik's input plus a bit of testing here give a fairly complete picture of what happens. Consider kernel 2.6.14, hdc connected over a via chipset, and two different initial boot images. One loads via first, the other binds ide-generic first. If via82cxxx is loaded first, that will manage the disk, and /sys/block/hdc/device is a symlink to ../../devices/pci./ide1/1.0. In this situation, if you run yaird, it can recognise the pci device as something that needs a via driver: run yaird again you get an image that does not need ide-generic to boot. If ide-generic is loaded first, that will manage the disk, and /sys/block/hdc/device is a symlink to ../../devices/ide1/1.0. Note the absence of pci in the devices tree. In this situation, if you run yaird, it has no way of knowing a via driver would be any good. However, since together with ide-disk we'll always load ide-generic, the image generated by yaird will still boot. I still need to check whether the same behaviour happens with 2.6.12. The story then becomes ide-generic posts misleading info in /sys, so we need ide-generic to boot and the idea that via82cxxx needs ide-generic to boot is wrong, a misunderstanding based on my sloppy testing ... The [permanent] stuff is probably not related. If I'm correct it has to do with via82cxxx being a driver that cannot cleanly deallocate all of its resources, so it can't be removed; that's an interesting issue, but separate from the device recognition stuff we have here. An improvement to yaird would be to load ide-generic if we encounter /sys/devices/ide1/1.0 (without pci) but not for devices like /sys/device/pci.../ide1/1.0. This would mean ide-generic is not loaded for configurations with hpt+piix, if yaird is being executed while the correct drivers are loaded. That still leaves the issue of recognising those cases where ide-generic is used while another driver could also have been used. Figuring that one out is a next step; for now I'll look at a patch to load ide-generic only if no other PCI driver is found. Regards, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336688: yaird also add [permanent] ide-generic
On Mon, Nov 21, 2005 at 02:21:57PM +0100, Frederik Schueler wrote: on my via82cxxx box, I had to load the via driver before the ide-generic one since I switched to a 2.6. kernel, configured manually first in /etc/mkinitrd/modules and now in /etc/yaird/Default.cfg. On other boxes, notably amd74xx and piix based ones I have access to, this was not needed. Thanks, that info helps. I'll experiment a bit with the via82cxxx, not today though. Regards, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336688: yaird also add [permanent] ide-generic
On Fri, Nov 18, 2005 at 03:36:52AM +0100, Mau wrote: Yaird also adds to the initrd the [permanent] ide-generic module, which then prevents piix from loading. The result are the messages PIIX4: port 0x01f0 already claimed by ide0 and PIIX4: port 0x0170 already claimed by ide1 at boot and PIIX ide channels irq driven. ide-generic should probably not be permanent as it's not needed to boot the root filesystem. Please fix! Sigh, ide-generic. With via82cxxx (2.6.8) on a test box here, the IDE disk will only work if ide-generic is present. In /sys I see no hint where ide-generic must and must not be used. If I'm correct, the issue is that ide-generic will manage any IDE chipset that's not handled by any other driver; if another driver is loaded after ide-generic, the IDE devices are already claimed. However, as long as ide-generic is loaded after the chipset drivers, all this ambiguity should not hurt too much. For common hardware, ide-generic is expected to be one of the last drivers loaded. Could you post the output of 'yaird -v' to see if the issue is an ordering problem? Regards, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336688: yaird also add [permanent] ide-generic
On Sun, Nov 20, 2005 at 11:40:00PM +0100, Sven Luther wrote: On Sun, Nov 20, 2005 at 10:19:19PM +0100, Erik van Konijnenburg wrote: On Fri, Nov 18, 2005 at 03:36:52AM +0100, Mau wrote: ide-generic should probably not be permanent as it's not needed to boot the root filesystem. Please fix! that's not handled by any other driver; if another driver is loaded after ide-generic, the IDE devices are already claimed. Notice that i believe that ide-generic will drive any ide chipset for x86, i have some doubt of it working on non-x86 arches, at least it does not work on pegasos, and i don't think it will support the powermacs ide drives. The other problem is, as you say below, that loading it before the real thing will make the real thing not work, as is the case here. However, as long as ide-generic is loaded after the chipset drivers, all this ambiguity should not hurt too much. For common hardware, ide-generic is expected to be one of the last drivers loaded. Maybe the correct algorithm would be to : 1) only include ide-generic on x86 hardware. Doable ... 2) load it after the real driver, and maybe only if the real driver didn't produce a working driver for the root device. This is the problematic one: piix is recognised and works, via8cxxx is recognised and doesn't. How would yaird distinguish when to load ide-generic? [ notes about how ide-generic is not especially easy to read ... ] Yep. So, what about your via based case ? Why does via alone not work ? This is probably a bug in the via driver, maybe because of the strange interrupt issue or something ? I don't know. Options at this point: * Ideally, we could avoid the whole problem by just loading ide-generic late, but according to the report that does not always work. I'm curious about the --verbose output; would that show why this approach doesnt work here? * Or find out whether 'via needs ide-generic' is a bug or feature, possibly repair the driver; does not sound simple. * Or maintain a table of which drivers need ide-generic as extra. Not the kind of maintenance we're looking forward to. Regards, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336392: Acknowledgement (linux-image-2.6.14-1-686: 2.6.14 doesn't boot after dist-upgrade from 2.6.12)
On Fri, Nov 11, 2005 at 08:16:43AM +0100, Olaf van der Spek wrote:
Erik van Konijnenburg wrote:
On Thu, Nov 10, 2005 at 11:25:43PM +0100, Olaf van der Spek wrote:
yaird: goal: mountdir, / (/usr/lib/yaird/conf/Default.cfg:143)
yaird: action: insmod,
/lib/modules/2.6.14-1-686/kernel/drivers/scsi/scsi_mod.ko {optionList=-- }
yaird: action: insmod,
/lib/modules/2.6.14-1-686/kernel/drivers/scsi/sd_mod.ko {optionList=-- }
yaird: hardware: completed platform/host0/target0:0:0/0:0:0:0
yaird: action: mkbdev, /dev/sda {sysname=sda } {optionList=-- }
The two modules are clear: Sda is a blockdevice on SCSI, so we mknod
/dev/sda and
we load the SCSI disk driver, which requires scsi_mod.
But the SCSI host0 claims it's managed directly by the platform, without
any controller
Is that a hardware or software (driver) issue?
If it's a driver issue, shouldn't this report be copied/moved to the
kernel package?
It's a software issue: a driver that does not yet fully take advantage of
the sysfs infrastructure. You may be able to guess which driver by looking
at lsmod under the old kernel.
The author of the driver probably knows already that sysfs is still on the todo
list, so it's not like refiling this issue would provide new info.
Note that making a driver make use of sysfs is a structural change,
not something the author can handle with a quick bugfix.
to manage the bus, so yaird sees no reason to load any SCSI/PCI modules.
Solution: if the SCSI bus is managed by a controller that needs a driver,
make sure the driver that manages the controller makes itself visible in
/sys.
Workaround: in /etc/yaird/Default.cfg, before MOUNTDIR, use the keyword
'MODULE'
to load whatever modules your system needs.
I see no manageable way to detect and repair this kind of misleading /sys
directory
automatically in a standard yaird distribution.
I'm wondering, how did it work before?
In 2.6.12 you may have used initrd-tools. If that's so, the command 'file
/boot/initrd*'
will show 'Linux Compressed ROM File System'. That tool took a bit of a
shotgun approach:
put a lot on the image, and hope something works; yaird is more conservative in
what goes
on the image. Neither approach always produces a booting machine.
Note that initrd-tools cannot be used with kernel 2.6.13 or later: the initrd
approach
uses devfs, a feature that has been removed from newer kernels.
If you have room to experiment with explicitly putting the missing module on
the image,
please do; I would like to include the resulting knowledge in the readme.
Regards,
Erik
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336988: yaird: ignoring 'mesh' doesn't allow root device to be found
On Mon, Nov 07, 2005 at 08:13:05PM +0100, Sven Luther wrote:
On Mon, Nov 07, 2005 at 07:48:32PM +0100, Erik van Konijnenburg wrote:
On Sat, Nov 05, 2005 at 03:30:26PM -0800, Beiad Dalton wrote:
'mesh' is the onboard oldworld SCSI host adapter; my installation
happens to be on this, so when I boot 2.6.14-1-powerpc, I have no root
filesystem.
Does the following patch help? Apart from possible offset complaints,
it should apply to 0.0.11-11.
Regards,
Erik
* added files
{arch}/yaird/yaird--devo/yaird--devo--0.1/[EMAIL
PROTECTED]/patch-log/patch-99
* modified files
--- orig/ChangeLog
+++ mod/ChangeLog
@@ -2,6 +2,20 @@
# arch-tag: [EMAIL PROTECTED]/yaird--devo--0.1
#
+2005-11-10 21:46:24 GMTErik van Konijnenburg [EMAIL PROTECTED]
patch-99
+
+Summary:
+ pre 0.0.12
+Revision:
+ yaird--devo--0.1--patch-99
+
+ * Recognise mesh, an apple SCSI controller found hinding
+ behind apple IO chips. Untested.
+
+modified files:
+ ChangeLog perl/Hardware.pm
+
+
2005-11-09 22:57:06 GMTErik van Konijnenburg [EMAIL PROTECTED]
patch-98
Summary:
--- orig/perl/Hardware.pm
+++ mod/perl/Hardware.pm
@@ -79,6 +79,16 @@
elsif ($abspath =~ m!/[a-f\d]+\.[a-f\d]+:ata-\d+$!) {
# Apple IDE bus; harmless
}
+ elsif ($abspath =~ m!/[a-f\d]+\.[a-f\d]+:mesh$!) {
+ # Apple SCSI controller,
+ # expected behind a mac-io.
+ # In the kernel, the calls of routine
+ # macio_register_driver() suggest that mac53c95
+ # and perhaps media-bay might need similar treatment.
+ # Other mac-io devices are not storage related.
+ $modules = [ mesh ];
+ }
+
elsif ($abspath =~ m!/ide\d+/\d+\.\d+$!) {
# IDE device
my $dev = IdeDev-new (path = $abspath);
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336392: Acknowledgement (linux-image-2.6.14-1-686: 2.6.14 doesn't boot after dist-upgrade from 2.6.12)
On Thu, Nov 10, 2005 at 10:28:50PM +0100, Jonas Smedegaard wrote: On Sun, 30 Oct 2005 12:01:28 +0100 Olaf van der Spek [EMAIL PROTECTED] wrote: Try do a 'dpkg-reconfigure linux-image-2.6.14-1-686' and see if it spews out any errors or warnings. # dpkg-reconfigure linux-image-2.6.14-1-686 Using /usr/sbin/mkinitrd.yaird to build the ramdisk. Full list of probed ramdisk generating tools : /usr/sbin/mkinitrd /usr/sbin/mkinitrd.yaird /usr/sbin/mkinitramfs. I am surprised that no error is emitted here. Could you do yaird --verbose --output=/tmp/pindakaas.img 2.6.14-1-686 lspci and post the output? The generated image, ls -lR /sys, and the output of 'yaird --test 2.6.14-1-686' and 'yaird --debug --output=/tmp/hagelslag.img 2.6.etc' may also help, but they are bigger; let's look at the --verbose output first. Regards, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336392: Acknowledgement (linux-image-2.6.14-1-686: 2.6.14 doesn't boot after dist-upgrade from 2.6.12)
On Thu, Nov 10, 2005 at 11:25:43PM +0100, Olaf van der Spek wrote:
Erik van Konijnenburg wrote:
Could you do
yaird --verbose --output=/tmp/pindakaas.img 2.6.14-1-686
lspci
debian:~# yaird --verbose --output=/tmp/pindakaas.img 2.6.14-1-686
yaird: goal: template, prologue (/usr/lib/yaird/conf/Default.cfg:52)
(doing mouse and keyboard here ...)
yaird: goal: mountdir, / (/usr/lib/yaird/conf/Default.cfg:143)
yaird: action: insmod,
/lib/modules/2.6.14-1-686/kernel/drivers/scsi/scsi_mod.ko {optionList=-- }
yaird: action: insmod,
/lib/modules/2.6.14-1-686/kernel/drivers/scsi/sd_mod.ko {optionList=-- }
yaird: hardware: completed platform/host0/target0:0:0/0:0:0:0
yaird: action: mkbdev, /dev/sda {sysname=sda } {optionList=-- }
The two modules are clear: Sda is a blockdevice on SCSI, so we mknod /dev/sda
and
we load the SCSI disk driver, which requires scsi_mod.
But the SCSI host0 claims it's managed directly by the platform, without any
controller
to manage the bus, so yaird sees no reason to load any SCSI/PCI modules.
Solution: if the SCSI bus is managed by a controller that needs a driver,
make sure the driver that manages the controller makes itself visible in /sys.
Workaround: in /etc/yaird/Default.cfg, before MOUNTDIR, use the keyword 'MODULE'
to load whatever modules your system needs.
I see no manageable way to detect and repair this kind of misleading /sys
directory
automatically in a standard yaird distribution.
Regards,
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#337479: yaird: should use /usr/bin/perl, not /usr/local/bin/perl
On Wed, Nov 09, 2005 at 10:20:47PM +0100, Mattia Dongili wrote: 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: [...] 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. Yes, sorry. I was thinking of a lot of silly corner cases when I wrote that (I hit the same issue when playing with ./configure and stuff so that's what I had in mind in the first place). By the way, Erik, Jonas I'm attaching a patch to the configure.in to add --with-perl option (defaults to autodetection if not given). I'm sorry I'm not into cdbs enough to provide a patch for debian/rules also :) Thanks. Note that the patch only helps if cdbs or debian/rules is also adapted, and then only for yaird, only for perl; not for other stuff in /usr/local, not for other packages being built. For this reason, I'll hold off incorporating the patch until it becomes clear this cannot be fixed in cdbs or dpkg-dev. Outline of possible fix: * do 'configure PATH=/bin:/usr/bin' rather than plain configure. Tested from the command line, helps hiding /usr/local/bin/perl effectively. * in cdbs, class/autotools-vars.mk, do that path setting in DEB_CONFIGURE_SCRIPT_ENV. This bit is untested. Regards, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#338228: yaird error: unrecognised line in /proc/bus/input/devices: S: Sysfs=/class/input/input0 (fatal)
On Tue, Nov 08, 2005 at 11:04:23PM +0100, Rutger Nijlunsing wrote:
apt-get dist-upgrade results in (on a fairly recent git kernel):
yaird error: unrecognised line in /proc/bus/input/devices: S:
Sysfs=/class/input/input0 (fatal)
Thanks for pointing this out.
Attached three patches:
- patch 96: support DAC960 (recognition works, boot untested)
- patch 97: correct ldd regression #337855
- patch 98: cope with new input format in 2.6.15, tested with 2.6.14-git12.
Regards,
Erik
* added files
{arch}/yaird/yaird--devo/yaird--devo--0.1/[EMAIL
PROTECTED]/patch-log/patch-96
* modified files
--- orig/ChangeLog
+++ mod/ChangeLog
@@ -2,6 +2,20 @@
# arch-tag: [EMAIL PROTECTED]/yaird--devo--0.1
#
+2005-11-09 14:12:07 GMTErik van Konijnenburg [EMAIL PROTECTED]
patch-96
+
+Summary:
+ pre 0.0.12
+Revision:
+ yaird--devo--0.1--patch-96
+
+* Add DAC960 recognition.
+* Add todo stuff
+
+modified files:
+ ChangeLog TODO perl/Plan.pm
+
+
2005-11-03 06:02:57 GMTErik van Konijnenburg [EMAIL PROTECTED]
patch-95
Summary:
--- orig/TODO
+++ mod/TODO
@@ -1,4 +1,6 @@
Todo:
+ - regression: ldd for dynamic executables fails, eg ldconfig.
+ - consider $TMPDIR, umask for output.
- what if sda,sdb are raid, then a new disk is added,
and the raid is sda,sdc? we need something like coldplug.
- what about fbcon?
--- orig/perl/Plan.pm
+++ mod/perl/Plan.pm
@@ -447,6 +447,13 @@
return 1;
}
+ # similar driver
+ if ($name =~ /^rd!c\d+d\d+$/) {
+ ModProbe::addModules ($actions, [ DAC960 ]);
+ $actions-add(mkbdev, $device-yspecial, sysname = $name);
+ return 1;
+ }
+
return 0;
}
* added files
{arch}/yaird/yaird--devo/yaird--devo--0.1/[EMAIL
PROTECTED]/patch-log/patch-97
* modified files
--- orig/ChangeLog
+++ mod/ChangeLog
@@ -2,6 +2,24 @@
# arch-tag: [EMAIL PROTECTED]/yaird--devo--0.1
#
+2005-11-09 20:46:57 GMTErik van Konijnenburg [EMAIL PROTECTED]
patch-97
+
+Summary:
+ pre-0.0.12
+Revision:
+ yaird--devo--0.1--patch-97
+
+* Replace all the variants for getting output from a command
+ with a unified routine.
+* For ldd, restore the behaviour that non-zero exit is expected
+ if it's not a dynamic executable.
+ This should fix debian bug #337855
+
+modified files:
+ ChangeLog TODO perl/Base.pm perl/LvmTab.pm perl/ModProbe.pm
+ perl/Plan.pm perl/RaidTab.pm perl/SharedLibraries.pm
+
+
2005-11-09 14:12:07 GMTErik van Konijnenburg [EMAIL PROTECTED]
patch-96
Summary:
--- orig/TODO
+++ mod/TODO
@@ -1,5 +1,4 @@
Todo:
- - regression: ldd for dynamic executables fails, eg ldconfig.
- consider $TMPDIR, umask for output.
- what if sda,sdb are raid, then a new disk is added,
and the raid is sda,sdc? we need something like coldplug.
--- orig/perl/Base.pm
+++ mod/perl/Base.pm
@@ -152,119 +152,115 @@
#
-# tryGetOutput -- all chomped lines of output for a given command.
-# The twist is that errors are acceptable and result in returning undef.
-# Discard stderr.
-#
-sub tryGetOutput {
- my ($cmd, @args) = @_;
- my $cmdLine = join (' ', $cmd, @args);
-
- my $in;
- my $result;
- if (! -e $cmd) {
- Base::debug (tryGetOutput - no command $cmd, returning undef);
- return undef;
- }
-
- my $rc = open ($in, -|);
-
- if (! defined ($rc)) {
- # Failure to fork is not the kind of error we're
- # prepared to ignore.
- Base::fatal (Can't start command $cmdLine);
- }
-
- elsif ($rc == 0) {
- # Child - setup stderr and exec or fatal.
- $rc = open (STDERR, '', '/dev/null');
- if (! $rc) {
- exit (1);
+# runCmd -- run a command, return result code plus chomped output lines.
+# Result code is false if something went wrong; it's *not* child exit code.
+# Uses named arguments:
+# missingOk = absent executable non-fatal, result output will be undef
+# failOk = don't fatal on non-zero exit code
+# keepStderr = do not discard stderr of command.
+# cmd = what to do, including args.
+#
+# Note that some errors (like failure to fork) are fatal even
+# if failOk is set.
+#
+sub runCmd {
+ my %args = @_;
+
+ #
+ # Decode the argument hash.
+ # Sigh, why didn't I do this in python...
+ #
+ my $missingOk = 0;
+ my $failOk = 0;
+ my $keepStderr = 0;
+ my $cmdList = undef;
+ for my $k (keys %args) {
+ if ($k eq 'missingOk') {
+ $missingOk = $args{missingOk};
}
-
- # Do the exec like so to make shell escapes
- # impossible
Bug#336988: yaird: ignoring 'mesh' doesn't allow root device to be found
On Sat, Nov 05, 2005 at 03:30:26PM -0800, Beiad Dalton wrote: 'mesh' is the onboard oldworld SCSI host adapter; my installation happens to be on this, so when I boot 2.6.14-1-powerpc, I have no root filesystem. Could you post 'ls -lR /sys' to see what kind of input we have to recognise this kind of host, and could you give a hint which modules you expect to be loaded to get this device operational? Thanks, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337855: yaird fails with error Could not read output for /usr/bin/ldd ... (fatal)
On Sun, Nov 06, 2005 at 11:22:35PM +0100, Walter Hofmann wrote: I have a yaird configuration which includes /bin/busybox, a statically linked executable. yaird calls /usr/bin/ldd /bin/busybox, which returns with exit status 1 because the file is not a dynamic executable. yaird checks for this exit code and stops because it is not zero. The same problem seems to happen with script files. Ouch. You are correct; this is a regression introduced with adding getOutput in Yaird 0.0.11-11. As an aside, /bin/busybox is a dynamic executable on this sid box; where did your version originate? Regards, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337293: linux-image-2.6.14-1-k7: kernel doesn't boot...
On Mon, Nov 07, 2005 at 09:49:53PM +0100, Erik van Konijnenburg wrote: On Mon, Nov 07, 2005 at 10:54:37AM +0100, Bruno Boettcher wrote: On Thu, Nov 03, 2005 at 09:09:34PM +0100, Erik van Konijnenburg wrote: Hello! Underneath the tmpfs mounted on /dev is the /dev/ that is part of your root device. You can do 'mount -o bind / /mnt; ls /mnt/dev' to see what's there. /dev/.static/dev/ may contain an alias of this. didn't knew this one :D alas: ls -l /dev/.static/dev/console /dev/console crw--- 1 root root 5, 1 2005-11-03 19:02 /dev/console crw--- 1 root tty 5, 1 2005-10-27 23:54 /dev/.static/dev/console For yaird, that /dev on your root device needs to contain at least /dev/console, there's some other stuff too that you want there. On an etch install I tested this week, those special files are available without special user action necessary. seems as if the file is there Pity, it was a nice theory. i have put up the stuff related to what asked me the ramfs guy and the menu.lst onto http://bboett.free.fr/kernel/ could it be possible that theres some problem with rdeving the installed kernel? strange this is that all kernels have a boot device hda1 and i don't have any device called by that name... does grub automaticly do a rdev? Rdev as in http://www.netadmintools.com/html/8rdev.man.html ? That's been obsolete a few years now. Some notes on your dump: * the root=/dev/sdb1 should be redundant but harmless. you may want to try without. * you seem to have a aic7xxx type scsi controller with a straightforward ext3 fs on it as root device. Correct? And there are recent bug reports for that driver: see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=338089 This may cause your boot problems. * boot with 'ydebug' on the kernel command line and you'll be dumped in a shell before switching to the real root. You'll also see the init script commands being executed. Any odd error messages? * At this point you don't have ls, but you can do 'cd /mnt; echo *'. /mnt should at this point have your root device, with /mnt/dev/console on it. Have a look around /mnt; does it look like your root? Have a look at /sys/block/sdb; does it look as a /sys entry for a working disk? Regards, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337293: linux-image-2.6.14-1-k7: kernel doesn't boot...
On Thu, Nov 03, 2005 at 07:11:56PM +0100, Bruno Boettcher wrote: i installed the kernel through dselect, when i reboot the whole things comes to a grinding halt with: Switching root /usr/lib/yaird/exec/run_init: opening console: No such file or directory Kernel panic _ not syncing: Attempted to kill init i have not the faintest idea on what i could do to change this... i had allready a very similar error when i wanted to migrate to 2.6.12... this was solved by reinstalling a debian on that machine, but i wont reinstall the whole thing each time there's a new kernel... Underneath the tmpfs mounted on /dev is the /dev/ that is part of your root device. You can do 'mount -o bind / /mnt; ls /mnt/dev' to see what's there. /dev/.static/dev/ may contain an alias of this. For yaird, that /dev on your root device needs to contain at least /dev/console, there's some other stuff too that you want there. On an etch install I tested this week, those special files are available without special user action necessary. Now if those files went missing, for example, if you would clean up your system by doing 'rm -rf /dev/.static', subsequent boots would fail. The fix would then be to 'cp -ax' from the udev-generated /dev to the underlying root device. Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337279: yaird: /boot != /tmp
On Thu, Nov 03, 2005 at 09:20:55PM +0100, Sven Luther wrote: On Thu, Nov 03, 2005 at 09:12:35PM +0100, Jonas Smedegaard wrote: On Thu, 3 Nov 2005 20:31:40 +0100 Sven Luther [EMAIL PROTECTED] wrote: On Thu, Nov 03, 2005 at 11:44:23AM -0500, Anthony DeRobertis wrote: /boot is for static files of the boot loader according to the FHS. yaird is attempting to use it as /tmp, and failing horribly as it runs out of inodes: A tmpfs could also be used for that, could it not ? The problem is at ramdisk build time, not at boot time, so no need for fancy stuff: Better use plain standard /tmp I guess. Make sure you create a subdir in a secure way, there where loads of security issues involving this in the past. Which is exactly why /tmp is not used. By using a relative path, the side effect is that the temp file is created in a location that the admin deemed safe enough for use. This avoids the whole complicated discussion in http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/avoid-race.html#TEMPORARY-FILES and works perfectly, except of course if you try to use a target directory with 64 inodes, 50% full ... Using $TMPDIR may be workable: this allows the security conscious to set TMPDIR=$HOME/tmp, and TMPDIR=/tmp for users with inode constraints on their target directory. Regards, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335230: More Code also Random, but less :-)
Progress update: Script started on Thu 03 Nov 2005 09:55:57 PM CET [EMAIL PROTECTED]:~$ uptime 21:56:01 up 2 min, 2 users, load average: 1.64, 1.17, 0.47 [EMAIL PROTECTED]:~$ df -k Filesystem 1K-blocks Used Available Use% Mounted on /dev/evms/ev0 19674388 2670484 16004484 15% / tmpfs 518256 0518256 0% /dev/shm tmpfs1024088 10152 1% /dev banaan:/dat 58980544 38083040 17901384 69% /dat [EMAIL PROTECTED]:~$ exit Script done on Thu 03 Nov 2005 09:56:08 PM CET This is an evms volume on top of lvm on top of md, on top of two partitions of the same hard disk. Earlier reported panic was due to my forgetting to populate /dev/ on the junk root disk used for testing. System has no lvm2, mdadm or dmsetup installed. The yaird version no essential differences from the preview a few days ago: added /var/log and /sbin/swapon to the template. Swapon seems not to make difference to the SWAPFS error message discussed earlier. Kernel is 2.6.14 vanilla. Generated image is ca 2Mb. Regards, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335601: compaq arrays with ida
On Wed, Nov 02, 2005 at 05:16:48PM +0100, Erich Schubert wrote:
Hi,
the compaq smart arrays I have use ida:
/dev/ida/c0d0p5 on / type ext3 (rw,errors=remount-ro)
/dev/ida/c0d0p1 on /boot type ext2 (rw)
/dev/ida/c0d0p6 on /home type ext3 (rw,nodev)
as well as /sys/block/ida!c0d0
The module needed is cpqarray
Thanks! Perhaps you would want to test the following patch?
Erik
--- orig/perl/Plan.pm
+++ mod/perl/Plan.pm
@@ -441,6 +441,12 @@
$actions-add(mkbdev, $device-yspecial, sysname = $name);
return 1;
}
+ if ($name =~ /^ida!c\d+d\d+$/) {
+ ModProbe::addModules ($actions, [ cpqarray ]);
+ $actions-add(mkbdev, $device-yspecial, sysname = $name);
+ return 1;
+ }
+
return 0;
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337065: yaird: fails with error: uuid '472dd55c-c2ab-462b-a7b1-2cc890b2d074' not found
On Wed, Nov 02, 2005 at 03:42:20PM +0200, Antonio Kanouras wrote: yaird error: uuid '472dd55c-c2ab-462b-a7b1-2cc890b2d074' not found (/etc/fstab:5) (fatal) I attached a copy of my /etc/fstab. UUID=472dd55c-c2ab-462b-a7b1-2cc890b2d074 / xfs defaults0 1 At the moment, yaird only recognises labels for ext2 and reiser. The workaround is to mount /dev/disk/by-uuid/47..74. The fix is to rip out the label/uuid recognition in yaird and replace it with a wrapper around blkid. --erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336450: linux-image-2.6.14-1-686: 2.6.14-1-686 doesn't support vga=795 o
On Wed, Nov 02, 2005 at 12:23:15AM +0100, Erik van Konijnenburg wrote: On Tue, Nov 01, 2005 at 12:39:13PM +0100, Jonas Smedegaard wrote: On Tue, 1 Nov 2005 07:14:45 +0100 Erik van Konijnenburg [EMAIL PROTECTED] wrote: On Mon, Oct 31, 2005 at 10:42:13AM +0100, Jonas Smedegaard wrote: On Mon, 31 Oct 2005 00:08:24 + Richard Burton [EMAIL PROTECTED] wrote: So, I have a workaround. Not sure how this should be fixed permanently though? Easiest way would seem to be to change the yaird Default.conf, but I don't know if that's the right way. Yaird upstream (Erik) is listening here as well - I'll let him decide if fbcon should perhaps be loaded by default... The interesting bit is what to do about kernels that don't *have* an fbcon, modular or otherwise. Given that the loading is done from a configuration file, we can expect users of such kernels to drop the loading command from the config file, so I don't see objections to loading by default. Why not add a MODULE_GRACEFULLY or similar that fails silently if loading fails. That's useful also for trying to load all NIC drivers (for a single netboot image for a heterogenous network). Good idea; I plan to build that tomorrow release a patch. After that EVMS then swsusp, which will take longer. Please let me know if there's other stuff that you consider to have higher priority. There now is a version of the config file that has OPTIONAL MODULE fbcon plus a version of yaird that understands this syntax. Tested with vanilla 2.6.14 on PC: got it running with both vesafb and rivafb. Note however that even with vga=... I did not succeed in getting a black screen. As an experiment, it's published as a directory of small boring patches in http://www.xs4all.nl/~ekonijn/yaird/patches/ If all goes well, you should be able to just dump these in the quilt patches directory, summarise the changelog and build a new working debian package. As an aside, the quickest way to produce this in tla is: 1. tla get-changeset yaird--devo--0.1--patch-88 2. tla show-changeset --diffs yaird--devo--0.1--patch-88.patches patch88 3. repeat upload Regards, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337168: (no subject)
On Wed, Nov 02, 2005 at 07:01:48PM -0500, Michael Stroucken wrote: yaird gives an error when it parses my fstab, saying that label () wasn't found. My fstab contains the lines LABEL=/ / ext3defaults,errors=remount-ro 0 1 LABEL=/boot /boot ext3defaults0 2 but yaird thinks the root partition label has an extra trailing slash, and removes it, leaving an empty label. A quick and dirty patch is attached. Agreed, except for the word dirty. Incorporated unchanged in upstream tree. Thanks, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336450: linux-image-2.6.14-1-686: 2.6.14-1-686 doesn't support vga=795 o
On Tue, Nov 01, 2005 at 12:39:13PM +0100, Jonas Smedegaard wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 1 Nov 2005 07:14:45 +0100 Erik van Konijnenburg [EMAIL PROTECTED] wrote: On Mon, Oct 31, 2005 at 10:42:13AM +0100, Jonas Smedegaard wrote: On Mon, 31 Oct 2005 00:08:24 + Richard Burton [EMAIL PROTECTED] wrote: So, I have a workaround. Not sure how this should be fixed permanently though? Easiest way would seem to be to change the yaird Default.conf, but I don't know if that's the right way. Yaird upstream (Erik) is listening here as well - I'll let him decide if fbcon should perhaps be loaded by default... The interesting bit is what to do about kernels that don't *have* an fbcon, modular or otherwise. Given that the loading is done from a configuration file, we can expect users of such kernels to drop the loading command from the config file, so I don't see objections to loading by default. Why not add a MODULE_GRACEFULLY or similar that fails silently if loading fails. That's useful also for trying to load all NIC drivers (for a single netboot image for a heterogenous network). Good idea; I plan to build that tomorrow release a patch. After that EVMS then swsusp, which will take longer. Please let me know if there's other stuff that you consider to have higher priority. Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336518: yaird: document using NFS Root
On Tue, Nov 01, 2005 at 06:02:57PM +0100, Jonas Smedegaard wrote: On Mon, 31 Oct 2005 19:52:52 -0700 Vagrant Cascadian [EMAIL PROTECTED] wrote: On Sun, Oct 30, 2005 at 11:51:11PM +0100, Jonas Smedegaard wrote: Currently, MOUNTDIR does not support nfsroot so needs to be commented out completely. ugh. Well, actually... Looking at FsEntry.pm and other code it might actually be supported somehow - or support is halfway there... It's recognised as something we can't support. Mounting eg 'www.debian.org:/boot' would require name resolution, and there's way too much guesswork involved in doing that on the initial boot disk: do you want /etc/hosts? LDAP? NIS? DNS? There's other unpleasantness involved in trying to interpret nfs partitions from fstab on the boot image, but this is the most obvious one. Instead, pass ip= and nfsroot= on the kernel command line as documented in kernel tree Documentation/nfsroot.txt. Do not pass root= on the kernel command line. /init ignores it, but perhaps it confuses the kernel. The most common form is ip=eth0 or ip=all, with nfsaddr= omitted. This will do DHCP initialisation of ethernet device, and get mount point over DHCP in the usual manner. What happens if you omit ip= depends on your config file: you could use a hard disk instead, or start an ssh deamon, or simply panic. More variations possible that can be expressed in a simple command yaird command line option. You may want to remove IP addresses from all your network cards, then run /usr/lib/yaird/exec/ipconfig ip=all to get a feeling for what the IP client code does. Patches for the manual page are welcome. Regards, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336636: fails on fstab line without optional fields
On Tue, Nov 01, 2005 at 10:08:11PM +0100, Jonas Smedegaard wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 1 Nov 2005 17:37:19 +0100
Sven Luther [EMAIL PROTECTED] wrote:
BTW, i just had an idea, but is maybe the way yaird does this not
broken, and it should use the mount output instead :
The output of mount shows what is currently mounted.
/etc/fstab shows what is intended to be mounted.
So switching to using a different rootfs for the next mount would not
be possible if relying on what's mounted now.
Please find attached a patch to do
* absent options in fstab
* multiple fstypes: ext2,ext3
* auto fstype.
We could use blkid to verify the fstype even if it's given explicitly
in /etc/fstab, then do an error message if there's no match so the
image would not boot. Somehow I get the impression that's an improvement
that would not be much appreciated today ...
Regards,
Erik
This is the test set used to make the patch:
#
# This is true; works
# /dev/mapper/vg0-tst /b ext3 defaults,noauto 0 2
# This is a lie, its ext3 -- mount complains 'wrong fstype or
superblock'.
# Expect yaird to fail at boot time.
# /dev/mapper/vg0-tst /b vfat defaults,noauto 0 2
# this is successful -- do two mount system calls, both fs types.
#/dev/mapper/vg0-tst /b vfat,ext3 defaults,noauto 0 2
# Works, but complains about unknown fstype '' if it was already mounted
# deviant repeat errors not tested for other variants.
#/dev/mapper/vg0-tst /b vfat,ext3, defaults,noauto 0 2
# Works
#/dev/mapper/vg0-tst /b ,vfat,ext3 defaults,noauto 0 2
# Works
#/dev/mapper/vg0-tst /b vfat,,ext3 defaults,noauto 0 2
# Fails
#/dev/mapper/vg0-tst /b ,, defaults,noauto 0 2
# this works -- courtesy of blkid libaries
# /dev/mapper/vg0-tst /b auto defaults,noauto 0 2
# this works - fsck stuff is optional
# /dev/mapper/vg0-tst /b ext3 defaults,noauto
# this also works
# /dev/mapper/vg0-tst /b ext3
# this breaks -- mount complains unknown fstype ''
# /dev/mapper/vg0-tst /b
#
diff -urN -x {arch} -x .arch-ids -x configure -x aclocal.m4 -x depcomp -x
missing -x Makefile -x Makefile.in -x install-sh -x INSTALL p79/ChangeLog
p83/ChangeLog
--- p79/ChangeLog 2005-11-01 22:55:04.0 +0100
+++ p83/ChangeLog 2005-11-01 22:55:16.0 +0100
@@ -2,6 +2,62 @@
# arch-tag: [EMAIL PROTECTED]/yaird--devo--0.1
#
+2005-11-01 21:54:21 GMTErik van Konijnenburg [EMAIL PROTECTED]
patch-83
+
+Summary:
+ support fstype == auto
+Revision:
+ yaird--devo--0.1--patch-83
+
+support fstype == auto
+
+
+modified files:
+ ChangeLog perl/Plan.pm
+
+
+2005-11-01 21:29:30 GMTErik van Konijnenburg [EMAIL PROTECTED]
patch-82
+
+Summary:
+ merge optGetOutput from evms branch
+Revision:
+ yaird--devo--0.1--patch-82
+
+merge optGetOutput from evms branch
+
+
+modified files:
+ ChangeLog perl/Base.pm
+
+
+2005-11-01 21:15:27 GMTErik van Konijnenburg [EMAIL PROTECTED]
patch-81
+
+Summary:
+ allow absent fs options
+Revision:
+ yaird--devo--0.1--patch-81
+
+allow absent fs options
+
+
+modified files:
+ ChangeLog perl/FsTab.pm
+
+
+2005-11-01 21:04:52 GMTErik van Konijnenburg [EMAIL PROTECTED]
patch-80
+
+Summary:
+ allow fstype ext3,vfat
+Revision:
+ yaird--devo--0.1--patch-80
+
+allow fstype ext3,vfat
+
+
+modified files:
+ ChangeLog perl/Plan.pm
+
+
2005-11-01 20:28:10 GMTErik van Konijnenburg [EMAIL PROTECTED]
patch-79
Summary:
diff -urN -x {arch} -x .arch-ids -x configure -x aclocal.m4 -x depcomp -x
missing -x Makefile -x Makefile.in -x install-sh -x INSTALL p79/perl/Base.pm
p83/perl/Base.pm
--- p79/perl/Base.pm2005-11-01 22:55:04.0 +0100
+++ p83/perl/Base.pm2005-11-01 22:55:16.0 +0100
@@ -35,6 +35,7 @@
#
# Also routines to
# - read content of one-line files
+# - read content of multi-line files
# - get device number from block or character device files
# - interpret symbolic links
# - interpret pathnames
@@ -151,6 +152,69 @@
#
+# optGetOutput -- all chomped lines of output for a given command.
+# The twist is that a non-existent command is acceptable,
+# and results in returning undef.
+# Errors in invoking the cmd are fatal.
+# Discard stderr.
+#
+sub optGetOutput {
+ my ($cmd, @args) = @_;
+ my $cmdLine = join (' ', $cmd, @args);
+
+ my $in;
+ my $result;
+ if (! -e $cmd) {
+ Base::debug (No command $cmd, returning undef);
+ return undef;
+ }
+
+ my $rc = open ($in, -|);
+
+ if (! defined ($rc)) {
+ Base::fatal (Can't start command $cmdLine
Bug#336518: yaird: document using NFS Root
On Tue, Nov 01, 2005 at 10:24:05PM +0100, Sven Luther wrote: On Tue, Nov 01, 2005 at 09:03:37PM +0100, Erik van Konijnenburg wrote: On Tue, Nov 01, 2005 at 06:02:57PM +0100, Jonas Smedegaard wrote: On Mon, 31 Oct 2005 19:52:52 -0700 Vagrant Cascadian [EMAIL PROTECTED] wrote: On Sun, Oct 30, 2005 at 11:51:11PM +0100, Jonas Smedegaard wrote: Currently, MOUNTDIR does not support nfsroot so needs to be commented out completely. ugh. Well, actually... Looking at FsEntry.pm and other code it might actually be supported somehow - or support is halfway there... It's recognised as something we can't support. Mounting eg 'www.debian.org:/boot' would require name resolution, and there's way too much guesswork involved in doing that on the initial boot disk: do you want /etc/hosts? LDAP? NIS? DNS? There's other unpleasantness involved in trying to interpret nfs partitions from fstab on the boot image, but this is the most obvious one. What about runing host www.debian.org and using the returned IP address ? What about round-robin DNS, changes in hosting, IPv6 addresses, NFS over IPsec tunnels, gateways other than the default, using an old server without warning after the hostname was changed to a new IP address ... It's possible to generate an NFS image using such heuristics that may occasionally work, but I don't know how to do it reliably. Under those circumstances, it would be misleading to interpret an NFS path in fstab and pretend that we expect it to work. On the other hand, the current approach with ip= allows very precise control, from fully automatic IP configuration using DHCP to fully manual. That said, there's room for improvement to the manual; it also could make sense to have a custom config file and wrapper script for common NFS configurations such as used in lessdisks. Regards, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336518: yaird: document using NFS Root
On Tue, Nov 01, 2005 at 10:38:56PM +0100, Jonas Smedegaard wrote: Erik: Would it make sense to allow static IP, and only choke on non-IP value before the colon in fstab? Finding the server would be easier. Now to figure out a way to decide whether client should have a hard-coded IP address or a DHCP address. For bonus points, do so in a distro independent manner... I couldn't find a way to do so reliably. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336567: postinst fails runnng modprobe on 'ext3,ext2'
On Tue, Nov 01, 2005 at 11:07:06PM +0100, Sven Luther wrote: On Tue, Nov 01, 2005 at 10:28:05PM +0100, Jonas Smedegaard wrote: On Tue, 1 Nov 2005 22:00:34 +0100 Sven Luther [EMAIL PROTECTED] wrote: Well, using debconf is packaging. Well, i disagree You are makind debconfification much more complicated than it really needs to be :) Yaird is available for redhat as well. Is debconf available for redhat? If not, then the use of debconf either needs to be separated from the tool itself (what I call the packaging - call it whatever you like) or indeed it gets rather complicated! Indeed, you need to split out all user interaction in their own perl module, which can use either debconf or normal stuff, but this does by no way need any of the other stuff you where talking about. Two considerations: * Keeping the core portable across distros seems worthwhile to me, even if it's only to create additional testing opportunities. Using debconf in the core plays ill with this approach. * The core is complicated enough for my taste without being interactive. You're welcome to build a wrapper around yaird that interprets error messages, talks debconf to the user and restarts yaird after fixing whatever errors found, but it does not strike me as a very promissing approach ... Regards, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336585: yaird: The fs_freq and fs_passno fields in /etc/fstab are optional
On Mon, Oct 31, 2005 at 11:22:23AM +, Ian Campbell wrote:
Package: yaird
Version: 0.0.11-10
Severity: normal
When running yaird I get the following:
$ sudo /usr/sbin/yaird --output /tmp/initrd 2.6.14-1-386
yaird error: malformed line in /etc/fstab:14 (fatal)
this also effects the linux-image-2.6.14-1-386 package.
The problem is that I have several entries in fstab without the optional
fifth and sixth fields (fs_freq and fs_passno). The comments around line
49 of /usr/lib/yaird/perl/FsTab.pm suggest that the author was aware
that these were optional fields but I thought a bug report was
appropriate to stop the problem falling through the cracks.
Attached patch should fix this;
note that 336612, 336636 336585 seem to be dups.
Regards,
Erik
diff -urN -x {arch} -x .arch-ids -x configure -x aclocal.m4 -x depcomp -x
missing -x Makefile -x Makefile.in -x install-sh -x INSTALL p77/ChangeLog
p78/ChangeLog
--- p77/ChangeLog 2005-10-31 20:59:00.0 +0100
+++ p78/ChangeLog 2005-10-31 20:59:07.0 +0100
@@ -2,6 +2,23 @@
# arch-tag: [EMAIL PROTECTED]/yaird--devo--0.1
#
+2005-10-31 19:58:18 GMTErik van Konijnenburg [EMAIL PROTECTED]
patch-78
+
+Summary:
+ 0.0.12 pre
+Revision:
+ yaird--devo--0.1--patch-78
+
+* The last two fields on fstab line are optional
+ in the mount command, so let's have them optional
+ in yaird as well.
+ This should fix debian bugs 336612, 336636 336585
+
+
+modified files:
+ ChangeLog perl/FsTab.pm
+
+
2005-10-31 19:30:17 GMTErik van Konijnenburg [EMAIL PROTECTED]
patch-77
Summary:
diff -urN -x {arch} -x .arch-ids -x configure -x aclocal.m4 -x depcomp -x
missing -x Makefile -x Makefile.in -x install-sh -x INSTALL p77/perl/FsTab.pm
p78/perl/FsTab.pm
--- p77/perl/FsTab.pm 2005-10-31 20:59:00.0 +0100
+++ p78/perl/FsTab.pm 2005-10-31 20:59:07.0 +0100
@@ -45,9 +45,10 @@
next if $line =~ /^#/; # comment line
next if $line eq ;# empty line
my @fields = split (/\s+/, $line, 999);
- if ($#fields 6) {
+ if ($#fields 4) {
# no test for extra fields;
# the mount command allows that.
+ # note that field 5,6 (fsck stuff) is optional
Base::fatal (malformed line in $name:$lineNo);
}
if ($fields[2] eq swap) {
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336585: yaird: The fs_freq and fs_passno fields in /etc/fstab are optional
On Mon, Oct 31, 2005 at 04:51:11PM +, Ian Campbell wrote: On Mon, 2005-10-31 at 17:45 +0100, Jonas Smedegaard wrote: And upstream knew about it? The comment in the code is a bit vague, he could be talking about these fields, or perhaps some other optional extra fields... The comment refered to absence of error checking for 6 fields on a given line in mount command, as motivation for similar absence in yaird. That's no excuse for failing to notice that mount treats last two fields are optional of course ... -- 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#336599: please support dm-crypt devices
On Mon, Oct 31, 2005 at 12:46:27PM +, Martin Michlmayr wrote: Package: yaird Version: 0.0.11-10 Severity: wishlist Please support dm-crypt devices. Given that initrd-tools handles this fine, yaird should really support it if it wants to be a replacement... | yaird error: encrypted device 'root' has keyfile specified in /etc/crypttab:3. This is not supported. (fatal) | Failed to create initrd image. This happens only for root on a crypted device with a keyfile other than 'none'. If I read initrd-tools correctly, it will run /keyscripts/* (not sure where it gets them, not sure where its documented) but it will ignore the keyfile field in /etc/crypttab. When booting with initrd-tools, do you have to enter a passphrase to unlock the root disk? If so, there's probably a typo in /etc/crypttab that was not detected by initrd-tools, and we can close this report. Otherwise, could you describe how you feed the key to cryptsetup? We'll then need to find a way to do that in yaird, preferably one that works in mkinitramfs as well. Regards, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336514: yaird: falls down when new scsi/sata disks are added
On Mon, Oct 31, 2005 at 01:20:32PM -0500, Daniel Jacobowitz wrote: On Mon, Oct 31, 2005 at 07:18:01PM +0100, Jonas Smedegaard wrote: On Mon, 31 Oct 2005 12:47:58 -0500 Daniel Jacobowitz [EMAIL PROTECTED] wrote: On Mon, Oct 31, 2005 at 06:09:28PM +0100, Jonas Smedegaard wrote: Ah, the mknod call. Yes, you are right. Erik: Recent versions of mdadm supports a new option auto to auto-create devices as needed. Perhaps that could be used at least on Debian to avoid hardcoded device names? I don't think that will help? That's for /dev/md0, not /dev/sd*. Right. So what was the problem again with my proposed hack? mdadm presumably needs to open device nodes in order to find RAID disks. If we don't _create_ the device nodes, it can't _find_ them. Daniel: agreed, the mdadm auto hack won't work for the reason you note. Doing mknod for all partitions and disks in /sys gets close to coldplugging. I don't expect it to be trivial. The reason is yaird currently has a depth-first recursive walk doing exactly the stuff required for a file system. With coldplugging, you work in layers: first all hardware probing, then creating block-special nodes, then doing scan for raid, lvm or crypt devices. Coldplugging is more resilient to hardware changes, but harder to get right if someone has crypt below lvm instead of the other way around for example. Interesting to experiment with, but not a quick fix for today. Regards, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335230: More Code also Random, but less :-)
On Mon, Oct 31, 2005 at 11:00:45AM +0100, Mattia Dongili wrote: On Mon, October 31, 2005 1:00 am, Erik van Konijnenburg said: On Fri, Oct 28, 2005 at 08:12:57PM +0200, Marco Amadori wrote: Diff attached, diffed to extracted yaird-0.11-9, but should not differs to much I think. I tried to go more in deep into this project, but I still needed a lot of pseudocode comments. Please comments my doubts and questions and put your queries here. Just a quick note: your code is now incorporated into what will be 0.0.12, Excellent! So I'll wait to get your code (yesterday I started working on Marco's code too as I finally got a fully working qemu+evms environment to play with). I'm working on the EvmsDev object trying to make some sense of all the segment/region/etc relationships and trying to call evms_query as less as possible as it's very slow. BTW: do you have an online repository (svn.debian.org?) in order for me to stay up-to-date? The first preview is in http://www.xs4all.nl/~ekonijn/yaird/yaird-evms.tar.gz This preview is *NOT* suitable for packaging: there are bugfixes in the 0.0.11-x series that are not incorporated here. Testing: minimal. The code was built on a test box, generates an image there, afterwards code was merged in tla and rolled into a tarball. The tarball can be downloaded and installed will build images. The images still need to be beat in shape: no succesful boot so far. The testcase is deliberately silly: ext3 on lvm on raid1, with both raid components on same IDE drive. Standard 2.6.12-1 kernel on newly installed box. Messages on boot: - plugin SWAPFS failed to load, error 38, function not implemented - devfs_mk_dev: could not append to parent for md/0 - raid1: md0 active 2 out of 2 mirrors. - run_init: opening console: no such file or directory. - panic: attempt to kill init. Obvious debugging steps are 'set -x' in init script, running dash interactively before run_init. Not today ... Sorry, no public repository yet. It's on the todo list. Regarding dm-raid: lets discuss that *after* we get this working ... Thanks, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336450: linux-image-2.6.14-1-686: 2.6.14-1-686 doesn't support vga=795 o
On Mon, Oct 31, 2005 at 10:42:13AM +0100, Jonas Smedegaard wrote: On Mon, 31 Oct 2005 00:08:24 + Richard Burton [EMAIL PROTECTED] wrote: So, I have a workaround. Not sure how this should be fixed permanently though? Easiest way would seem to be to change the yaird Default.conf, but I don't know if that's the right way. Yaird upstream (Erik) is listening here as well - I'll let him decide if fbcon should perhaps be loaded by default... The interesting bit is what to do about kernels that don't *have* an fbcon, modular or otherwise. Given that the loading is done from a configuration file, we can expect users of such kernels to drop the loading command from the config file, so I don't see objections to loading by default. Regards, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335230: More Code also Random, but less :-)
On Fri, Oct 28, 2005 at 08:12:57PM +0200, Marco Amadori wrote: Diff attached, diffed to extracted yaird-0.11-9, but should not differs to much I think. I tried to go more in deep into this project, but I still needed a lot of pseudocode comments. Please comments my doubts and questions and put your queries here. Just a quick note: your code is now incorporated into what will be 0.0.12, and just produced it's first disk recipe. The list of ingredients that should go on the disk is not complete yet, but the analysis when to do evms activation plays nicely with the rest of the framework now. I plan to do a preview tarball tomorrow night. Regards, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336450: linux-image-2.6.14-1-686: 2.6.14-1-686 doesn't support vga=795 o
On Sun, Oct 30, 2005 at 10:21:39PM +0100, Jonas Smedegaard wrote: On Sun, 30 Oct 2005 15:25:33 + Richard Burton [EMAIL PROTECTED] wrote: This could be changes to video drivers in the kernel. Please describe your graphics card used. Oops, I did intened to mention that. It's an Nvidia GeForce 6600GT 128MB (generic unbranded reference board). Nvidia. Ok (or ok is perhaps an exageration: problems with this specific hardware vendor is not really a surprise to me...) Please try the following: 1) add ramdisk = /usr/sbin/mkinitrd.yaird to /etc/kernel-img.conf 2) make a backup of the initrd for your older working kernel 3) Run dpkg-reconfigure old kernel package 4) Reboot with older kernel Now older kernel hits same problem. So I guess this is yaird problem then? You can also try installing initramfs-tools, uninstalling yaird, run dpkg-reconfigure new kernel package and reboot with new kernel. Also has no video on boot. You did remember to uninstall yaird before regenerating the ramdisk? Then it sounds like the nvidia driver being buggy then - not a yaird bug if also appearing with initramfs-tools. I am not experienced here, so others please comment, if this is a known situation! Richard: Are you ready for some more geeky tests? Perhaps initrd-tools loads other modules or in another order than both yaird and initramfs-tools. So if you could boot an old kernel with initrd ramdisk and kernel options init=/bin/sh rw, and run the following command: /sbin/lsmod /mkinitrd-modules.dump Then do the same with same kernel but yaird ramdisk, and (blindly) dump to a separate file. Then post both dumps here... Just a quick note that there's nothing in yaird 0.0.11 tarball to support vga=... This will probably require an extra module in the config file, vesafb or so, plus an equivalence to a kernel define (I seem to remember modular framebuffers are broken on some architectures, so it may be compiled in on some machines). Perhaps also an 'optional' variant of the MODULE keyword, that will not complain if the module is not compiled in and not a module. --erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336378: yaird fails to prepare an initrd image when vesafb-tng is present
On Sat, Oct 29, 2005 at 11:49:56PM +0300, Er?in EKER wrote:
Package: yaird
Version: 0.0.11-9
I have compiled linux-2.6.14 with kernel-package and when i wanted to
install the Deb packages yaird complains about the strange video mode
given in kernel configuration.
command line failure message:
yaird error: bad value in /boot/config-2.6.14-archck1:
CONFIG_FB_VESA_DEFAULT_MODE=[EMAIL PROTECTED] (fatal)
Failed to create initrd image.
Does this help? Apply to /usr/lib/yaird/perl/KConfig.pm
* looking for [EMAIL PROTECTED]/yaird--devo--0.1--patch-76 to compare with
* comparing to [EMAIL PROTECTED]/yaird--devo--0.1--patch-76
M perl/KConfig.pm
* modified files
--- orig/perl/KConfig.pm
+++ mod/perl/KConfig.pm
@@ -66,7 +66,7 @@
|| $value eq 'm'
|| $value =~ /^-?\d+$/
|| $value =~ /^0x[0-9a-f]+$/
- || $value =~ /^[-a-zA-Z0-9,.:_\/= ]*$/
+ || $value =~ /^[-a-zA-Z0-9@,.:_\/= ]*$/
) {
$kConfMap-{$key} = $value;
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335230: More stub code
On Wed, Oct 26, 2005 at 09:49:13AM +0200, Mattia Dongili wrote: On Tue, October 25, 2005 10:13 pm, Erik van Konijnenburg said: On Tue, Oct 25, 2005 at 08:09:06PM +0200, Mattia Dongili wrote: The init() function looks OK. Detail: you're doing a fork/exec of evms_query info ... just to find a major/minor number. Using Base::devno() is cheaper: just a stat() system call. Yes, that was my first implementation actually. But the Device Number in evms_query info doesn't match the real device maj/min and I really don't know which one might be useful when filtering with findByDevNo eg: Possibly evms devices modified in the ui but not yet activated ... Plugins: you're working on those. In the mean time, I got EVMS installed on a test box here, albeit in a silly configuration. Playing a bit suggests that it may be that the properties uncovered now are already enough to support raid; should become apparent in testing. Here's a twist: what if there are two devices on evms that yaird accesses? So far we've been able to do a depth-first walk over devices needed, but if evms_activate does not take an argument indicating which device we're trying to activate, we'll need to find an alternative approach. evms_activate will try to discover them all. I still don't get why this is an issue but this is due to limited computing power in my brain :) There's some tricky issues there, but that requires more coffee to write down properly than is advisable at this time of day :-) Anyway, I plan to hook the code you mailed into a test version of yaird this weekend. Thanks, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335230: More stub code
On Tue, Oct 25, 2005 at 08:09:06PM +0200, Mattia Dongili wrote: I've been able to setup an almost-working evms box (at least evms_query reports useful data). I tried following Erik's suggestions and also implemented part of the init() method and reworked some of Marco's code. Some parts are still to be finished, but I'd like some feedback expecially on evms_query commands and the expected content of some EvmsDev properties. The init() function looks OK. Detail: you're doing a fork/exec of evms_query info ... just to find a major/minor number. Using Base::devno() is cheaper: just a stat() system call. The properties look OK to find devices, but don't yet provide enough information to decide whether to load raid0/raid5. The crude fix is to just load them always ... Marco, opinions? Here's a twist: what if there are two devices on evms that yaird accesses? So far we've been able to do a depth-first walk over devices needed, but if evms_activate does not take an argument indicating which device we're trying to activate, we'll need to find an alternative approach. Regards, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335230: Random Code so far to be cleaned
Thanks; that was fast.
In the following comment, there are occasional notes so far we did
it differently. That does not necessarily mean your approach is wrong,
however I would prefer not to introduce variations in style if we don't
have to. The unity in style should make it easier for future generations
to familiarize themselves with the code ...
In other situations, I found it effective to first build analysis code
that is invoked with the --test option, that just shows which evms devices
are available and what are their underlying devices.
Note that I haven't played with EVMS yet; these are mostly issues of fitting
in with the existing code, not test results.
On Mon, Oct 24, 2005 at 06:33:42PM +0200, Marco Amadori wrote:
diff -urN yaird-0.0.11/perl/Evms.pm yaird-0.0.11-evms/perl/Evms.pm
--- yaird-0.0.11/perl/Evms.pm 1970-01-01 01:00:00.0 +0100
+++ yaird-0.0.11-evms/perl/Evms.pm2005-10-24 18:31:24.0 +0200
@@ -0,0 +1,70 @@
+#!perl -w
+#
+# Evms -- encapsulate evms_gather output
+# Copyright (C) 2005 Erik van Konijnenburg, Marco Amadori
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+#
+
+use strict;
+use warnings;
+use Base;
+use Conf;
Conf is probably redundant
+use base 'Obj';
+package Evms;
These two lines may need to be swapped.
+
+sub fill {
+ my $self = shift;
+ $self-SUPER::fill();
+ $self-takeArgs ('path', 'devno', 'disks', 'plugins', 'version');
+}
+
+sub path { return $_[0]-{path}; }
+sub devno{ return $_[0]-{devno}; } # 4 what?
+sub disks{ return $_[0]-{disks}; }
ok ...
+sub plugins { return $_[0]-{plugins}; } # not implemented
+sub version { return $_[0]-{version}; }
can these differ between devices in a single system?
if not, not much sense in making them attributes of individual disks..
+
+sub string {
+ my $self = shift;
+ my $path = $self-path;
+ my $devno = $self-devno;
+ my $disks = join (',', @{$self-disks});
+ my $plugins = join (',', @{$self-plugins});
+ return $path($devno) = $plugins on $disks;
+}
+
+
+sub findDisksByName ($) {
So far, the find functions have been kept in a module
named like YyyTab.pm, separate from the YyyDev.pm, the YyyDev
then contains just access functions like string() and
friends.
perhaps we need an EvmsTab.pm?
+# should provide a list from evms_query disks name
+# like the output of the shell command
+# evms_query disks /dev/evms/lvm2/safe/usr64 | xargs -i echo /dev/\{\}
+# /dev/sda
+# /dev/sdb
+# /dev/sdc
+ my ($name) = @_;
+
+ return $evms-disks;
$evms? from where? So far, a module EvmsTab contained a variable
$evmsTab. A find() function then does init(), and init() will initialise
$evmsTab if it is not yet defined; doing so by parsing output of evms_query.
The find() function can walk $evmsTab afterwards.
Note that this is easier to integrate if you have a findByDevno()
that returns an Evms object given a major:minor for a device, or undef.
+
+
+sub findVersion () {
+# equivalent of evms_query info | head -1 | cut -d ' ' -f 3
+# e.g. from the output EVMS Version: 2.5.3 \
+# EVMS Engine API Version: 10.1.0 gives 2.5.3
+
+ return $evms-version;
+}
+
+1;
diff -urN yaird-0.0.11/perl/Plan.pm yaird-0.0.11-evms/perl/Plan.pm
--- yaird-0.0.11/perl/Plan.pm 2005-08-07 22:57:40.0 +0200
+++ yaird-0.0.11-evms/perl/Plan.pm2005-10-24 18:28:12.375146768 +0200
@@ -1,7 +1,7 @@
#!perl -w
#
# Plan -- high-level stuff
-# Copyright (C) 2005 Erik van Konijnenburg
+# Copyright (C) 2005 Erik van Konijnenburg, Marco Amadori
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
@@ -25,6 +25,7 @@
use FsTab;
use ActiveBlockDevTab;
use LvmTab;
+use Evms;
use Hardware;
use ModProbe;
use RaidTab;
@@ -83,6 +84,7 @@
}
my $ok = 0;
+ $ok || ($ok = tryEvms ($actions,$device,[$device,@{$working}]));
Tricky. Trying Evms even before verifying a device may be a partition
of other device? The partition check is simple, cheap and foolproof;
a good one to start with.
$ok || ($ok = tryParent ($actions,$device,[$device,@{$working}]));
$ok || ($ok
Bug#335601: compaq smart array controller support in yaird
Package: yaird
Version: 0.0.11-6
Yaird 0.0.11 does not support the compaq smart array controller;
here's a patch for machines with the cciss driver, a preview from 0.0.12.
This does not provide support for cpqarray; reports about those are welcome.
Beware: there's one report that the core patch in Plan.pm works; the
other bells and whistles here are untested so far.
--erik
diff -urN -x {arch} -x .arch-ids -x configure -x aclocal.m4 -x depcomp -x
missing -x Makefile -x Makefile.in -x install-sh -x INSTALL p73/ChangeLog
p74/ChangeLog
--- p73/ChangeLog 2005-10-24 23:51:03.0 +0200
+++ p74/ChangeLog 2005-10-24 23:50:57.0 +0200
@@ -2,6 +2,27 @@
# arch-tag: [EMAIL PROTECTED]/yaird--devo--0.1
#
+2005-10-22 15:03:19 GMTErik van Konijnenburg [EMAIL PROTECTED]
patch-74
+
+Summary:
+ 0.0.12 - preparing for ...
+Revision:
+ yaird--devo--0.1--patch-74
+
+ * Add support for Compaq smartarray, SMART2 only,
+ no reports yet about Smart 5xxx, but should not be too complicated.
+ These drivers don't point to underlying hardware; no change
+ of doing generic detection, just look at name of block device,
+ then pick a hard-coded module
+ * add more quotes in config files. This should be more robust
+ in the face of ! marks in smart-array device names.
+
+modified files:
+ ChangeLog perl/KConfig.pm perl/Plan.pm
+ templates/Debian-initrd.cfg templates/Debian.cfg
+ templates/Fedora.cfg
+
+
2005-10-13 20:44:53 GMTErik van Konijnenburg [EMAIL PROTECTED]
patch-73
Summary:
diff -urN -x {arch} -x .arch-ids -x configure -x aclocal.m4 -x depcomp -x
missing -x Makefile -x Makefile.in -x install-sh -x INSTALL p73/perl/KConfig.pm
p74/perl/KConfig.pm
--- p73/perl/KConfig.pm 2005-10-24 23:51:03.0 +0200
+++ p74/perl/KConfig.pm 2005-10-24 23:50:57.0 +0200
@@ -192,6 +192,10 @@
'st' = 'CHR_DEV_ST',
'sr-mod' = 'BLK_DEV_SR',
'sg' = 'CHR_DEV_SG',
+
+ # Compaq Smart Array controllers
+ 'cpqarray' = 'BLK_CPQ_DA',
+ 'cciss' = 'BLK_CPQ_CISS_DA',
};
diff -urN -x {arch} -x .arch-ids -x configure -x aclocal.m4 -x depcomp -x
missing -x Makefile -x Makefile.in -x install-sh -x INSTALL p73/perl/Plan.pm
p74/perl/Plan.pm
--- p73/perl/Plan.pm2005-10-24 23:51:03.0 +0200
+++ p74/perl/Plan.pm2005-10-24 23:50:57.0 +0200
@@ -426,6 +426,22 @@
return 1;
}
+ #
+ # compaq smart controllers in 2.6.13 also lack the hardware link.
+ # plan B: assume that a cciss is a cciss.
+ # complication: there's a discrepancy between /sys and /dev:
+ # /sys/block/cciss!c0d0 and /dev/cciss/c0d0, but this turns out
+ # to have no further consequences.
+ #
+ # note that there also exist /dev/ida/c0d0 devices with cpqarray
+ # underlying devices, but no reports about those so far.
+ #
+ if ($name =~ /^cciss!c\d+d\d+$/) {
+ ModProbe::addModules ($actions, [ cciss ]);
+ $actions-add(mkbdev, $device-yspecial, sysname = $name);
+ return 1;
+ }
+
return 0;
}
diff -urN -x {arch} -x .arch-ids -x configure -x aclocal.m4 -x depcomp -x
missing -x Makefile -x Makefile.in -x install-sh -x INSTALL
p73/templates/Debian.cfg p74/templates/Debian.cfg
--- p73/templates/Debian.cfg2005-10-24 23:51:03.0 +0200
+++ p74/templates/Debian.cfg2005-10-24 23:50:57.0 +0200
@@ -217,8 +217,7 @@
# and already is suitably escaped.
SCRIPT /init
BEGIN
- !/sbin/insmod 'TMPL_VAR NAME=target' \
- ! TMPL_VAR NAME=optionList
+ !/sbin/insmod 'TMPL_VAR NAME=target' TMPL_VAR
NAME=optionList
END SCRIPT
END TEMPLATE
@@ -360,8 +359,8 @@
! TMPL_IF NAME=isRoot$ro/TMPL_IF \
! -t TMPL_VAR NAME=fsType \
! TMPL_VAR NAME=options \
- ! TMPL_VAR NAME=device \
- ! TMPL_VAR NAME=target
+ ! 'TMPL_VAR NAME=device' \
+ ! 'TMPL_VAR NAME=target'
END SCRIPT
END TEMPLATE
diff -urN -x {arch} -x .arch-ids -x configure -x aclocal.m4 -x depcomp -x
missing -x Makefile -x Makefile.in -x install-sh -x INSTALL
p73/templates/Debian-initrd.cfg p74/templates/Debian-initrd.cfg
--- p73/templates/Debian-initrd.cfg 2005-10-24 23:51:03.0 +0200
+++ p74/templates/Debian-initrd.cfg 2005-10-24 23:50:57.0 +0200
@@ -382,8 +382,8 @@
! TMPL_IF NAME=isRoot$ro/TMPL_IF \
! -t TMPL_VAR NAME=fsType \
! TMPL_VAR NAME=options
Bug#335230: [#335230] How to actually support EVMS in an initrd
On Sun, Oct 23, 2005 at 01:07:26PM +0200, Mattia Dongili wrote: On Sat, Oct 22, 2005 at 10:01:02PM +0200, Sven Luther wrote: On Sat, Oct 22, 2005 at 09:47:12PM +0200, Marco Amadori wrote: Alle 21:18, sabato 22 ottobre 2005, Steinar H. Gunderson ha scritto: EVMS support in yaird should not be difficult to add for someone who already knows yaird. Basically, what you need to do is: We need a perl hacker. Mattia, maybe you would like to jump in here too ? I hope i am not abusing by asking you that :) Oh, well, I'd really like to :) Only problem I have is that I don't have any EVMS system available. I'm going to see if I have enough spare HW parts to build a pc and set it up but it might take some time... And to avoid stepping on anybody's feet, Erik, aren't you interested? As I see you are the author of yaird :) Yep, I'm interested; plan to participate in discussions, test and merge results in next release. However, that doesn't mean I'm the only one who can talk about the use of perl in yaird. If you and Marco come up with something good, i don't consider that stepping on my feet ... Regards, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335315: yaird: vgchange does not find logical volumes on a dm-crypt device
On Sun, Oct 23, 2005 at 12:20:04PM +0200, Tino Keitel wrote: my root partition is located in a LVM2 on a dm-crypt device. vgchage doesn't find any VGs during boot. The reason is that vgchange doesn't look for VGs on other device mapper devices per default. To enable this, this line has to be added to /etc/lvm/lvm.conf: types = [ device-mapper, 1 ] I modified /etc/yaird/Templates.cfg and added the line FILE /etc/lvm/lvm.conf which contains the types option above, and now the initrd finds the VG. However, it bails out later with usr/lib/yaird/exec/run_init: opening console: No such file or directory, but that's another story. Hmm, I'm reluctant to add /etc/lvm/lvm.conf to the boot image. It's possible to put stuff in that config file that makes no sense on a boot image. That said, I don't see a more robust approach. I'll test it on a box with lvm and no dm-crypt for 0.0.12. --erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335264: yaird fails with older (titanium) powerbooks.
On Sun, Oct 23, 2005 at 01:31:54AM +0200, Sven Luther wrote: On my titanium powerbook, yaird fails with : yaird error: unrecognised device: /sys/devices/pci0001:10/0001:10:17.0/0.8000:mac-io yaird error: unrecognised device: /sys/devices/pci0001:10/0001:10:17.0/0.8000:mac-io/0.0001f000:ata-4 Well, those are non-fatal errors, and the mac-io is just a super-controller kind of thingy sitting on the pci bus, and holding the ata-* devices, which in turn have ide0 or ide1 subdirs, which are the ones given in the path. Now, there are two problems, first is that we should harmlessly recognize those above, provided in the attached patch, well not sure about the exact syntax of the comment, but this should do, and i added a small typo-fixing in the above comment :). OK, I copied Jonases 0.0.11-7 version of this for 0.0.12. The second problem is that since the initrd is generated correctly, those non-harmfull errors should maybe not cause mkinitrd.yaird to return and error code of 1 and thus fail, not sure though. That was a conscious decision: we dont recognise the syntax of the device name, so there's no reason to suppose that device does not need a module, so no reason to suppose that an image without module would boot. Exit 1 is the only honest result nder those circumstances. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335230: [#335230] How to actually support EVMS in an initrd
On Sat, Oct 22, 2005 at 09:54:54PM +0200, Steinar H. Gunderson wrote: On Sat, Oct 22, 2005 at 09:47:12PM +0200, Marco Amadori wrote: - Make sure /dev/ is writable, and mkdir /dev/evms. Translate this in perl plz :-) Well, the make sure part depends on how yaird works. You may have to mount a tmpfs over /dev/evms if the initrd is read-only. (This is during _boot_ time, BTW; running /sbin/evms_activate at yaird time will help you nothing.) Agreed. Note: the initramfs generated by yaird has a writable /dev at an early stage. As an aside: there will be one case where the tryEvms() function will need to enable a disk even though root is not evms: the case where swap is used for swsusp, swap is on evms and root is not. --erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329319: swsusp2 in initramfs risks disk corruption
Changing the init script to do swsusp is easy, but without other changes you risk data corruption; see for references http://www.suspend2.net/HOWTO-4.html A more robust solution requires not replaying the journal from initramfs in logbased filesystems. libblkid helps here. I'm still examining the possibilities. Regards, 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 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: Hey, i didn't know the mkinitrd wrapper was shell, or i would have done it myself. I wonder why you need the : if [ $supported_host_version != ] though, since by default, it will test for an empty string, so this seems redundant, but maybe there is some obscure shell thingies i am not aware of. As Jonas suspected, it's coding style. This notation works correctly even if the variable happens to contain -x; furthermore, this notation does not require the reader to grok the difference between -n (null string) and -z (zero string). The patch claims support for 2.6.8, which is where development started, but later yaird versions only have had testing with newer kernels. If we could get away with claiming a later version, that can only reduce number of bug reports. Not a good idea, 2.6.8 is the sarge kernel, and it should be best to keep at least 2.6.8 host systems in the compatibility list, for sarge26 - etch upgrades. Not sure about target system, anything below 2.6.12 is rather academic there. Agreed with Jonas here: stick with 2.6.8; reconsider if that becomes too limiting. Also, i would like to hear your comments on the yaird-using sarge24 - etch upgrade path ? Though one, but cannot be avoided forever. One of the reasons why yaird can be simple in principle (if not in implementation ...) is that it does not bother with 2.4 compatibility. In particular, it needs /sys to do analysis. 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 one relies on using initrd-tools or mkinitramfs for the 2.4-2.6 step; it's probably quickest. The second one is more interesting: to build a boot image that works on any machine, you don't have to analyse /sys. You need such a boot image for the d-i, and it would help in migrating away from initrd-tools. The generated image would be very similar to what mkinitramfs does; it's not obvious that extending yaird to do this has real advantages over just using mkinitramfs in this context. BTW: I'm happy to see you'll move the yaird packaging to Alioth, that should give more continuity than a TLA archive I keep at home. :) I'll react to this part in reply to Jonases mail. Regards, 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#333196: Default settings for yaird are unsuitable for initrd replacement.
On Mon, Oct 10, 2005 at 10:47:21PM +0200, Sebastien Bernard wrote: Yaird package has a poor choice for default Template.cfg. 2 different set of files are provided in the /usr/lib/yaird/conf directory. One named Debian.cfg (the Template.cfg is a copy of this file). One named Debian-initrd.cfg. The default Template.cfg make yaird generate an initrd file with a /init script making it usuitable for initrd replacement (at least using the cramfs format), but correct for a initramfs file. To use yaird as a replacement of the initrd-tools, one has to replace Template.cfg with the Debian-initrd.cfg file generating a /linuxrc suitable for booting the initrd file. My machine needs an initrd to mount the lvm2 root filesystem. And without doing the described modification, there is no way to generate a correct file. But why do you want to use the initrd format? Initramfs boots a Debian system just as well, and will have more support in future kernels. Regards, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327762: yaird: includes (unnecessary?) psmouse module in generated image.
On Sun, Sep 11, 2005 at 09:16:42PM -0300, Diego Essaya wrote: I may be wrong, but I think that the 'psmouse' module is unnecessary. In fact, I don't have a PS/2 mouse (I have a USB one). The 'evdev' and 'mousedev' modules may be unnecessary as well... In the meantime 0.0.11 is published, which makes it easier to play with what modules are used. Look at /usr/lib/yaird/conf/Default.cfg, but beware that this is not yet marked as a configuration file, so any changes made there will be overwritten by a new release. You can specify an alternative config file on the command line. The cause: yaird looks for keyboard devices in /proc/bus/input/devices, finds /sys/class/input/event0, with a link to the underlying hardware: /sys/devices/platform/i8042/serio1. Then we load required modules for the hardware. Platform? Nothing special. i8042? Just the i8042 module. Serio1? Hmmm, could be a psmouse, could be atkbd; lets load both. This is ugly: the fact that serio does not have the nicely coordinated vendor/product codes you find in USB or PCI devices makes it difficult to do good detection. Could we use 'driver' link in .../serio1 to find the appropriate device driver? Only if (a) the driver has same name in running and new kernel, and (b) driver is modular in running kernel. Not reliable enough. Note that older kernels ( 2.6.10?) don't have the device link in /sys/class/input/event0, in which case some fallback logic in yaird becomes active: if /proc/bus/input/devices talks about keyboard, it's probably atkbd. The psmouse stuff doesn't happen in this case. For 0.0.12, I plan to look at 'softrepeat' and 'resolution' files in serioX sysfs directory; this distinguishes nicely between atkbd and psmouse device, and it should break *visibly* for exotic stuff like newton kbd, which is an improvement over the current approach of load atkbd and hope for the best. Regarding evdev and mousedev: you don't need these to boot the system, but if mouse or keyboard is loaded from initramfs rather than /etc/init.d, you no longer can assume evdev and mousedev get sucked in as a side-effect, and they are probably needed: evdev is what allows yaird to find the keyboard, mousedev is expected by X-Windows. It would probably be more straightforward to load them from /etc/modules, but that would require manual intervention by the sysadm: the system no longer works out of the box for common configurations. Lets not do that. Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325768: yaird: can't open blacklist /etc/hotplug/blacklist (fatal)
On Wed, Aug 31, 2005 at 03:32:19AM -0500, Peter Samuelson wrote: [Erik van Konijnenburg] The upstream 0.0.11 tarball has the attached fix to make the blacklist optional; workaround obvious. I hope it's not *exactly* the attached fix: - parseBlackList ($hotplugDir/blacklist); + my $blackListName = hotplugDir/blacklist; Need a $ there. Arghh. And because the whole point of the change is to make yaird silent if there's no blacklist this error did not raise any alarms while testing ... I'll prepare a corrected deb file. Thanks, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325768: yaird: can't open blacklist /etc/hotplug/blacklist (fatal)
On Tue, Aug 30, 2005 at 02:58:12PM -0500, Peter Samuelson wrote:
I don't have a /etc/hotplug/blacklist file. I do have a
/etc/hotplug/blacklist.d/ which other packages have installed things
into. Since I don't have hotplug installed, I am not sure if hotplug
is supposed to create and maintain this file, or what.
If yaird cannot cope without a /etc/hotplug/blacklist file, it probably
ought to declare a dependency on hotplug. Even better would be not to
require this file at all, and to read /etc/hotplug/blacklist.d/*.
Thanks for reporting this issue.
The upstream 0.0.11 tarball has the attached fix to make the blacklist
optional; workaround obvious.
Note that even if you don't have hotplug, you may want to create a blacklist
file if you find that yaird includes more modules than you want.
Regards,
Erik
--- aap/usr/lib/yaird/perl/Blacklist.pm 2005-08-03 16:24:05.0 +0200
+++ noot/usr/lib/yaird/perl/Blacklist.pm2005-08-25 21:33:36.0
+0200
@@ -36,7 +36,17 @@
}
my $blackMap = {};
my $hotplugDir = Conf::get ('hotplug');
- parseBlackList ($hotplugDir/blacklist);
+ my $blackListName = hotplugDir/blacklist;
+ if (-e $blackListName) {
+ # The blacklist does not have to exist:
+ # there are machines without hotplug,
+ # and blacklist support in hotplug is
+ # likely to be replaced with a keyword in
+ # the module-init-tools config file.
+ # If it does exist, but is unreadable,
+ # that's an error.
+ parseBlackList ($blackListName);
+ }
my $dir;
my $dirName = $hotplugDir/blacklist.d;
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324774: yaird: does not work with current mdadm
On Tue, Aug 23, 2005 at 07:03:49PM -0400, Daniel Jacobowitz wrote: When I installed a kernel using yaird to create the ramdisk, I got an error that there were no listed devices in the mdadm output. I edited RaidTab.pm to invoke mdadm with -v (--verbose), and then things seemed to work OK. Hi Jonas, a fix is waiting at the familiar location for QA and upload. It follows the ideas discussed earlier in this tread, so people hit by this bug before the updated version hits the mirrors can use the workaround found by Daniel. Regards, Erik. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324774: yaird: does not work with current mdadm
On Tue, Aug 23, 2005 at 07:03:49PM -0400, Daniel Jacobowitz wrote: When I installed a kernel using yaird to create the ramdisk, I got an error that there were no listed devices in the mdadm output. I edited RaidTab.pm to invoke mdadm with -v (--verbose), and then things seemed to work OK. Thanks for pointing this out. Some working notes: * between 1.9.0 and 1.12.0 the devices=... got dropped from normal mdadm output. * that's desirable behaviour, since the old format promotes overspecified and fragile mdadm.conf files. * in 1.12.0, -v produces devices=... In 1.9.0, -v produces far more verbose output, that 1.12.0 generates with -v -v. * in the upstream package, I cannot simply ignore devices=..., since it determines which hardware drivers need to be loaded. * in the upstream package, I don't want to require mdadm = 1.12.0, since other distros have earlier versions. (fedora seems to use 1.6.0) * parsing the mdadm -v -v -v output is a pain; much too verbose. * The cleanest solution seems to be to first try mdadm without -v, and if that doesn't yield devices=... to retry with -v option. Regards, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317504: Spurious build-dependency on build-essential
On Sat, Jul 09, 2005 at 12:43:17PM +0200, Jonas Smedegaard wrote: On 09-07-2005 09:56, Jeroen van Wolffelaar wrote: Package: yaird Severity: normal Your package has a spurious build-depends on build-essential. Build-essential packages are already guaranteed to be installed, and the build-essential packages doesn't add something useful to your package's build process. Uh - ok. Thanks for noticing. The dependency is inserted by CDBS generating the control file (if DEB_AUTO_UPDATE_DEBIAN_CONTROL is set) and is indeed spurious. It is caused by a bug in CDBS, #316034. That bug report includes a patch. I propose - marking this as a duplicate of 316034 - not building a new yaird package for this issue alone. - manually fixing the spurious dependency in future yaird updates until CDBS is fixed. Jonas? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315549: kernel-image-2.6.8-2-sparc64: Fails to recognize and start md2 during boot
On Thu, Jun 23, 2005 at 02:50:32PM +0200, Henrik Stoerner wrote: Package: kernel-image-2.6.8-2-sparc64 Version: 2.6.8-15 Severity: normal This kernel fails to recognize all LVM RAID-1 devices. It will automatically detect md0 and md1, but fails to detect md2. During bootup it therefore fails to mount the filesystem on this partition and drops to a console prompt. Running mdadm --assemble /dev/md2 /dev/sda5 /dev/sdb5 correctly recognizes and starts the md2 device, and I can bootup normally. The initrd only starts root and swap md devices, the rest is started automatically by /etc/init.d/mdadm-raid, *IF* you set AUTOSTART=true in /etc/default/mdadm. This is by design. 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 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#273182: a possible fix/workaround
On Sat, May 21, 2005 at 05:35:48PM +0200, martin f krafft wrote:
- 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.
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.
The problem is that users are not aware that this configuration option
exists, giving rise to repeated bug reports, so you want to create the
device regardless of config setting.
Mdadm provides the --auto commandline option for that, but it turns out
that the absense of auto=md in the config file overrules the command line,
so it's useless in practice.
The attached patch changes this, so that --auto works regardless of command
line settings, like so:
# rm /dev/md0
rm: cannot remove `/dev/md0': No such file or directory
# cat /etc/mdadm/mdadm.conf
DEVICE partitions
ARRAY /dev/md0 level=raid1 num-devices=2
UUID=85318365:3b91c827:faee55c7:b1d96199
# /sbin/mdadm -A -s -a
mdadm: error opening /dev/md0: No such file or directory
# ./mdadm -A -s -a
mdadm: /dev/md0 has been started with 2 drives.
# ls -l /dev/md0
brw--- 1 root root 9, 0 2005-05-21 19:06 /dev/md0
#
With this modification, you no longer need the tests for /dev/.udevdb etc,
and can simply say $MDADM -A -s -a in /etc/init.d/mdadm-raid.
Regards,
Erik
--- mdadm-1.9.0/mdadm.c 2005-05-21 18:48:49.0 +0200
+++ mdadm-1.9.0-hack/mdadm.c2005-05-21 18:45:04.0 +0200
@@ -732,7 +732,7 @@
devlist-devname);
rv |= 1;
} else {
- mdfd = open_mddev(devlist-devname,
array_ident-autof);
+ mdfd = open_mddev(devlist-devname, (autof ?
autof : array_ident-autof));
if (mdfd 0)
rv |= 1;
else {
@@ -759,7 +759,7 @@
rv |= 1;
continue;
}
- mdfd = open_mddev(dv-devname,
array_ident-autof);
+ mdfd = open_mddev(dv-devname, (autof ? autof :
array_ident-autof));
if (mdfd 0) {
rv |= 1;
continue;
@@ -777,7 +777,7 @@
} else
for (; array_list; array_list =
array_list-next) {
mdu_array_info_t array;
- mdfd = open_mddev(array_list-devname,
array_list-autof);
+ mdfd = open_mddev(array_list-devname,
(autof ? autof : array_list-autof));
if (mdfd 0) {
rv |= 1;
continue;
--
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 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#310126: mdadm auto processing with patch
Package:mdadm
Version:1.9.0-2.1
Severity: wishlist
The mdadm package can automatically create device files when
assembling drives, provided the auto=md or auto=part7 option
is added to the relevant drives in the configuration file.
It turns out these configuration options are often forgotten
by users, with the result that the mdadm init.d script will
not create these devices, causing bug reports such as #273182.
Thus, there is a need to automatically create these devices
even if that's not specified in the config file.
There is a command line option to do this (mdadm -A -a /dev/md0),
but in combination with the --scan option this does not work.
The reason is that the absence of auto= in config file overrules
the presence on the commandline. The attached patch changes this
by making the command line --auto option a default for the
configuration file option.
The interaction with auto=md vs auto=part is worth noting.
In the config file, auto values yes and md mean that
a non-partitionable device must be created; this is represented
in core with '-1'. No and absense of the option mean not to
generate a file; represented by '0'. part, mdp, or part7
mean that a partitionable device must be created, represented
by a a positive number that indicates how many partitions are needed.
On the command line, yes and md are not the same. yes means
that the type must be derived from the filename, (represented by -2),
md (is -1) asks explicitly for non-partitionable device. Like the
config file, auto=part3 is represented by a positive number. On the
command line, --auto without '=' is interpreted as --auto=yes.
The patch uses the config file value if it differs from no/absent (0),
the command line value otherwise:
(array_ident-autof ? array_ident-autof : autof));
This means auto=part7 in the config file will overrule a --auto=yes
on the command line.
It also means auto=no in config file is now overridden by --auto=yes.
This differs from previous behaviour, and can't be changed without
changing the representation of auto in RAM. Let's call this an improvement
rather than a bug.
For devices such as /dev/md-root, the auto=md option in the config file
remains mandatory, since mdadm cannot determine whether partitioning
is necessary based on the file name. If the option is absent, a suitable
error message is produced.
As an aside, if this patch works OK, it may make sense to have udev
ignore md devices. That would help in moving from kernel names
(/dev/md0) which are determines by probing order toward symbolic names,
(/dev/md-root) which can be specified based on UUID, and are independent
of the orde in which hardware is detected.
Note that this is lightly tested: interactive use only, test in combination
with a revised init.d script.
Regards,
Erik
--- mdadm-1.9.0/mdadm.c 2005-05-21 18:48:49.0 +0200
+++ mdadm-1.9.0-hack/mdadm.c2005-05-21 20:57:12.0 +0200
@@ -732,7 +732,8 @@
devlist-devname);
rv |= 1;
} else {
- mdfd = open_mddev(devlist-devname,
array_ident-autof);
+ mdfd = open_mddev(devlist-devname,
+ (array_ident-autof ?
array_ident-autof : autof));
if (mdfd 0)
rv |= 1;
else {
@@ -759,7 +760,8 @@
rv |= 1;
continue;
}
- mdfd = open_mddev(dv-devname,
array_ident-autof);
+ mdfd = open_mddev(dv-devname,
+ (array_ident-autof ?
array_ident-autof : autof));
if (mdfd 0) {
rv |= 1;
continue;
@@ -777,7 +779,8 @@
} else
for (; array_list; array_list =
array_list-next) {
mdu_array_info_t array;
- mdfd = open_mddev(array_list-devname,
array_list-autof);
+ mdfd = open_mddev(array_list-devname,
+ (array_list-autof ?
array_list-autof : autof));
if (mdfd 0) {
rv |= 1;
continue;
--
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#304483: mkinitrd does not create mdadm -A record for /boot partition on raid1 when initrd.img is built
On Thu, May 19, 2005 at 05:50:06AM -0700, rds wrote: Quick question: why not add an auto=md clause to /etc/mdadm/mdadm.conf? That way you have the option of *not* assembling some md drives if necessary. 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. Oops, there's indeed one other point you'll need to check: you'll also need to make sure AUTOSTART is set correctly in /etc/default/mdadm. As Maks pointed out, the idea is that initrd only activates the md devices needed to boot. /etc/rcS.d/S04mdadm-raid can then activate the rest of the devices, (and optionally mknod(2) them as well) in time for S10checkroot and S30checkfs. Note that md does not create udev events, only md devices that exist at the time initrd ends are passed to udev by udevstart and get a rule applied, for the rest you'll need auto=md, although you can sometimes get away with omitting that due to a rather odd interaction between LVM, devfs on the initrd and udev. I made some notes on this issue, see http://www.xs4all.nl/~ekonijn/yaird/yaird.html#raid. Not for sarge, but I think the optimal approach would be: 1. make auto=md the default when installing a debian system with mdadm. 2. let udev ignore md devices. This would achieve: - user can decide which devices are activated automatically and which are not. - devices can get a symbolic name (/dev/md-root) based on UUID, rather than a name /dev/mdX that depends on detection order. - end to the inconsistency between devices accessed by initrd and the rest. Regards, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#304483: mkinitrd does not create mdadm -A record for /boot partition on raid1 when initrd.img is built
On Thu, May 19, 2005 at 06:39:35PM -0700, rds wrote: --- Erik van Konijnenburg [EMAIL PROTECTED] wrote: Oops, there's indeed one other point you'll need to check: you'll also need to make sure AUTOSTART is set correctly in /etc/default/mdadm. Tied a couple of changes with the following results (I'm not using udev): # cat /etc/default/mdadm # This file is automatically generated. # Run 'dpkg-reconfigure mdadm' to modify it. START_DAEMON=true MAIL_TO=root AUTOSTART=false // or true, tried both You'll need 'true' here. # cat /etc/mdadm/mdadm.conf auto=md This is Likely to be the problem: add auto=md to every ARRAY line where you want /dev/mdX to be created, not as a separate line; see man mdadm.conf(5). Regards, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#304483: mkinitrd does not create mdadm -A record for /boot partition on raid1 when initrd.img is built
On Wed, May 18, 2005 at 04:52:55PM -0700, rds wrote: Re: Bug#304483: mkinitrd does not create mdadm -A record for /boot partition on raid1 when initrd.img is built i'm a bit puzzled why you expect from initrd to mount all the mdadm partitions, from your report i see that the initrd is loaded and booted. it also seems to find your root device. seems more a failure of mdadm to bring up all your raid? The /boot partition is on /dev/md1 which is mdadm RAID1 array. I would expect that initrd assembles the /dev/md1 array when the system boots, right? It does assemble /dev/md2 (/) and /dev/md3 (swap), but not /dev/md1. As a result, fsck on /boot (which hosted on /dev/md1) fails and normal system's boot-up sequence stops. I had to disable fsck on /boot to bring up the system. And after that I have to assemble /dev/md1 and mount it to /boot MANUALLY EVERY TIME I REBOOT THE SYSTEM. Please let me know if you need any other info. Quick question: why not add an auto=md clause to /etc/mdadm/mdadm.conf? That way you have the option of *not* assembling some md drives if necessary. Regards, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295412: initrd-tools: Fails to ignore 32bit emulation layer on ldd calls
On Wed, Feb 23, 2005 at 05:58:59AM +0100, Harald Dunkel wrote: Joshua Kwan wrote: Harald Dunkel wrote: Assuming that valid shared library paths start with '/' I would suggest to apply this patch to mkinitrd: Hmm, maybe not if LD_LIBRARY_PATH is being used. Beware. ??? I am not sure whether searching dynamic libraries relative to either the $CWD or to the bin directory is a good idea, especially for system tools. Agreed. Your proposed patch is certainly much cleaner than grepping linux-gate away. If I understand the linux-gate concept correctly, its an area of memory mapped into application process space not based on a segment in an object file, but based on a prototype the kernel provides. What mkinitrd should recognise is that there's no file listed that the shared library resolves to. A pattern such as / = \(0x/ should recognise these cases and still maintain current behaviour with regard to LD_LIBRARY_PATH. Incidentally, there may be another ldd related bug waiting to happen. Currently, mkinitrd accepts ldd 2.3.2 output that look like this: /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0xb7fea000) But in ldd 2.3.3, that output format will change to this (tested in Fedora FC3): /lib/ld-linux.so.2 (0x0056f000) Perhaps that pattern should also be matched. Regards, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#281591: cannot hit Return at DELAY prompt on SunBlade 100
On Sat, Feb 19, 2005 at 07:00:31PM +0100, Frans Pop wrote: It is not very likely that this is an initrd-tools problem. We have several installation reports for SunBlade 100 that mention that the USB keyboard does not work correctly after booting debian-installer. So it is much more likely that there is a more general problem with kernel support for USB keyboards on these machines. We really need someone who has a machine like that to trace this... Cheers, FJP AFAICS, Debian mkinitrd does not automatically load the usbhid module, needed to access the keyboard, and I don't see usbhid or the prerequisite controller listed in the script listed earlier in this report. To work around this, add usbhid and ehci, ohci or uhci to /etc/mkinitrd/modules; of course the more general kernel problem may also exist. If you're interested in adding USB kbd support to mkinitrd, I'm working on a perl based alternative mkinitrd implementation that handles USB keyboard. The logic used there is not conveniently expressed as a shell script, but as a rough approximation, if [ `ls -l /sys/class/input/event*/device | grep /usb | wc -l` != 0 ] then add usb_core, uhci_hcd, ohci_hcd, ehci_hcd, usbhid fi should be mostly correct. http://www.xs4all.nl/~ekonijn/yaird/yaird.html 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
Pulling for now seems indeed the best option. I'm closing the #290145 report with suggested patch; it's obviously not what's needed. Based on reading of mkinitrd, the extension scripts are invoked as the very last action in mkinitrd. LVM is special-cased in the main body; thus your extension script can't act before the code generated for LVM. Extending initrd-tools for multipath-tools could be done as follows: Let multipath-tools depend on dmsetup. Having a multipath device causes mkinitrd to invoke dmsetup, and initrd-tools also runs in environments where everything is on a single IDE disk, so having the dependency in initrd-tools would needlessly bloat simple desktop installs. In mkinitrd, the getroot() function looks at devices and decides how to make them operational. For device-mapper devices, it invokes dm(), which uses `dmsetup table` to determine whether it's a crypt device or LVM. This function would need to be extended to recognise multipath. You then need a function to generate script code for multipath; dmcrypt() is a good example. This does the following: - invoke getroot() on underlying devices - echo required modules to file descriptor 1 - echo required files to fd 4 - echo required script fragment to fd 5 - echo names of required executables and libraries to fd 6 Regards, Erik On Thu, Jan 13, 2005 at 01:59:22PM +0100, Guido Guenther wrote: On Wed, Jan 12, 2005 at 11:02:50PM +0100, Erik van Konijnenburg wrote: 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. Uargh, that is very bad. We should run the multipath stuff before the LVM stuff anyway since you most likely want LVM over the multipath (if not you're of corse still free to do so). I'll have to have a look at the scripts of 0.4.2 to see if we can do this easily. Until then it would probably be best to pull the initrd related parts from multipath-tools again since they seem to cause quiet some trouble at the moment and are only needed if your root device is multipathed. Cheers, -- Guido -- 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]
