Bug#791631: src:linux: Please enable CONFIG_MOUSE_ELAN_I2C
Package: src:linux Version: 4.0.2-1 Severity: normal Dear Maintainer, the Debian kernel seems to exclude the ELAN I2C Touchpad support for some reason (needed for e.g. Acer C740 touchpads). Please consider enabling MOUSE_ELAN_I2C, MOUSE_ELAN_I2C_I2C and MOUSE_ELAN_I2C_SMBUS (presumably in debian/config/kernelarch-x86/config?) -- David Härdeman -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150707002245.ga12...@hardeman.nu
Bug#481104: [Pkg-cryptsetup-devel] /usr/sbin/update-initramfs: update-initramfs edits /etc/initramfs-tools/conf.d/cryptroot
On Wed, July 9, 2008 10:51, Giorgos D. Pallas wrote: David Härdeman wrote: ... (why do you have a cryptroot file by the way? It's supposed to be a cryptsetup internal config file) If I understood your question well, my answer is this: I have /etc/initramfs-tools/conf.d/*cryptroot containing the line: **target=lukspace,source=/dev/hda3,key=none,lvm=vg-root* because I have my root partition sitting on LVM, which sits on LUKS. So, somehow the initrd image must know that it has to find a LUKS partition and ask me for its passphrase. I hope I'm not talking nonsense. When I tried to set up encrypted root partition, I used googling, a bit hacking and imagination. So, there is the possibility that an easier method eludes me. Yes, the correct method would be to create a /etc/crypttab file with the mapping for your root device. See the documentation in /usr/share/doc/cryptsetup for details on how to do that. Once a proper crypttab is setup, cryptsetup will automagically generate initramfs config files for you. -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#481104: [Pkg-cryptsetup-devel] /usr/sbin/update-initramfs: update-initramfs edits /etc/initramfs-tools/conf.d/cryptroot
On Fri, Jul 04, 2008 at 11:56:59PM +0200, maximilian attems wrote: Look at that: (updating initrd, duplicates the content of the cryptroot config file...) right cryptsetup should maybe not write into /etc/i-t/conf.d but in /usr/share/i-t/conf.d but those could also be mounted ro?!? anyway i'd like to hear from cryptsetup maintainers before reassgning. I'm not sure I understand the question. The cryptsetup initramfs hook writes its config file by doing: echo $OPTIONS $DESTDIR/conf/conf.d/cryptroot If that is below /etc, that would be due to initramfs-tools, wouldn't it? -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#485789: initramfs-tools: With crypted LVM, tries to start LVM before decryption
On Wed, June 11, 2008 15:26, Martin Michlmayr wrote: Adding Max Vozeler and David Härdeman to the CC. * Didier Raboud [EMAIL PROTECTED] [2008-06-11 15:06]: ... I installed LennyBeta2 (under Qemu) with the graphical installer and chose crypted LVM. The thing is that on boot, the initramfs firstly tries to open (initiate ?) the LVM before it actually has access to it (because it is encrypted). It results in an error (attached) which could be avoided if the encrypted partition is opened before the LVM is initiated. It's intentional (although not very aesthetic). The cryptsetup initramfs scripts allows all other disk-related scripts to run first since you could have an encrypted LVM volume as well as LVM on an encrypted volume. After setting up the encrypted volume, the cryptsetup initramfs scripts will then perform the LVM/EVMS/etc setup when necessary. So the process is more like this: 1) LVM/EVMS/md/etc 2) cryptsetup 3) LVM/EVMS/md/etc -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465812: [Pkg-cryptsetup-devel] Bug#465812: linux-image-2.6.22-3-686: [Regression] LuKS passphrase not accepted anymore
On Fri, Feb 15, 2008 at 10:16:06PM +0100, Jonas Meurer wrote: On 15/02/2008 Martin Ammermüller wrote: On Friday 15 February 2008 17:23:39 maximilian attems wrote: On Fri, 15 Feb 2008, Martin Ammermüller wrote: Tried that for 2.6.22-3-686 and 2.6.24 with no effect. And I'm pretty sure that i didn't enter the passphrase wrong :) (works still with 2.6.22-2, did not try my luck with update-initramfs on this kernel-image, though). well then it can only be a cryptetup bug of newer version. as newer cryptsetup land on both of those. Looks like the keyboard-layout isn't set up correctly. I run etch installer with german keyboard layout. If I enter the passphrase like my keyboard had an english layout, it works with linux-image 2.6.24. I also did a diff of initrd.img from 2.6.22-2 and 2.6.22-3. /bin/kbd_mode as well as /bin/loadkeys are missing in initrd.img-2.6.22-3: David, can you take a look at this one? What exactly is responsible for putting kbd_mode and loadkeys into the initramfs? A brief search through the cryptsetup initramfs scripts/hooks gave no result, so I doubt that that's the source for the problem. But you should know more ;-) cryptsetup used to have code for adding stuff for keyboard setup. That code was moved into initramfs-tools and it should be activated by the cryptsetup/trunk/debian/initramfs/cryptroot-conf file which should be installed to /usr/share/initramfs-tools/conf.d. It seems that SVN commit 433 moved that file to /usr/share/initramfs-tools/conf-hooks.d. I'm not sure what the difference between the two directories are, but perhaps the newer location is only supported by a newer initramfs-tools version? -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-cryptsetup-devel] Bug#464673: cryptsetup seems to try to load some padlock modules
On Sun, Feb 10, 2008 at 01:58:34AM +0100, Jonas Meurer wrote: On 08/02/2008 Joachim Breitner wrote: I’m not sure about his. I am pretty sure the error messages came _after_ I entered the password the first time, but _before_ cryptsetup exits, which I noticed when I entered the password wrong the first time, and the second prompt came after the error messages. I’ll make sure this observation is correct at the next boot. Also, fgrepping the contents of my initramdisk for padlock, I only get: ./lib/modules/2.6.24-1-686/kernel/drivers/crypto/padlock-aes.ko. ./lib/modules/2.6.24-1-686/kernel/drivers/crypto/padlock-sha.ko. ./sbin/cryptsetup. ./usr/lib/libcrypto.so.0.9.8. so no script is manually loading these. Still some script adds the modules to you initramdisk, but i'm not sure whether this is initramfs-tools (update-initramfs) or some thirdparty script. Maybe you could add some debugging code to /usr/share/initramfs-tools/scripts/local-top/cryptroot and/or /usr/share/initramfs-tools/hooks/cryptroot? David, could you give further advice? /usr/lib/libcrypto.so.0.9.8 comes from the openssl package. The openssl package changelog says: openssl (0.9.8e-1) unstable; urgency=low ... - Load padlock modules (Closes: #345656, #368476) ... So it seems that the openssl library might be responsible for loading the padlock modules. As to why they are included in the initramfs image in the first place, the cryptsetup initramfs hook uses the initramfs-tools function manual_add_modules to add modules to the initramfs image. manual_add_modules checks module dependencies with modprobe, so if the cryptsetup hook calls manual_add_modules aes, the following is executed by that function (this example is for the Debian 2.6.24 kernel): modprobe --set-version=2.6.24-1-686 --ignore-install --show-depends aes which gives this output: insmod /lib/modules/2.6.24-1-686/kernel/crypto/aes_generic.ko insmod /lib/modules/2.6.24-1-686/kernel/crypto/blkcipher.ko insmod /lib/modules/2.6.24-1-686/kernel/drivers/crypto/geode-aes.ko insmod /lib/modules/2.6.24-1-686/kernel/crypto/blkcipher.ko insmod /lib/modules/2.6.24-1-686/kernel/drivers/crypto/padlock-aes.ko insmod /lib/modules/2.6.24-1-686/kernel/arch/x86/crypto/aes-i586.ko And all of those modules are added as a result. I think the next step would be to get some feedback from Maximilian. -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-cryptsetup-devel] Bug#456032: Bug#456032: Processed: Re: Bug#456032: Ping; just making sure this bug was noted after moved to initramfs-tools (debian-kernel list)
On Sat, Jan 19, 2008 at 01:35:00AM +0100, Jonas Meurer wrote: On 20/12/2007 maximilian attems wrote: On Thu, 20 Dec 2007, David Härdeman wrote: Maks: if the disks do appear later, wouldn't that indicate a bug in udevsettle returning before the RAID card is done initalizing (or a bug in the driver for the card...perhaps it should support scsi_wait)? I'm not sure what cryptsetup should/could do about it. yeah, good reminder to push scsi_wait. so what can we do in the cryptsetup package? is this a bug in cryptsetup at all, or may i close this bugreport? Kernel changes are needed. Kernel devs are aware changes are needed. Theoretically the bug could be reassigned to the Debian kernel packages, but I doubt that would be very helpful. So I suggest the BR be closed. -- David Härdeman
Re: [Pkg-cryptsetup-devel] Processed: Re: Bug#456032: Ping; just making sure this bug was noted after moved to initramfs-tools (debian-kernel list)
Daniel said in the BR: Installation succeeded however on reboot the encrypted LVM partition was not activated. The messages during startup (after install), were: Setting up cryptographic volume sdb1_crypt (based on /dev/sdb1) cryptsetup: Source device /dev/sdb1 not found The system then reports on megaraid logical disks (appearing as sda, sdb) and then hangs (but responds to keyboard and reboots with Ctrl-Alt-Del) Maks: if the disks do appear later, wouldn't that indicate a bug in udevsettle returning before the RAID card is done initalizing (or a bug in the driver for the card...perhaps it should support scsi_wait)? I'm not sure what cryptsetup should/could do about it. Daniel: a workaround you might want to try is to boot with the rootdelay option, for example rootdelay=10 should give your card 10 seconds to catch up before cryptsetup and the other scripts are executed. -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#422255: [etch] Installing with root on JFS in LVM fails
On Fri, May 11, 2007 1:38, Frans Pop said: The second was using an Etch netinst image, and there I can reliably reproduce the hangs you are seeing. They seem to occur during the unpacking of tarballs. At least, in both cases the last command that is visible in the output of 'ps' is tar -xf - (obviously a pipe from another command). I've seen two hangs (in different installs): - one at 31%; ps shows: zcat /usr/lib/debootstrap/devices.tar.gz | tar -xf - - one at 28% extracting tzdata; no 'zcat' visible in ps, just: tar -xf - (in state D) State D is Uninterruptible sleep (usually IO); there is no processor activity; killing processes does not help, the system remains frozen. I've also tried a normal install (no crypto, no LVM) with / on jfs, and that succeeded without problems. However, with jfs on / using LVM without crypto, I can also reproduce the problem, so the fact that encryption was used is irrelevant. The issue seems to be with using jfs in LVM (or maybe jfs with device-mapper). It does look like we've got a kernel issue here in the 2.6.18 kernel that has apparently been fixed in 2.6.20. Perhaps it's a kernel stack overflow issue? I remember there being a lot of fixes going into the kernel to reduce stack usage when the stack was reduced to 4kB and that many of the patches were against stacked filesystems (e.g. anyfs-on-lvm-on-md-on-something). Does dmesg show any interesting kernel messages after the installation barfs? (like stack overflow warnings) -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#383248: [Fwd: New package available]
On Tue, Apr 17, 2007 at 09:37:43AM -0300, Otavio Salvador wrote: David Härdeman [EMAIL PROTECTED] writes: Great, and once you do, feel free to add it as a git repo to git.debian.org and give me commit access then all of us can use that repo as the main one instead of my home-grown git repo. I have some trivial but useful changes to recommend: - Makefile shouldn't have the executable bit; - You should use debhelper compatibility 5 instead of 4 (see man debhelper); Ok, I've fixed these two in the git repo All the rest looks OK. All those changes are trivial and can be kept for the next version if wanted. I think it's a green light for its uploading ;-) Great...and BTW, I think maks was going to setup a git.debian.org usplash dir to hold both the usplash and usplash-theme source. -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383248: [Fwd: New package available]
On Mon, April 16, 2007 22:15, maximilian attems said: On Mon, 16 Apr 2007, David Härdeman wrote: Ok, I've fixed all lintian warnings, the updated version of the package is available via git: git clone http://david.hardeman.nu/git/usplash-theme-debian.git usplash-theme-debian i like it a lot. seems needs latest initramfs-tools git tree for me ;) Are you using AMD64? I think the only recent change in initramfs-tools that would affect usplash is the vga16fb loading change you commited? looks really cool. tried also with quiet boot param but that's really t quiet for me.. Yes, that's not related to the theme though, that is how usplash works these days (that is, with the quiet boot arg, it will instruct the theme not to even draw the text box). What is cool though is that even if you use the quiet boot arg, important things like asking for a passphrase during bootup (for encrypted root) will create the text box when necessary. still i'm seeing usplash bugs, aka i'm not landing in front of gdm but anywhere that is not even a black console. If you build and install the package, the easiest way of testing it is by running the usplash-test.sh script in the usplash source package as root. You might also want to try running usplash-test.sh -v as root to see the text output. thanks that test script run here, with the same effect that at the end i'm on a strange vc That's not a bug, its a feature :) The test script does not chvt back to the original vt once its done so you're left on vt8. It's been like this as far as I can remember so I think its intentional. i'd like to have a second voice on the package either by pere or otavio, then we should upload it soon. Great, and once you do, feel free to add it as a git repo to git.debian.org and give me commit access then all of us can use that repo as the main one instead of my home-grown git repo. -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383327: usplash: Enable usplash by default
If a user installs the usplash package, it seems reasonable that he/she expects it to be enabled by default. I've attached a simple patch which reverses the logic of the initramfs script (i.e, splash by default which can be disabled by the nosplash boot arg). This will probably make life easier for the debian-installer since no other changes than including usplash in the desktop task would be necessary in order to install with usplash (a bug I was planning to file later when a default theme is also available). -- David Härdeman diff -ur ./usplash-0.4-43.orig/initramfs/scripts/init-top/usplash ./usplash-0.4-43/initramfs/scripts/init-top/usplash --- ./usplash-0.4-43.orig/initramfs/scripts/init-top/usplash 2007-03-16 00:47:06.0 +0100 +++ ./usplash-0.4-43/initramfs/scripts/init-top/usplash 2007-04-17 22:46:05.0 +0200 @@ -16,13 +16,13 @@ [ -f /etc/usplash.conf ] . /etc/usplash.conf -SPLASH=false +SPLASH=true VERBOSE=true for x in $(cat /proc/cmdline); do case $x in - splash*) - SPLASH=true + nosplash*) + SPLASH=false ;; quiet*) VERBOSE=false
Bug#383248: [Fwd: New package available]
And about one hour later I uploaded a new version fixing a buffer overrun causing erratic theme sizes to be chosen. It's at the same URL so if anyone did download the package in that time interval, please retry. Original Message Hey Otavio, I've rolled a new version of the theme package that I created before (which is based on the artwork by the Debian Desktop team). This one works with usplash 0.4-43-1 without any changes, it can be downloaded from: http://david.hardeman.nu/files/patches/debian/usplash-theme-debian.tar.gz It would be great if you could take a look at it and add it to the archive (i.e. feel free to adopt it so that there is at least one default theme). -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383248: [Fwd: New package available]
On Mon, Apr 16, 2007 at 10:02:09AM +0200, maximilian attems wrote: On Mon, Apr 16, 2007 at 08:31:47AM +0200, David Härdeman wrote: And about one hour later I uploaded a new version fixing a buffer overrun causing erratic theme sizes to be chosen. It's at the same URL so if anyone did download the package in that time interval, please retry. cool, i just did a build check and saw the following: E: usplash-theme-debian: no-copyright-file E: usplash-theme-debian: unstripped-binary-or-object ./usr/lib/usplash/debian-theme.so E: usplash-theme-debian; The package contains no changelog. Ok, I've fixed all lintian warnings, the updated version of the package is available via git: git clone http://david.hardeman.nu/git/usplash-theme-debian.git usplash-theme-debian If you build and install the package, the easiest way of testing it is by running the usplash-test.sh script in the usplash source package as root. You might also want to try running usplash-test.sh -v as root to see the text output. once the lintian build is clean i'll take a second look :) Go ahead -- David Härdeman
Bug#387808: fails to properly handle when server-ip is included in root-path
Hey,
after a quick look, it seems that perhaps this part of the nfs script
could be causing problems:
# source relevant ipconfig output
. /tmp/net-${DEVICE}.conf
Could you please add some code to print the output of
/tmp/net-${DEVICE}.conf and report it since it has the ability to change
any variable which might cause the duplicated entries later (e.g.
192.168.111.64:192.168.111.65:/opt/ltsp/i386).
--
David Härdeman
Bug#383248: New package available
Hey Otavio, I've rolled a new version of the theme package that I created before (which is based on the artwork by the Debian Desktop team). This one works with usplash 0.4-43-1 without any changes, it can be downloaded from: http://david.hardeman.nu/files/patches/debian/usplash-theme-debian.tar.gz It would be great if you could take a look at it and add it to the archive (i.e. feel free to adopt it so that there is at least one default theme). -- David Härdeman
Bug#401916: #401916
On Thu, March 22, 2007 7:42, Gordon Farquharson said: Do you know if your patch [1] you posted to #401916 is going to make it into etch? That patch really belongs to #414842 since it is a change to udev's scripts. I do expect that a version of udev which fixes #414842 will make it into Etch since #414842 is RC and the release managers seemed to agree when I asked them. I'm not a DD so I can't take responsibility for NMU'ing udev myself. And for anyone following these bug reports: the rootdelay parameter is more of a bandaid for #401916 (thus allowing its severity to be downgraded) but it's the best we can do so shortly before release, maks and I have been discussing some better solutions to implement post-Etch. -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401916: udev: Add support for the ROOTDELAY parameter
Package: udev Version: 0.105-3 Severity: normal Tags: patch Hi, maks downgraded #401916 (and #366175) from RC severity with the understanding that something like the attached patch would be applied to the udev initramfs script before the release of Etch to allow people with affected systems some kind of manual workaround at least. I'm not setting the severity to R-C, but I'd like to know whether others (maks, Marco, RM's) think this should go in? -- David Härdeman diff -ur ./udev-0.105.orig/extra/initramfs.premount ./udev-0.105/extra/initramfs.premount --- ./udev-0.105.orig/extra/initramfs.premount 2007-03-14 01:48:20.0 +0100 +++ ./udev-0.105/extra/initramfs.premount 2007-03-14 01:55:12.0 +0100 @@ -20,5 +20,17 @@ udevtrigger udevsettle || true +# If the rootdelay parameter has been set, we wait a bit for devices +# like usb/firewire disks to settle +if [ -n $ROOTDELAY ]; then + if [ -x /sbin/usplash_write ]; then + /sbin/usplash_write TIMEOUT $(($ROOTDELAY + 5)) + fi + sleep $ROOTDELAY + if [ -x /sbin/usplash_write ]; then + /sbin/usplash_write TIMEOUT 15 + fi +fi + # Leave udev running to process events that come in out-of-band (like USB # connections)
Bug#401916: Invalid email address?
Just for the record, mail to [EMAIL PROTECTED] is refused with the message 550 5.1.1 unknown or illegal alias, I hope Hugo reads the bug report log. -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401916: grep PREREQ=
Hugo wrote: 04-15:54:57SDA6# grep PREREQ= * lvm:PREREQ=udev_helper mdadm mdrun lvm2 mdrun:PREREQ=udev_helper rootdelay:+ PREREQ= It seems that the patch has not been applied correctly, the rootdelay line reads '+ PREREQ=' (i.e. still in patch format) while it should read 'PREREQ='. Could you please try the patching again, and make sure that the rootdelay file looks ok afterwards. -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401916: PANIC: Circular dependency
Hugo Vanwoerkom wrote: After patching (no probs) and 'update-initramfs -u' and booting, I get 'PANIC: Circular dependency. Exiting.' from the functions script #167. Could you provide me with the output from grep PREREQ= /usr/share/initramfs-tools/scripts/local-top/* -- David Härdeman
Bug#401916: Bug #401916 - any progress?
On Fri, Feb 23, 2007 at 04:55:00PM +0100, maximilian attems wrote:
On Fri, Feb 23, 2007 at 04:39:52PM +0100, David Härdeman wrote:
On Fri, February 23, 2007 16:28, maximilian attems said:
No, unfortunately it seems that the times between loading the usb host
controller, loading usb-storage and spawning the usb-storage-scan thread
are all asynchronous. So we can't really know how long time we need to
wait for any of those stages.
zut they were only pasted to irc it seems,
no you had the mandrake one posted, so this one might not
been on the radar yet
http://david.woodhou.se/olpc-init.txt
I've looked at it, and it also has a static sleep of a couple of seconds
(not to mention that their target of possible boot devices is smaller)
Anyways, attached you'll find a new version of the rootdelay patch. This
one has two improvements, first it doesn't require any changes to udev,
second, the rootdelay parameter can now be passed as a number (of
seconds to wait) or a device node (to wait for).
The secondary sleep (after udev, lvm, raid, etc have executed) has been
given a static 180 seconds sleep (there really isn't that much to do
there, either sleep or panic).
You should hopefully find this patch to be better...
--
David Härdeman
diff -Nur initramfs-tools-0.85e-orig/init initramfs-tools-0.85e-hack/init
--- initramfs-tools-0.85e-orig/init 2006-11-03 09:03:44.0 +0100
+++ initramfs-tools-0.85e-hack/init 2007-02-25 19:01:16.0 +0100
@@ -46,6 +46,7 @@
export debug=
export cryptopts=${CRYPTOPTS}
export panic
+export ROOTDELAY
for x in $(cat /proc/cmdline); do
case $x in
diff -Nur initramfs-tools-0.85e-orig/scripts/local initramfs-tools-0.85e-hack/scripts/local
--- initramfs-tools-0.85e-orig/scripts/local 2006-10-17 09:26:59.0 +0200
+++ initramfs-tools-0.85e-hack/scripts/local 2007-02-25 19:42:54.0 +0100
@@ -13,11 +13,7 @@
log_begin_msg Waiting for root file system...
# Default delay is 180s
- if [ -z ${ROOTDELAY} ]; then
- slumber=180
- else
- slumber=${ROOTDELAY}
- fi
+ slumber=180
if [ -x /sbin/usplash_write ]; then
/sbin/usplash_write TIMEOUT ${slumber} || true
fi
diff -Nur initramfs-tools-0.85e-orig/scripts/local-top/lvm initramfs-tools-0.85e-hack/scripts/local-top/lvm
--- initramfs-tools-0.85e-orig/scripts/local-top/lvm 2006-08-25 15:09:28.0 +0200
+++ initramfs-tools-0.85e-hack/scripts/local-top/lvm 2007-02-25 19:55:56.0 +0100
@@ -1,6 +1,6 @@
#!/bin/sh
-PREREQ=mdadm mdrun lvm2
+PREREQ=udev_helper mdadm mdrun lvm2
prereqs()
{
diff -Nur initramfs-tools-0.85e-orig/scripts/local-top/rootdelay initramfs-tools-0.85e-hack/scripts/local-top/rootdelay
--- initramfs-tools-0.85e-orig/scripts/local-top/rootdelay 1970-01-01 01:00:00.0 +0100
+++ initramfs-tools-0.85e-hack/scripts/local-top/rootdelay 2007-02-28 01:28:53.0 +0100
@@ -0,0 +1,49 @@
+#!/bin/sh
+
+PREREQ=
+
+prereqs()
+{
+ echo $PREREQ
+}
+
+case $1 in
+# get pre-requisites
+prereqs)
+ prereqs
+ exit 0
+ ;;
+esac
+
+if [ -z $ROOTDELAY ]; then
+ exit 0
+fi
+
+. /scripts/functions
+# If the user wants us to, we'll wait for removable devices, etc...
+# (this is after udev has been executed, but not the other scripts such as LVM)
+if [ -x /sbin/usplash_write ]; then
+ # Some versions of udev seem to wrongly treat 0 as immediate timeout
+ /sbin/usplash_write TIMEOUT 900 || true
+fi
+
+# The rootdelay parameter can be interpreted in two ways
+if [ ${ROOTDELAY%%[^0-9]*} = $ROOTDELAY ]; then
+ # 1) As a number of seconds to wait
+ log_begin_msg Delaying setup for ${ROOTDELAY} seconds...
+ sleep $ROOTDELAY
+ log_end_msg
+else
+ # 2) As a device node to wait for
+ if [ ! -e $ROOTDELAY ]; then
+ log_begin_msg Delaying setup until ${ROOTDELAY} is present...
+ while [ ! -e $ROOTDELAY ]; do
+ sleep 1
+ done
+ log_end_msg
+ fi
+fi
+
+if [ -x /sbin/usplash_write ]; then
+ /sbin/usplash_write TIMEOUT 15 || true
+fi
diff -Nur initramfs-tools-0.85e-orig/scripts/local-top/udev_helper initramfs-tools-0.85e-hack/scripts/local-top/udev_helper
--- initramfs-tools-0.85e-orig/scripts/local-top/udev_helper 2006-07-16 21:20:10.0 +0200
+++ initramfs-tools-0.85e-hack/scripts/local-top/udev_helper 2007-02-25 19:32:35.0 +0100
@@ -1,6 +1,6 @@
#!/bin/sh
-PREREQ=
+PREREQ=rootdelay
prereqs()
{
Bug#401916: Bug #401916 - any progress?
maks...any progress on this bug? A new package which exports ROOTDELAY would be nice, then the rest can be fixed in udev... -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401916: Bug #401916 - any progress?
On Fri, February 23, 2007 12:11, maximilian attems said: On Fri, 23 Feb 2007, David Härdeman wrote: maks...any progress on this bug? no. latest initramfs-tools is on mentors without any #401916 yet. A new package which exports ROOTDELAY would be nice, then the rest can be fixed in udev... well i don't feel that is enough. That what is enough? Just having a sleep boot arg? mika's case is general enough, it affects lilo on almost any root beside ide and quick sata controller and grub for lvm2, evms and mdadm on those too. Sorry, I don't follow, what does lilo and grub have to do with waiting in the initramfs for the root blockdev to appear? Was that a reference to bug 409820? all the other distribution add some bandaid aka stupid sleep for the case of usb, .. and for a quick glance over those initramfs generators this would be done on mkinitramfs time. right? Yes, initramfs-based fixed sleep for a couple of seconds (which may still break in some scenarios) or a hardcoded root device (which allows the initramfs script to wait until that root device node appears) are the two solution I've seen from a quick survey. I still think a user-configurable sleep (and/or a user configurable device node to wait for) would be the best option at this point followed by a more complete solution later. sorry, really busy on a physics workshop so no code right now. but happy about your ping! Good luck with your workshop salutations amicales Med vänliga hälsningar. -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401916: Bug #401916 - any progress?
On Fri, February 23, 2007 14:16, maximilian attems said: On Fri, Feb 23, 2007 at 01:46:08PM +0100, David Härdeman wrote: On Fri, February 23, 2007 12:11, maximilian attems said: On Fri, 23 Feb 2007, David Härdeman wrote: snipp mika's case is general enough, it affects lilo on almost any root beside ide and quick sata controller and grub for lvm2, evms and mdadm on those too. Sorry, I don't follow, what does lilo and grub have to do with waiting in the initramfs for the root blockdev to appear? Was that a reference to bug 409820? for grub we can wait for the root dev to appear, for lilo we create it by hand, so it's always there and you fall into the rescue shell for async root drivers. Ah yes, now I follow, with lilo we get a numeric root dev which is passed to parse_numeric() and used for /dev/root. so this is the topic of this particular bug and afaik the grml-2hd test case is precisely done on an usb stick with lilo bootloader. all the other distribution add some bandaid aka stupid sleep for the case of usb, .. and for a quick glance over those initramfs generators this would be done on mkinitramfs time. right? Yes, initramfs-based fixed sleep for a couple of seconds (which may still break in some scenarios) or a hardcoded root device (which allows the initramfs script to wait until that root device node appears) are the two solution I've seen from a quick survey. I still think a user-configurable sleep (and/or a user configurable device node to wait for) would be the best option at this point followed by a more complete solution later. yes the user configured sleep should override the stupid bandaid sleep. and i would like that band aid sleep only for the known trouble cases like usb-storage and ieee1394. we don't have too _many_ complaints, so we aren't doing that badly. Exactly, considering the low amount of complaints, I'd say there's a tiny minority that is actually affected by this bug. Secondly, there is no way to have the bandaid-wait for usb-storage users only, instead it would hit every computer with usb port (i.e. the vast majority). That's why I think it would be enough to: not include the bandaid at all, implement the rootwait parameter and let the small minority who are affected use it. sorry, really busy on a physics workshop so no code right now. but happy about your ping! Good luck with your workshop thanks, pretty intersting but lots of work.. Since you're busy, I'll do another patch which implements the rootwait parameter during the weekend. Question is, should I completely remove the wait from the premount stage (where it is now) and move it to the udev stage, or should it be duplicated? salutations amicales Med vänliga hälsningar. zut babelfish lacks danish features. Swedish switching back ;) Mit freundlichen Grüßen :) -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401916: Bug #401916 - any progress?
On Fri, February 23, 2007 16:28, maximilian attems said: On Fri, Feb 23, 2007 at 03:05:44PM +0100, David Härdeman wrote: Exactly, considering the low amount of complaints, I'd say there's a tiny minority that is actually affected by this bug. Secondly, there is no way to have the bandaid-wait for usb-storage users only, instead it would hit every computer with usb port (i.e. the vast majority). hmm i thought there was just from looking at the init scripts you or mikap posted.. No, unfortunately it seems that the times between loading the usb host controller, loading usb-storage and spawning the usb-storage-scan thread are all asynchronous. So we can't really know how long time we need to wait for any of those stages. Since you're busy, I'll do another patch which implements the rootwait parameter during the weekend. Question is, should I completely remove the wait from the premount stage (where it is now) and move it to the udev stage, or should it be duplicated? don't remove it as the udev rootdelay is optional as bootparam. we want a small diff too ;) So just to make sure: you want the use of the rootdelay parameter to be added to the udev script and kept in the initramfs script (i.e. used twice)? In that case if you specify rootdelay=5, the boot will pause in the udev stage and then again after the premount stage (before the actual mount). The dual wait is probably no big deal of course...since it adds a few seconds to some exotic boot scenarios only. I'll start working on this... -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401916: Bug 401916: analysis and suggested solution
On Mon, Feb 19, 2007 at 07:21:08PM +0100, maximilian attems wrote:
heya david,
Hey Maks :)
On Fri, 16 Feb 2007, David Härdeman wrote:
Short-term solution:
Therefore, I think the best short-term solution (considering the
ever-impending Etch release) would be to add the root_wait= boot
parameter so that affected users can set the timeout value manually. If
that parameter was added, and documented in the release docs, the severity
of these bugs could be downgraded (imho).
well we already check the rootdelay variable and it could easily be
exported and checked by the udev hook.
please no new boot variables. also aboves is the original meaning of
rootdelay, just currently perverted it's usage.
so yes this can be done easily.
Oh, I missed that variable...I've written a patch now to export it.
Alternatively, or additionally, the scripts could check whether one of
several problematic modules have been loaded when udevsettle returns and
if so, sleep a couple of extra seconds (most other distros that take this
approach seem to wait around 6 - 10 seconds). The problem is that the list
of problematic modules is potentially huge (see list of buses above)
additionally sounds like a good idea, plus an extra udevsettle call.
please cook up a patch for mika.
I've attached a patch against the udev and initramfs-tools source
packages that implement the following changes...please review:
1) ROOTDELAY is exported by initramfs-tools and used in udev if set
2) Checks in udev for scsi/firewire/usb have been added and will add 10
seconds of sleep if found
3) The module scsi_wait_scan will be loaded by udev if scsi is detected,
modprobe should only return from loading that module once all scsi
busses have been scanned (I found that module yesterday...pretty
nifty band-aid solution to the problem, does not help with
usb/firewire though).
The only problem with the approach is that a large majority of all
machines have usb which means that we'll slow down the boot for all
those machines even though a small minority are affected.
Thanks to Mika for the preliminary testing done so far, it has helped my
understanding of the underlying problem...
Long-term solution:
...
Take all scripts under /usr/share/initramfs-tools/scripts/local-top/ that
setup block devices (i.e. cryptsetup, lvm, evms, etc), and split them in
two, a udev rule snippet and a script.
...
Then the main init script is changed to sleep until $ROOT (not /dev/root
but whatever is set as the $ROOT variable) appears
i agree that this was a possible and probable plan i thought of.
disadvantage currently you can exchange udev with some simple hotplug
script out of initramfs-tools and everything will work fine.
If you want a static setup you could still call all those scripts with
some static arguments (e.g. /dev/hda, /dev/sda)
also the idea is to have an MODULES=MOST target that would
just add/run the needed modules and thus not include udev,
than aboves approach is in trouble.
How would MODULES=MOST create stuff under /dev then?
so i'd put that up for discussion and we'll have enough time
to figure that out postetch.
Agreed.
--
David Härdeman
diff -Nur initramfs-tools-0.85e-orig/init initramfs-tools-0.85e/init
--- initramfs-tools-0.85e-orig/init 2006-11-03 09:03:44.0 +0100
+++ initramfs-tools-0.85e/init 2007-02-19 21:05:47.0 +0100
@@ -46,6 +46,7 @@
export debug=
export cryptopts=${CRYPTOPTS}
export panic
+export ROOTDELAY=
for x in $(cat /proc/cmdline); do
case $x in
diff -Nur udev-0.105-orig/extra/initramfs.hook udev-0.105/extra/initramfs.hook
--- udev-0.105-orig/extra/initramfs.hook 2006-05-16 18:16:49.0 +0200
+++ udev-0.105/extra/initramfs.hook 2007-02-19 20:54:13.0 +0100
@@ -16,6 +16,9 @@
# udevd uses unix domain sockets for communication
force_load unix
+# this is used to ensure that SCSI disks have been scanned
+manual_add_modules scsi_wait_scan
+
cp -a /etc/udev/ $DESTDIR/etc/
cp /etc/scsi_id.config $DESTDIR/etc/
rm -f $DESTDIR/etc/udev/rules.d/*_hotplugd.rules # XXX
diff -Nur udev-0.105-orig/extra/initramfs.premount udev-0.105/extra/initramfs.premount
--- udev-0.105-orig/extra/initramfs.premount 2006-12-19 11:19:23.0 +0100
+++ udev-0.105/extra/initramfs.premount 2007-02-19 21:08:03.0 +0100
@@ -20,5 +20,45 @@
udevtrigger
udevsettle || true
+# Check for problematic devices
+problem=0
+
+# USB / FireWire
+if $(grep -q usb\|ieee1394 /proc/devices); then
+ problem=1
+fi
+
+# SCSI
+if [ -e /proc/scsi ]; then
+ modprobe -q scsi_wait_scan || problem=1
+ udevsettle || true
+fi
+
+if [ ${problem} -gt 0 ]; then
+ if [ -z ${ROOTDELAY} ]; then
+ ROOTDELAY=10
+ fi
+fi
+
+# Optionally, wait a user-defined number of seconds
+if [ -z ${ROOTDELAY} ]; then
+ slumber=0
+else
+ slumber=${ROOTDELAY}
+fi
+
+if [ ${slumber} -gt 0 ]; then
+ log_begin_msg Waiting for additional devices...
+ if [ -x /sbin/usplash_write ]; then
+ /sbin/usplash_write TIMEOUT 0
Bug#401916: Bug 401916: analysis and suggested solution
Frans Pop wrote: On Monday 19 February 2007 21:22, David Härdeman wrote: The only problem with the approach is that a large majority of all machines have usb which means that we'll slow down the boot for all those machines even though a small minority are affected. That's a very, very ugly solution then. I'd almost say it's unacceptable to add more than 1, maybe 2 seconds for something like this. Is there really no way to avoid that? Of course there is, I described it earlier in the bug log - do not add any timeout but document the rootdelay parameter in the release notes and let affected users set it to an appropriate value themselves (and there's a good long-term solution as well...but you'll have to read the BR for that one :)) -- David Härdeman
Bug#401916: Bug 401916: analysis and suggested solution
On Mon, Feb 19, 2007 at 11:02:10PM +0100, maximilian attems wrote: Quoting David Härdeman [EMAIL PROTECTED]: I've attached a patch against the udev and initramfs-tools source packages that implement the following changes...please review: ... 2) Checks in udev for scsi/firewire/usb have been added and will add 10 seconds of sleep if found hmm this seems to affect any modern board, so urrgs. Yes...urgh but your grep on the usb_storage thread was not successfull, so maybe we need here build depend logic?!? I've realised that usb_storage thread grepping / usb_storage module grepping will not work because the usb-storage module is loaded asynchronously and udevsettle will return when the usb host driver is loaded, not when the usb_storage driver has been loaded. The usb-storage driver might be loaded at an arbitrary time later...and the same goes for the kernel scanning threads. On most machines with most usb devices this apparently takes place fast enought to work, on Mika's it doesn't. In addition, the grepping would not solve the more generic case (firewire, sas, fibre channel, you name it). I'm still seeing three possible short-term fixes: Auto-decide that scsi/usb/whatever is in use and sleep a couple of seconds Let the affected users specify the sleep interval using the rootdelay parameter Add another parameter in addition to rootdelay...let's call it rootdelaydev, then affected users can set that parameter to something sane (e.g. /dev/sdb) and the udev script can sleep until that dev appears. None of the three options are magic bullets but rather bandaids...and all of them would need some documentation 3) The module scsi_wait_scan will be loaded by udev if scsi is detected, modprobe should only return from loading that module once all scsi busses have been scanned (I found that module yesterday...pretty nifty band-aid solution to the problem, does not help with usb/firewire though). ack, but not for etch: The relevant commit happend for 2.6.20 with the note: This patch only handles drivers which call scsi_scan_host. Fibre Channel, SAS, SATA, USB and Firewire all need additional work. Oh, I missed that...darn so it would already be of a help for uname = 2.6.20. willy was pushing this work, so we'd have the expertise for a postetch kernel fixes. Postetch we won't need that, since we'll implement a udev-driven asynchronous wait-for-root-dev-on-boot...right? :) How would MODULES=MOST create stuff under /dev then? oot what about static dev.. ;) Yuck :) -- David Härdeman
Bug#401916: Bug 401916: analysis and suggested solution
On Mon, Feb 19, 2007 at 11:36:29PM +0100, Michael Prokop wrote:
* David Härdeman [EMAIL PROTECTED] [20070219 22:15]:
+# Check for problematic devices
+problem=0
+
+# USB / FireWire
+if $(grep -q usb\|ieee1394 /proc/devices); then
+ problem=1
+fi
How about:
if $(ps | grep -q usb-storage); then
problem=1
fi
This way only boxes with usb-storage are affected by the booting
delay and not all the boxes with for example an usb input device
like an usb mouse.
I just verified my ps...usb-storage-code: works as intented and
booting from usb works fine then.
It won't work reliably because only the usb host driver is loaded once
udevsettle exits (your screenshot at http://grml.org/initramfs/ shows
this quite well). I'm leaning towards the rootdelay/rootdelaydev +
documentation solution (see my mail to the BR a few minutes ago).
Let's see what maks says...
+if [ ${slumber} -gt 0 ]; then
+ log_begin_msg Waiting for additional devices...
The log_begin_msg call fails (don't ask me why, had no time for
further debugging and locating this bug costed me some minutes
already) and booting failed due to use of 'set -e' in the script
then. Changing the log_begin_msg to echo fixed the problem.
Mea culpa...the udev script needs to source /scripts/functions at the
beginning to be able to use the log_begin_msg function
--
David Härdeman
Bug#401916: Bug 401916: analysis and suggested solution
I've spent more time researching this by reading kernel code, checking the boot process of other distros and trolling through mailing list archives and I think I have a pretty good picture of the problem now. Description: Basically udevsettle will return once all modules have been loaded and no more uevents are pending. all modules include e.g. scsi host drivers and usb host drivers. The problem is that even if a module has been loaded for a usb host which has a storage device attached, the usb host driver will not emit uevents for the device immediately. Instead the scanning is done asynchronously and might take an arbitrary amount of time (based on things like the reset-time of the storage device, which can be several seconds, the number of hubs between the host and the device, etc). The same goes for several other buses (e.g. SCSI, Firewire, fibre-channel, etc), and we won't be able to solve it completely by watching kernel threads (the approach that I tried in earlier mails to the same BR). Short-term solution: Therefore, I think the best short-term solution (considering the ever-impending Etch release) would be to add the root_wait= boot parameter so that affected users can set the timeout value manually. If that parameter was added, and documented in the release docs, the severity of these bugs could be downgraded (imho). Alternatively, or additionally, the scripts could check whether one of several problematic modules have been loaded when udevsettle returns and if so, sleep a couple of extra seconds (most other distros that take this approach seem to wait around 6 - 10 seconds). The problem is that the list of problematic modules is potentially huge (see list of buses above) Long-term solution: In the long term (post-Etch), I think something like the following might be a good solution: Take all scripts under /usr/share/initramfs-tools/scripts/local-top/ that setup block devices (i.e. cryptsetup, lvm, evms, etc), and split them in two, a udev rule snippet and a script. The udev rule snippet would list the devices that this particular script is interested in, and tell udev to call the script whenever such a device node is created. The script is basically the old script with minor changes so that it takes a device node as argument, and also so that it doesn't preserve any state between invocations. Then the main init script is changed to sleep until $ROOT (not /dev/root but whatever is set as the $ROOT variable) appears Advantages of the long-term approach: there will be no more sleeping than necessary everything will be asynchronous there will be no need to specify dependencies between the /usr/share/initramfs-tools/scripts/local-top/ scripts The last one might seem minor, but it actually makes the system much simpler. Right now it is not possible to support both crypto-on-lvm and lvm-on-crypto without duplicating the lvm functionality in the cryptsetup initramfs script (as you can tell initramfs to run lvm before or after cryptsetup, but not both). Example: Let's say we have the scripts lvm, cryptsetup and md in /usr/share/initramfs-tools/scripts/blockdev-scripts/ Each script has a udev rule snippet in /usr/share/initramfs-tools/scripts/blockdev-rules/ Most probably these rule snippets would be something like (this is probably not a valid udev rule, I can't check the syntax right now): KERNEL=[sh]d[a-z], PROGRAM=/usr/share/initramfs-tools/scripts/blockdev-rules/md Let's say that /dev/sda1 is detected. udev will then use its rules to execute /usr/share/initramfs-tools/scripts/blockdev-scripts/lvm which will check the device, realize it's no lvm pv and exit the same thing then happens for the cryptsetup script the md script recognizes /dev/sda1 as a raid partition, but it is missing an additional device, so no action is taken Later, /dev/sdb1 is detected. udev calls the lvm script again, which exits again the same thing then happends for the cryptsetup script the md script recognizes /dev/sdb1 as a raid partition, and /dev/sda1 is the other part of the raid device, so the device is setup and a new uevent is triggered in response, udev creates /dev/md1 and starts going through the scripts again udev calls the lvm script again, which exits again udev calls the cryptsetup script which recognizes /dev/md1 as a crypto device, prompts for the password and sets it up, this generates another uevent in response, udev creates /dev/mapper/cryptroot and starts going through the scripts again udev calls the lvm script again, which recognizes /dev/mapper/cryptroot as a lvm pv and sets up the vg and its lv's the lv's generate new uevents in response, udev creates (among others) /dev/mapper/mainvg-mainlv init notices this and boot continues Phew, this mail became much longer than expectedso whaddaya think Maks? -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401916: bug #401916
Have any of you guys who can reproduce this been able to do the additional tests suggested in the bug report yet? This is one of the few remaining RC bugs which is present in both Etch and Sid so it would be nice to make some progress... -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366175:
severity 366175 critical forcemerge 366175 401916 tags 366175 -moreinfo thanks I'd say that this is the same bug as 401916 so I'm merging them (not sure about the severity though but I picked the higher of the two). Torsten, could you please read bug report #401916 and try the steps suggested in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=401916#52 -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401916:
On Wed, February 14, 2007 11:02, Michael Prokop said: * David Härdeman [EMAIL PROTECTED] [20070206 19:15]: udevtrigger udevsettle || true ps /begin.ps while ps | grep -q usb-stor-scan; do sleep 1; done while ps | grep -q scsi_scan_; do sleep 1; done ps /middle.ps udevsettle || true ps /finish.ps Done that. I've taken screenshots with the digicam (sorry, was the easiest way for me and I'm a little bit in a hurry right now): http://dufo.tugraz.at/~prokop/initramfs/ Images is fine, thanks. Unfortunately the ps ax output is the same each time so it is no surprise that my approach doesn't work. I do however have another theory, it seems that it can take a sec or two between the loading of usb-storage and the usb-stor-scan thread to be created...in order to test this further, could you please replace the above parts with: udevtrigger udevsettle || true cat /proc/modules /modules.txt And provide me with the contents of modules.txt (the digicam method is fine) Could you also provide the output of ps ax once the system is up and running? -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401916:
On Tue, Feb 06, 2007 at 11:14:34AM +0100, Michael Prokop wrote:
* David Härdeman [EMAIL PROTECTED] [20070201 18:08]:
On Thu, Feb 01, 2007 at 05:16:11PM +0100, maximilian attems wrote:
On Thu, Feb 01, 2007 at 04:38:03PM +0100, David Härdeman wrote:
So, as a workaround for Etch until this is fixed (presumably by upstream
changes to udev and/or the kernel), how about changing the following lines
in the udev initramfs script:
udevtrigger
udevsettle || true
to something like this:
udevtrigger
udevsettle || true
while ps | grep -q [usb-stor-scan]; do
sleep 1;
done
while ps | grep -q [scsi_scan_.*]; do
sleep 1;
done
udevsettle || true
Ok, after running several different tests: nope, this does not fix
the problem. The usb stuff is running very asynchron. :(
...
I tried to find out what other distributions do and I like the
approaches of for example OLPC and SuSE. They use an udev rule for
creating the /dev/root device as an symlink to the main device,
like:
SUBSYSTEM==block, SYSFS{dev}==$major:$minor, SYMLINK+=root
I tried to adopt the code for Debian's initramfs-tools but udev does
not work as I expect it to (I do not find any devices inside /dev
created by udev - huh?!) so I could not resolve the issue so far. :(
Unfortunately this wouldn't work because scripts which are independent
of udev might also bring up the root partition (e.g. lvm, evms,
cryptsetup). At least that is my understanding...
...
Any further tips, hints,... what I could try?
Could you try these lines in the udev script and then mail the contents
of /begin.ps, /middle.ps and /finish.ps? It would be interesting to see
if we can find out why the previously suggested approach didn't work:
udevtrigger
udevsettle || true
ps /begin.ps
while ps | grep -q usb-stor-scan; do
sleep 1;
done
while ps | grep -q scsi_scan_; do
sleep 1;
done
ps /middle.ps
udevsettle || true
ps /finish.ps
--
David Härdeman
Bug#401916:
Looking at: http://cvs.mandriva.com/cgi-bin/viewvc.cgi/gi/tools/draklive?revision=1.116view=markup there's an interesting line which sleeps while the usb storage scanning kernel thread is running (search the page for usb-stor-scan). The usb scanning thread is called usb-stor-scan and the scsi scanning threads are called scsi_scan_NUM (AFAIK). So, as a workaround for Etch until this is fixed (presumably by upstream changes to udev and/or the kernel), how about changing the following lines in the udev initramfs script: udevtrigger udevsettle || true to something like this: udevtrigger udevsettle || true while ps | grep -q [usb-stor-scan]; do sleep 1; done while ps | grep -q [scsi_scan_.*]; do sleep 1; done udevsettle || true -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401916:
On Thu, Feb 01, 2007 at 05:16:11PM +0100, maximilian attems wrote: On Thu, Feb 01, 2007 at 04:38:03PM +0100, David Härdeman wrote: So, as a workaround for Etch until this is fixed (presumably by upstream changes to udev and/or the kernel), how about changing the following lines in the udev initramfs script: udevtrigger udevsettle || true to something like this: udevtrigger udevsettle || true while ps | grep -q [usb-stor-scan]; do sleep 1; done while ps | grep -q [scsi_scan_.*]; do sleep 1; done udevsettle || true mika, you could reliable trigger that race by using grml2hd with lilo. could you please test aboves proposed solution and tell us how it works out? And if you do, please make sure to change the greps to use \[...\] instead of [...] The file to edit is: /usr/share/initramfs-tools/scripts/init-premount/udev -- David Härdeman
Re: XServe G5 has no hardware deffect, so this *IS* a udev bug :/
On Fri, Jan 26, 2007 at 10:52:39AM +0100, Sven Luther wrote:
Next step would be :
1) write a program writing to stdout and dropping the actual error message
somewhere.
How about this:
#include stdio.h
#include stdlib.h
#include errno.h
#include string.h
#define LOGFILE /stdouttest.log
#define TESTMSG This is a test string\n
int
main(int argc, char **argv, char **envp)
{
FILE *logfile;
int printerrno;
char *printerror;
int retval = EXIT_FAILURE;
int result;
/* Setup a log file */
logfile = fopen(LOGFILE, a);
if (!logfile)
exit(retval);
fprintf(logfile, Program %s started\n, argv[0]);
/* Print to stdout */
result = fprintf(stdout, TESTMSG);
/* Log results */
if (result 0) {
printerrno = errno;
printerror = strerror(printerrno);
fprintf(logfile, Printing failed (%i): %s\n,
printerrno, printerror);
} else if (result strlen(TESTMSG)) {
fprintf(logfile, Printing was truncated to %i bytes\n,
result);
} else {
fprintf(logfile, Printing successful\n);
retval = EXIT_SUCCESS;
}
/* We're done */
fclose(logfile);
exit(retval);
}
2) contact udev author and ask for his help, since Marco said he didn't have
a further clue, and this may be an upstream problem.
Sounds like a good idea...the upstream mailing list is very active.
--
David Härdeman
Re: [Pkg-cryptsetup-devel] loadkeys in early userspace (using initramfs-tools)
On Tue, January 9, 2007 15:20, Tim Dijkstra said:
Just like cryptsetup the uswsusp package needs to interact with the
user via the keyboard in early userspace.
...
I found out that cryptsetup already solved the problem in its
initramfs-{hook,script}. To not duplicate your work wouldn't it be
better to split that functionality of and put it in the initramfs-tools
package?
What do you think?
I discussed adding loadkeys to initramfs-tools earlier and the
initramfs-tools maintainer disagreed (which is why I implemented it
directly in cryptsetup).
I'm not opposed to a shared solution at all, but I suggest you check with
the initramfs-tools maintainer (see bugs 337663 and 376393 for reference).
Perhaps he is of another opinion now that at least two different initramfs
users need the keymap.
One solution would be to change initramfs-tools to allow other
initramfs-using packages to specify that they need a localized keymap so
that it can be conditionally included in the initramfs image.
This could be done e.g. by including a per-package file such as
/usr/share/initramfs-tools/conf.d/{cryptsetup,uswsusp} which contains the
line KEYMAP=y (this would also be flexible enough to allow other
customizations in the future).
This would also allow users to specify that they want the keymap to be
included even if there is no package which needs it (by creating such a
file themselves).
--
David Härdeman
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: initramfs-utils and LVM ?
On Sat, Nov 04, 2006 at 11:14:04AM +0100, maximilian attems wrote: On Fri, 03 Nov 2006, Hadmut Danisch wrote: Thanks for the hint. I was reading that skript when I wrote my own one. Unfortunately the initramfs hooks did not support what I was looking for. I was in contact with the luks package maintainers. The scripts that come with debian support (or at least supported at that time) only encrypting the volumes inside an LVM separately. please explain what you mean by aboves sentence. afaik cryptoroot on top of a lvm is supported as well as lvm on top of luks. In contrast, I wanted to encrypt the whole LVM volume in one luks volume and hide it's volume structure, and to require only a single password and luks mount step. It works pretty well, there's just one big luks volume on the disk, and all partitions including root is hidden inside this LVM. This also reduces overhead, because you don't have to cope with the encryption when adding new logical volumes. again i don't understand your wording. addding alpix on cc. I'm not quite sure I follow, but the cryptsetup initramfs scripts have supported both crypto on LVM and LVM on crypto for some while now. In fact, that is the setup that you'll get if you choose to do an automated encrypted installation with current daily snapshots of debian-installer (one small unencrypted /boot, one large luks-encrypted partition with LVM ontop). -- David Härdeman
Bug#396022: initramfs-tools: Tries to create the /dev/fb0 device multiple times, causing harmless but confusing error messages
Package: initramfs-tools Version: 0.84 Severity: minor Tags: patch The init-top/framebuffer script has the following lines (83 - 92): if [ -e /proc/fb ]; then while read fbno desc; do mknod /dev/fb$fbno c 29 $fbno done /proc/fb mknod /dev/fb0 c 29 0 for i in 0 1 2 3 4 5 6 7 8; do mknod /dev/tty$i c 4 $i done fi The problem is that the mknod /dev/fb0 will be executed twice if fb0 has already been found in /proc/fb. The fix would be to change it to: if [ -e /proc/fb ]; then while read fbno desc; do mknod /dev/fb$fbno c 29 $fbno done /proc/fb if [ ! -e /dev/fb0 ]; then mknod /dev/fb0 c 29 0 fi for i in 0 1 2 3 4 5 6 7 8; do mknod /dev/tty$i c 4 $i done fi -- David Härdeman
Bug#383248: Suggestion about usplash-themes
On Wed, October 18, 2006 13:18, Daniel Baumann said: 1. When will the next upload for usplash happen? upstream is at 0.4, where debian is still at 0.3. That's for Maks to answer, last thing I heard was that it is held up due to differences between how Ubuntu and Debian handle framebuffer modules (IIRC they're modular in Ubuntu and static in Debian...). I've never had problems with this since I use self-built kernels, but I understand it needs to be resolved for the Debian package. 2. Are you, David, interested in maintaining (or co-maintaining) a usplash-theme package? If so, I would be happy to help out/sponsor/$whatever and to contribute a derivated theme for debian-live. That'd be great. I'm not a DD so I can't upload the theme package myself, so it needs a maintainer, I'd just like to know that I'll be able to commit fixes to it :) I'd also like to know what Maks, as the usplash maintainer, thinks...Maks, would you like to take the usplash theme package or is it ok if Daniel maintains it? As for the status of the usplash-theme package itself, right now it still needs upstream to commit one tiny patch (which I expect they won't for two weeks or so since there's a new Ubuntu release just around the corner). Perhaps if upstream OK's the patch, it could be added prematurely to the Debian version of usplash. In addition, I also have some minor fixes made and some slight artwork updates, so the tarball I posted a link to is a bit outdated. I should really put it into a repository soonish. I'll let you know when I've done so, and then perhaps you could review it (especially the stuff in the debian/ dir since I haven't really messed around with Debian packaging that much)? As for debian-live customization, that should be really easy considering how the package works: right now it takes a SVG image which is scaled and used as background for the different resolutions, and it also uses a PNG image as a progressbar which is incrementally drawn to indicate progress (so right now the Debian text gradually appears as the boot progresses). Just plopping in a new SVG/PNG should be enough to change the looks (you may have to change the parameters in theme.h also). It should be easy to change the package so that it builds several themes using the same infrastructure (just some Makefile magic). -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: Possible (partial) solution for device persistence issue
On Wed, October 18, 2006 11:32, Geert Stappers said: P: /block/hda N: hda S: disk/by-id/ata-IC25N020ATMR04-0_MRG108K1HJSLPH S: disk/by-path/pci-0.0001f000:ata-4-ide-0:0 ... I think that by-path is the presistent thing I want (expect that it is long) I think in general the by-id path would be better since that'd still work if you plug the harddrive into a different port on the IDE controller or change controllers... As udev is always installed with current d-i, the necessary change would be to generate a fstab which uses the by-id paths instead of the UUID= or LABEL= stuff, like so: /dev/disk/by-id/ata-IC25N020ATMR04-0_MRG108K1HJSLPH / ext3 defaults 1 1 This approach requires little to no changes to initramfs scripts which do not (yet?) understand LABEL= and UUID= syntax (like the cryptoroot scripts) and makes it quite simple to see which disk fstab refers to (ls -al /dev/long-path). And of course I've already nagged Frans about it on IRC :) -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383248: usplash
On Sun, Oct 08, 2006 at 12:41:58PM +0200, maximilian attems wrote:
i'm having lots of trouble lately with usplash -
i guess it's due that it no longer uses vga16fb but vesafb
and as debian's one is not modular like ubuntu ones you need
to pass the vga boot arg.
Oh, I had no idea since I use self-built kernels
so sorry that i didn't make lots of progresss on that front.
No problem, here's something to cheer you up :)
I've taken the image posted at [0] and made a debian package based on it
which can create usplash themes of arbitrary sizes. This makes it dead
easy to construct a theme with a number of sizes (e.g. 1600x1200,
1024x768...etc).
Just change the first line in the Makefile to set the size(s) that
should be included and build.
It should have most things that a sane usplash theme package should,
like adding an alternative for /usr/lib/usplash/usplash-artwork.so.
I've tested it with and without verbose output and with several
different resolutions.
In the future, if any of the Debian art wizards would like to update the
theme without having to understand the usplash formats, all they have to
do is to download the sources, plop in a new SVG background and
(optionally) a new png progress image and recompile.
In order to use it, you need the latest upstream usplash sources along
with the attached patch.
I'm hoping that you can take over this artwork package and upload it to
the Debian archive as soon as a usplash with my tiny patch is in the
archive.
The source package can be downloaded from:
http://www.hardeman.nu/~david/files/misc/usplash-theme-etch.tar.gz
--
David Härdeman
[0] http://wiki.debian.org/DebianDesktopArtwork/UsplashEtch
=== modified file 'usplash-theme.h'
--- usplash-theme.h 2006-09-24 13:19:47 +
+++ usplash-theme.h 2006-10-09 21:50:12 +
@@ -25,7 +25,7 @@
#include stdlib.h
/* Current theme version */
-#define THEME_VERSION 2
+#define THEME_VERSION 3
typedef enum { USPLASH_4_3, USPLASH_16_9 } usplash_ratio;
@@ -38,6 +38,8 @@
usplash_ratio ratio;
struct usplash_pixmap *pixmap; /* Background image */
struct usplash_font *font; /* Font for writing text */
+ struct usplash_pixmap *progress_fg; /* Progress bar foreground */
+ struct usplash_pixmap *progress_bg; /* Progress bar background */
/* Palette indexes */
short background; /* General background colour */
Bug#380004: changing FSTYPE
Alex Owen wrote: At the least please add the export FSTYPE= line to init there by allowing local-premount scripts to adjust it if needed. If you want to change a global variable from a script you can already do so by writing the proper lines to /conf/param.conf from the premount script. It will be sourced by the init script once your premount script exits (see the cryptsetup initramfs script for an example). And fstype will hopefully gain iso9660 detection support soon (http://www.zytor.com/pipermail/klibc/2006-September/001997.html) -- David Härdeman
Bug#386441: initramfs-tools: Support custom framebuffer modules
On Tue, Sep 12, 2006 at 09:51:40AM +0200, maximilian attems wrote:
On Mon, 11 Sep 2006, David Härdeman wrote:
elif [ $opt != ${opt#[[:digit:]]*x[[:digit:]]}; then
# Sadly no regexps are available
# but presumably a modevalue without the mode= prefix
echo -n mode=$opt
you can use printf as regex replacement,
it's both in dash as in ash, see load_modules()
from scripts/functions
Ehm...I might be daft, but how would I use printf to check if a string
matches the regexp ^[0-9]+x[0-9]+?
for i in 0 1 2 3 4 5 6 7 8; do
mknod /dev/tty$i c 4 $i
done
The above line should be [ -c /dev/tty$i ] || mknod /dev/tty$i c 4 $i
i'll test it out for the 0.80 release, seems very valuable indeed.
Cool, let me know how it goes
Regards,
David
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#386441: initramfs-tools: Support custom framebuffer modules
On Fri, Sep 08, 2006 at 08:09:15AM +0200, Sven Luther wrote:
On Fri, Sep 08, 2006 at 01:05:57AM +0200, maximilian attems wrote:
On Thu, 07 Sep 2006, David Härdeman wrote:
Package: initramfs-tools
Version: 0.78
Severity: minor
Tags: patch
The attached patch adds support for the video kernel parameter to the
framebuffer script. This allows for the use of non-vesa/vga framebuffer
drivers and at the same time simplifies the logic a bit.
looks good, need to merge anyway the improvement by mjg59
in ubuntu to add fb unconditionaly, although i don't know
yet the reason of his change.
nitpicking below.
Notice that on some arches, like powerpc, many of those fbdev drivers are
builtin.
I've attached a new version of the script (which I haven't had time to
test yet). It should work properly with builtin or modular fb drivers
and also support the extra options which can be passed to fb modules via
the kernel command line.
--
David Härdeman
#!/bin/sh
PREREQ=
prereqs()
{
echo $PREREQ
}
case $1 in
# get pre-requisites
prereqs)
prereqs
exit 0
;;
esac
parse_kernel_opts()
{
local OPTS=$1
local IFS=,
# Must be a line like video=fbdriver:opt1,[opt2]...
if [ $OPTS = ${OPTS%%:*} ]; then
return
fi
OPTS=${OPTS#*:}
# The options part of the kernel video= argument (i.e. everyting
# after video=fbdriver:) has very inconsistent rules.
#
# Generally the following applies:
# 1) options are comma-separated
# 2) options can be in either of these three forms:
# arg=value
# arg:value
# boolean-arg
# 3) the mode option has the form
xresxyres[M][R][-bpp][@refresh][i][m]
#and may or may not start with mode=
#
# When the options are used with modules, they need to be
space-separated
# and the following conversions are needed:
# arg:value - arg=value
# boolean-arg - boolean-arg=1
# modevalue - mode=modevalue
for opt in $OPTS; do
if [ $opt != ${opt#*=} ]; then
# Already in the arg=value form
echo -n $opt
elif [ $opt != ${opt#[[:digit:]]*x[[:digit:]]}; then
# Sadly no regexps are available
# but presumably a modevalue without the mode= prefix
echo -n mode=$opt
else
# Presumably a boolean
echo -n $opt=1
fi
done
}
FB=
OPTS=
for x in $(cat /proc/cmdline); do
case $x in
splash*)
# Let the other options take precedent
if [ -z $FB ]; then
FB=vga16fb
OPTS=
fi
;;
vga=*)
FB=vesafb
OPTS=
;;
video=*)
TMP=${x#*=}
FB=${TMP%%:*}
OPTS=$(parse_kernel_opts $TMP)
;;
esac
done
if [ -n $FB ]; then
modprobe -q $FB $OPTS
fi
if [ -e /proc/fb ]; then
while read fbno desc; do
mknod /dev/fb$fbno 29 $fbno
done /proc/fb
for i in 0 1 2 3 4 5 6 7 8; do
mknod /dev/tty$i c 4 $i
done
fi
Bug#386441: initramfs-tools: Support custom framebuffer modules
On Fri, September 8, 2006 8:09, Sven Luther said: Notice that on some arches, like powerpc, many of those fbdev drivers are builtin. So what would need to change for those arches? Detecting a builtin fb and creating the /dev/fbX and /dev/ttyX device nodes (i.e. the last few line of the script)? Do you know how a builtin fb could be detected in that case? -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380750:
Note that this has been fixed in upstream version 0.4-17 (which generates a usplash-dev package) -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#385730:
Isn't this a dupe of bug #385641 which is fixed by now? -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#386441: initramfs-tools: Support custom framebuffer modules
Package: initramfs-tools Version: 0.78 Severity: minor Tags: patch The attached patch adds support for the video kernel parameter to the framebuffer script. This allows for the use of non-vesa/vga framebuffer drivers and at the same time simplifies the logic a bit. -- David Härdeman diff -ur ./initramfs-tools-0.78.orig/scripts/init-top/framebuffer ./initramfs-tools-0.78/scripts/init-top/framebuffer --- ./initramfs-tools-0.78.orig/scripts/init-top/framebuffer2006-07-24 23:28:00.0 +0200 +++ ./initramfs-tools-0.78/scripts/init-top/framebuffer 2006-09-07 19:10:22.0 +0200 @@ -13,27 +13,32 @@ ;; esac -SPLASH=false; -VESA=false; +FB= for x in $(cat /proc/cmdline); do case $x in splash*) - SPLASH=true; + # Let the other options take precedent + if [ -z $FB ]; then + FB=vga16fb + fi ;; vga=*) - VESA=true; + FB=vesafb + ;; + video=*) + # Look for an argument like video=driver:xresxyres[-bpp[EMAIL PROTECTED] + TMP=$(echo $x | cut -d '=' -f2 | cut -s -d ':' -f1) + if [ -n $TMP ]; then + FB=$TMP + fi ;; esac done -if [ $SPLASH = true -o $VESA = true ]; then +if [ -n $FB ]; then modprobe -q fbcon - if [ $VESA = true ]; then - modprobe -q vesafb - else - modprobe -q vga16fb - fi + modprobe -q $FB mknod /dev/fb0 c 29 0 for i in 0 1 2 3 4 5 6 7 8; do mknod /dev/tty$i c 4 $i
Bug#383249: FYI
FYI, upstream included the recent version of the patch in usplash 0.4-16, so the bug should fix itself once a more recent version is uploaded. -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383249: Updated patch
I've attached a new version of the patch which was recreated against the
current upstream version (0.4-15).
Matthew, I got no feedback from the last version of the patch, I hope
that you'll be able to give some on this version now that it applies
cleanly again after the libusplash splitout and added svga support...
--
David Härdeman
diff -ur usplash-0.4-orig/initramfs/scripts/init-top/usplash
usplash-0.4/initramfs/scripts/init-top/usplash
--- usplash-0.4-orig/initramfs/scripts/init-top/usplash 2006-08-07
22:02:00.0 +0200
+++ usplash-0.4/initramfs/scripts/init-top/usplash 2006-09-04
00:10:51.0 +0200
@@ -33,6 +33,8 @@
for i in 0 1 2 3 4 5 6 7 8; do
mknod /dev/tty$i c 4 $i
done
+ modprobe -q i8042
+ modprobe -q atkbd
/sbin/usplash -c -x $xres -y $yres
sleep 1
fi
diff -ur usplash-0.4-orig/libusplash.c usplash-0.4/libusplash.c
--- usplash-0.4-orig/libusplash.c 2006-08-24 01:20:33.0 +0200
+++ usplash-0.4/libusplash.c2006-09-04 00:32:39.0 +0200
@@ -20,6 +20,7 @@
*/
#include linux/vt.h
+#include linux/limits.h
#include sys/select.h
#include sys/time.h
@@ -53,6 +54,7 @@
void draw_text (const char *string, size_t len);
void draw_line (const char *string, size_t len);
void draw_status (const char *string, size_t len, int mode);
+int handle_input (const char *string, size_t len, int quiet);
/* Non-static so that svgalib can call it. Damned svgalib. */
void usplash_restore_console (void);
@@ -99,6 +101,9 @@
ioctl (fd, VT_ACTIVATE, vt);
ioctl (fd, VT_WAITACTIVE, vt);
close (fd);
+
+ close (STDIN_FILENO);
+ open (vtname, O_RDONLY);
}
void
@@ -291,3 +296,77 @@
usplash_text (x1, y1, string, len, fg, theme-text_background);
}
+
+int
+handle_input (const char *string, const size_t len, const int quiet)
+{
+ int i;
+ char input;
+ int x1, y1, x2, y2, xpos;
+ ssize_t wlen;
+ int fifo_outfd;
+ char inputbuf[PIPE_BUF] = ;
+
+ /* some variables which we'll need */
+ x1 = left_edge + theme-text_x;
+ x2 = x1 + theme-text_width;
+
+ y2 = top_edge + theme-text_y + theme-text_height;
+ y1 = y2 - theme-line_height;
+
+ /* draw the prompt */
+ draw_line (string, len);
+ xpos = x1;
+ for (i = 0; i len; i++)
+ xpos += usplash_getfontwidth (*(string + i));
+
+ /* Get user input */
+ for (i = 0; i PIPE_BUF - 1; i++) {
+ input = getchar ();
+ if (input == '\n' || input == '\r' || input == '\0')
+ break;
+
+ inputbuf[i] = input;
+
+ if (quiet)
+ input = '*';
+
+ /* Make sure the text doesn't overflow */
+ if (xpos + usplash_getfontwidth (input) x2) {
+ usplash_move (x1,
+ top_edge + theme-text_y +
theme-line_height,
+ x1,
+ top_edge + theme-text_y,
+ theme-text_width,
+ theme-text_height - theme-line_height);
+ usplash_clear (x1, y1, x2, y2, theme-text_background);
+ xpos = x1;
+ }
+
+ usplash_text (xpos, y1, input, 1,
+ theme-text_foreground, theme-text_background);
+ xpos += usplash_getfontwidth (input);
+ }
+ inputbuf[i] = '\0';
+
+ /* We wait for timeout seconds for someone to read the user input */
+ for (i = 1; i != timeout + 1; i++) {
+ fifo_outfd = open (USPLASH_OUTFIFO, O_WRONLY|O_NONBLOCK);
+ if (fifo_outfd 0)
+ sleep(1);
+ else
+ break;
+ }
+
+ if (fifo_outfd 0)
+ return 1;
+
+ wlen = write (fifo_outfd, inputbuf, strlen(inputbuf) + 1);
+ if (wlen 0)
+ return 1;
+
+ close(fifo_outfd);
+ memset(inputbuf, 0, PIPE_BUF);
+ return 0;
+}
+
diff -ur usplash-0.4-orig/libusplash.h usplash-0.4/libusplash.h
--- usplash-0.4-orig/libusplash.h 2006-08-24 01:36:08.0 +0200
+++ usplash-0.4/libusplash.h2006-09-04 00:12:25.0 +0200
@@ -9,6 +9,8 @@
void draw_text (const char *string, size_t len);
void draw_line (const char *string, size_t len);
void draw_status (const char *string, size_t len, int mode);
+int handle_input (const char *string, size_t len, int quiet);
+
int usplash_setup (int xres, int yres);
void usplash_restore_console (void);
int strncspn (const char *s, size_t n, const char *reject);
diff -ur usplash-0.4-orig/usplash_backend.h usplash-0.4/usplash_backend.h
--- usplash-0.4-orig/usplash_backend.h 2006-08-03 02:23:49.0 +0200
Bug#383249: usplash: add support for user input
I've attached a patch which adds user input support to usplash.
This works by creating a second fifo /dev/.initramfs/usplash_outfifo and
two new commands: INPUT and INPUTQUIET.
Both INPUT and INPUTQUIET take a prompt as argument. The prompt is
written to the usplash screen and then one line of user input is read to
a buffer. If INPUTQUIET has been used, the user input is not echoed to
screen (but '*').
usplash then waits for a reader to be ready on the outfifo or until the
timeout time elapses. If a reader is available, the user input is
written to the fifo from the buffer.
In a initramfs script, something like this would be used:
if [ -p /dev/.initramfs/usplash_outfifo ]; then
usplash_write INPUTQUIET Enter password:
PASS=$(cat /dev/.initramfs/usplash_outfifo)
else
echo -n Enter password:
read PASS
echo
fi
I have tried the patch locally with a slightly modified cryptsetup
initramfs script and it seems to work.
Regards,
David
Index: usplash-0.3e-quilt/usplash.c
===
--- usplash-0.3e-quilt.orig/usplash.c 2006-08-17 21:50:39.0 +0200
+++ usplash-0.3e-quilt/usplash.c2006-08-19 01:54:47.0 +0200
@@ -20,6 +20,7 @@
*/
#include linux/vt.h
+#include linux/limits.h
#include sys/select.h
#include sys/time.h
@@ -59,6 +60,7 @@
static void draw_line (const char *string, size_t len);
static void draw_status (const char *string, size_t len, int mode);
+static int handle_input (const char *string, size_t len, int quiet);
/* Default theme, used when no suitable alternative can be found */
extern struct usplash_theme testcard_theme;
@@ -115,6 +117,14 @@
}
}
+ if (mkfifo (USPLASH_OUTFIFO, S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP) 0) {
+ if (errno != EEXIST) {
+ perror (mkfifo);
+ ret = 1;
+ goto exit;
+ }
+ }
+
fifo_fd = open (USPLASH_FIFO, O_RDONLY|O_NONBLOCK);
if (fifo_fd 0) {
perror (open);
@@ -180,6 +190,9 @@
ioctl (fd, VT_ACTIVATE, vt);
ioctl (fd, VT_WAITACTIVE, vt);
close (fd);
+
+ close (STDIN_FILENO);
+ open (vtname, O_RDONLY);
}
static void
@@ -333,6 +346,12 @@
} else if (! strncmp (command, PROGRESS, commandlen)) {
draw_progressbar (atoi (string));
+
+ } else if (! strncmp (command, INPUT, commandlen)) {
+ return handle_input (string, len, 0);
+
+ } else if (! strncmp (command, INPUTQUIET, commandlen)) {
+ return handle_input (string, len, 1);
}
return 0;
@@ -473,3 +492,75 @@
bogl_text (x1, y1, string, len, fg, theme-text_background,
0, theme-font);
}
+
+static int
+handle_input (const char *string, const size_t len, const int quiet)
+{
+ int i;
+ char input;
+ int x1, y1, x2, y2, xpos;
+ ssize_t wlen;
+ int fifo_outfd;
+ char inputbuf[PIPE_BUF] = ;
+
+ /* some variables which we'll need */
+ x1 = left_edge + theme-text_x;
+ x2 = x1 + theme-text_width;
+
+ y2 = top_edge + theme-text_y + theme-text_height;
+ y1 = y2 - theme-line_height;
+
+ /* draw the prompt */
+ draw_line (string, len);
+ xpos = x1 + bogl_metrics (string, len, theme-font);
+
+ /* Get user input */
+ for (i = 0; i PIPE_BUF - 1; i++) {
+ input = getchar ();
+ if (input == '\n' || input == '\r' || input == '\0')
+ break;
+
+ inputbuf[i] = input;
+
+ if (quiet)
+ input = '*';
+
+ /* Make sure the text doesn't overflow */
+ if (xpos + bogl_metrics (input, 1, theme-font) x2) {
+ bogl_move (x1,
+ top_edge + theme-text_y +
theme-line_height,
+ x1,
+ top_edge + theme-text_y,
+ theme-text_width,
+ theme-text_height - theme-line_height);
+ bogl_clear (x1, y1, x2, y2, theme-text_background);
+ xpos = x1;
+ }
+
+ bogl_text (xpos, y1, input, 1,
+ theme-text_foreground, theme-text_background,
+ 0, theme-font);
+ xpos += bogl_metrics (input, 1, theme-font);
+ }
+ inputbuf[i] = '\0';
+
+ /* We wait for timeout seconds for someone to read the user input */
+ for (i = 1; i != timeout + 1; i++) {
+ fifo_outfd = open (USPLASH_OUTFIFO, O_WRONLY|O_NONBLOCK);
+ if (fifo_outfd 0)
+ sleep(1);
+ else
+ break;
+ }
+
+ if
Bug#383249: usplash: add support for user input
On Wed, August 16, 2006 13:31, maximilian attems said: nice to see you back, :-) Thank you :) I'm slowly getting up to speed on what's happened while I've been gone On Wed, 16 Aug 2006, David Härdeman wrote: Some startup scripts (e.g. cryptsetup) require user input during the boot which means that usplash exits. It would be nice if user input support could somehow be added to usplash. yes, as quick workaround cryptsetup hook can shut down usplash and fire it up again when it got the anser. Sounds like a reasonable workaround for now. Is there a recommended way for a initramfs script to detect whether usplash is running? Should it just look for usplash_write and use it, if present, to attempt the shutdown unconditionally? Regards, David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383249: usplash: add support for user input
Package: usplash Version: 0.3e Severity: wishlist Some startup scripts (e.g. cryptsetup) require user input during the boot which means that usplash exits. It would be nice if user input support could somehow be added to usplash. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383248: usplash: Please add a default debian splash theme
Package: usplash Version: 0.3e Severity: wishlist usplash (as far as I could tell) does not currently include a default theme (beside the test image). It would be nice to include a default Debian theme. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#376311: initramfs-tools: remove some harmless warnings from the lvm script
Package: initramfs-tools
Version: 0.66
Severity: minor
Tags: patch
The attached patch removes some harmless warnings generated by the lvm
script if for example, resume is a /dev/mapper device but not a lvm
device.
Regards,
David
diff -ur initramfs-tools-0.67-orig/scripts/local-top/lvm
initramfs-tools-0.67/scripts/local-top/lvm
--- initramfs-tools-0.67-orig/scripts/local-top/lvm 2006-06-28
12:16:29.0 +0200
+++ initramfs-tools-0.67/scripts/local-top/lvm 2006-07-02 00:59:59.0
+0200
@@ -40,7 +40,12 @@
# Make sure that we have a d-m path
vg=${vg#/dev/mapper/}
if [ $vg = $1 ]; then
- return 0
+ return 1
+ fi
+
+ # Make sure that the device includes at least one dash
+ if [ $(echo -n $vg | tr -d -) = $vg ]; then
+ return 1
fi
# Split volume group from logical volume.
@@ -61,3 +66,5 @@
activate_vg $ROOT
activate_vg $resume
+
+exit 0
Bug#374891: initramfs-tools: activate resume volume group
On Thu, June 22, 2006 2:11, maximilian attems said: although the cleanup might hurt users with lilo and lvm root user. as lilo passes the root as major and minor, we need to check for fe too. current lvm hook is very sloppy and tries to activate anything. see #357538 something like this to match current behaviour: case $vg in fe[0-9]+) vgchange -ay return ;; esac Ah, I see, that explains some parts of the lvm script that I didn't understand. Have you already fixed lilo support on top of my patch or do you want an updated patch? Regards, David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFC: swap on a LVM volume in debian-installer
Hi all, in debian-installer, there is a package - partman-auto-lvm - which can setup an entire disk to be used for the debian installation with the use of lvm for most partitions. Currently it sets up one boot partition, one swap partition and one lvm PV which is used for the rest of the partitions (usually root and possibly home depending on the recipe used). I'm currently considering whether to change partman-auto-lvm so that the swap partition is created as a lvm lv rather than a separate partition, and I'd like to ask for some comments and feedback before doing so. The last discussion of this feature seems to have been in this thread: http://lists.debian.org/debian-boot/2005/10/msg00842.html === So far, I've seen the following advantages and disadvantages of swap-on-lvm mentioned: Advantages == o makes more partitions available to LVM This means that the swap space can also be managed via the regular lvm tools. Swap space can be reclaimed, enlarged and shrunk using the regular tools when needed. E.g. if a larger swap space is needed, one can do a swapoff, lvextend, mkswap, swapon. In general, to get the most out of lvm, as many partitions as possible should use it. Disadvantages = These are mostly gathered from the above thread: o lowmem I'm not sure this is an issue. If root is already accessed via lvm, will accessing swap via lvm make a difference in lowmem situations? o suspend-to-disk There have been concerns that suspend/resume may not work with swap on a lvm volume. Using initramfs-tools, it seems perfectly possible to resume from a swap partition on lvm (I do so daily). I am not sure whether yaird supports this feature. o overhead Accessing swap via the LVM layer might introduce additional overhead. However, the LVM maintainer disagreed in the above thread, noting that swap should be an io-bound operation and I tend to agree. Note that these disadvantages might be i386 oriented, are there any other disadvantages on other arches, or on i386 for that matter, that I've overlooked? Discussion of additional advantages would also be welcome of course :) === The reason that I'm personally interested is that swap-on-lvm as the default for a lvm install would allow the experimental partman-auto-crypto (a package which uses partman-crypto and partman-auto-lvm to automatically partition a disk so that any partition except /boot will be encrypted) to share 90% of its code with partman-auto-lvm. Comments welcome. Regards, David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: swap on a LVM volume in debian-installer
On Thu, Jun 22, 2006 at 06:58:27PM -0300, Otavio Salvador wrote: David Härdeman [EMAIL PROTECTED] writes: o suspend-to-disk There have been concerns that suspend/resume may not work with swap on a lvm volume. A patch was send today for initramfs-tools to address some issues of it and in new upload should be fine. Am I right maks? Yes, that patch was from yours truly. Previously initramfs-tools would activate the LVM VG which contained the root LV, so if swap was on the same VG, it would be activated as a side-effect (and this is indeed how things are laid out with partman-auto-*). The patch allows root and swap to be on different LVM VG's and should be included in the next initramfs-tools version after 0.64 (which is in incoming right now) according to maks on IRC. Regards, David
Bug#374891: initramfs-tools: activate resume volume group
Package: initramfs-tools
Version: 0.60
Tags: patch
Currently the lvm script does not activate the volume group which the
resume partition resides on. In case the resume lv is in the same vg as
the root lv, then things will work anyway since the root vg is activated
but if they are in different vg's this means that resume will not work.
I've attached a patch which fixes this by activating both resume and
root vg's.
Regards,
David Härdeman
diff -ur initramfs-tools-0.60-orig/scripts/local-top/lvm
initramfs-tools-0.60/scripts/local-top/lvm
--- initramfs-tools-0.60-orig/scripts/local-top/lvm 2006-03-26
21:56:35.0 +0200
+++ initramfs-tools-0.60/scripts/local-top/lvm 2006-06-21 23:43:19.0
+0200
@@ -15,23 +15,34 @@
;;
esac
-vg=${ROOT#/dev/mapper/}
+activate_vg()
+{
+ local vg=$1
-case ${vg} in
- /dev/root)
- unset vg
- ;;
- /*)
- exit 0
- ;;
-esac
-
-modprobe -q dm-mod
+ # Make sure that we have a non-empty argument
+ if [ -z $vg ]; then
+ return 0
+ fi
+
+ # Make sure that we have a d-m path
+ vg=${vg#/dev/mapper/}
+ if [ $vg = $1 ]; then
+ return 0
+ fi
-# Split volume group from logical volume.
-vg=$(echo ${vg} | sed -e 's#\(.*\)\([^-]\)-[^-].*#\1\2#')
-# Reduce padded --'s to -'s
-vg=$(echo ${vg} | sed -e 's#--#-#g')
+ # Split volume group from logical volume.
+ vg=$(echo ${vg} | sed -e 's#\(.*\)\([^-]\)-[^-].*#\1\2#')
+ # Reduce padded --'s to -'s
+ vg=$(echo ${vg} | sed -e 's#--#-#g')
-vgchange -ay ${vg}
+ vgchange -ay ${vg}
+}
+
+if [ ! -e /sbin/vgchange ]; then
+ exit 0
+fi
+
+modprobe -q dm-mod
+activate_vg $ROOT
+activate_vg $resume
Bug#370556: initramfs-tools: does not handle cryptroot-on-lvm properly
On Wed, Jun 07, 2006 at 08:06:24PM +0200, maximilian attems wrote: hello david, thanks for your response and quick jump in! On Tue, 06 Jun 2006, David Härdeman wrote: snipp bug report I think a better approach (which I've suggested before) would be to have a list of devices that should be present before we try to mount root. That list could then contain md/lvm/evms/crypto/dmraid devices as necessary, in the proper order. E.g. for root-on-lvm-on-crypto-on-lvm-on-raid-on-two-hds rootdeps=/dev/hda,/dev/hdb,/dev/md0,/dev/mapper/basevg-baselv,/dev/mapper/cryptdevice,/dev/mapper/mainvg-rootlv nack, this adds extra complexity with not much gain. evms is pretty contained and does not need that, also we want to autodetect so far as as possible. i would not know of another usage than cryptoroot itself, which is still quite specialized even if easy and fun with luks. please take care to document for the cryptoroot on lvm user what they need to pass as root param. Will do as soon as I write some documentation. I'll reassign this bug to cryptsetup, thanks for the feedback. Regards, David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#370556: initramfs-tools: does not handle cryptroot-on-lvm properly
Hey Maximilian, thanks for the CC. On Tue, June 6, 2006 1:05, maximilian attems said: On Mon, Jun 05, 2006 at 05:05:15PM -0400, Daniel Kahn Gillmor wrote: root=/dev/mapper/croot ro this is obviously wrong, current cryptsetup scripts expect the cryptoroot to be set by cryptopts, try root=/dev/mapper/squeak0 cryptopts=cryptsource=/dev/mapper/croot I guess this isn't very clear, but if you have an encrypted root partition on top of lvm/evms/md, you have to point the root variable to the underlying lvm/evms/md partition (this is a limitation of how the current initramfs system works). So, could you try to just change the root variable to root=/dev/mapper/squeak0-rt and boot? Skip the cryptopts variable suggested above, it should already be set to something sane via a config file in the initramfs. i never found the way those cryptopts are specified to be pretty, README.initramfs is not yet enlighting on the subject, adding Davic on cc. I agree that they're not pretty. OTOH, once all bugs are ironed out, they shouldn't be necessary save for exceptional cases. I'll write more documentation when the dust settles and the scripts become more stable. Proposal: What if the end user could supply a list of volume groups that need activation in some environment variable stored in conf.d/lvm? if that variable was set, it would be the one used, otherwise, the script would try to automatically detect the proper vg. I think a better approach (which I've suggested before) would be to have a list of devices that should be present before we try to mount root. That list could then contain md/lvm/evms/crypto/dmraid devices as necessary, in the proper order. E.g. for root-on-lvm-on-crypto-on-lvm-on-raid-on-two-hds rootdeps=/dev/hda,/dev/hdb,/dev/md0,/dev/mapper/basevg-baselv,/dev/mapper/cryptdevice,/dev/mapper/mainvg-rootlv Then each script can inspect the list and bring up the next device in the order if it knows how to do so. Regards, David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#362442: initramfs-tools: A few simple options for greater flexibility
John Goerzen wrote: There are a few things I would find helpful: 1) If scripts in local_top could change the notion of ROOT. I have a script that probes the system to find where the DFS CD is, and then mounts it, since there is no ability to specify a custom ROOT. Fortunately this works since the local script doesn't do error-checking. 2) If scripts in local_top could override the fstype guess. The fstype reports unknown for ISO9660 filesystems. Ideally it would suport them, but even though it doesn't, it would be fine with me if I could override the detected value. Both 1 and 2 seems to be the same as bug 348147 (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=348147;msg=48) 3) It should be documented that hooks and scripts may not contain hyphens in their names. This looks like bug 344639 which should be fixed already. Regards, David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#362442: initramfs-tools: A few simple options for greater flexibility
On Sun, Apr 16, 2006 at 06:36:08PM +0200, maximilian attems wrote: John Goerzen wrote: The fstype reports unknown for ISO9660 filesystems. ...fix in fstype of klibc-utils would be better. I might have time to look into adding ISO9660 detection to fstype sometime next week as a short term solution. A long term solution would perhaps be to completely replace fstype with vol_id from udev instead, but that discussion is probably more suitable upstream [1]. Regards, David [1] e.g. http://www.zytor.com/pipermail/klibc/2006-February/001341.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348147: Bug#358452: [Pkg-cryptsetup-devel]...
Please note that this bug (348147) is not about the cryptsetup hook/script per se anymore, but rather about the possibility to alter global variables from subscripts. Therefore, I've cloned Arjan's mail into a separate bug report against cryptsetup (362564, which in turn in an enhancement of the hook and script in report 358452). The gist of this bug report is still: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=348147;msg=48 Regards, David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348147: cryptoroot-enabling capacity
Hi, if you want to try the patches I've made in a really simple manner, you can try downloading: http://www.hardeman.nu/~david/files/patches/debian/fix-cryptroot It's a shell script, so make it executable after you've downloaded it and then run it as root. It will install the two cryptroot files under /etc/mkinitramfs and divert /usr/share/initramfs-tools/scripts/functions before installing a new version of it. After you've run the script, you need to make sure that you have an entry for your encrypted root partition in /etc/crypttab and then update the failing initramfs by running update-initramfs -c -u -t -k kernel-version. Oh, and you should of course look trough the above script before you run it as root...just in case I'm malicious or just plain incompetent, as it could do nasty things Re, David PS If you do try it, please let me know what the results are... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348147: New version of patch
Thanks for the feedback.
First of all, note that I've split this bug into two with the changes to the
regular initramfs-tools scripts (the only change being the sourcing of files
generated by subscripts) going into this bug and the new hook and
local-premount script going into a bug against cryptsetup (bug 358452).
Some of your comments have already been fixed in the scripts I've attached to
that bug, and some have not. I'll CC this mail to that bug to make sure that
this conversation is noticed by anyone reading that report as well.
maximilian attems ([EMAIL PROTECTED]) wrote:
David Härdeman wrote:
* Adds support for changing variables in the main init script, this is
performed by checking for the file /dev/.initramfs/source.me after
running each script and sourcing it if it does. This is probably
necessary if we ever want to support features such as ROOT=probe as it
would require changing the ROOT variable as the real root is found.
nacked, this hack is ugly.
the form you envisaged to do it is really nonobvious.
the trouble is that you change the ROOT variable to NEWROOT from a
subscript. need to think of a better way to do this.
Yes it is somewhat ugly. But the alternatives are far uglier. With this hack
it is much easier to support things like
root-on-reiserfs-on-lvm-on-dm-crypt-on-raid or ROOT=probe without having to do
extensive changes to unrelated scripts.
The only alternative that I could think of was to change the main init script
to source the subscripts rather than to execute them, but this would require
much more extensive changes.
I hope I can persuade you that this hack is the way to go :)
* Uses the above feature to remove the cryptroot boot option and also
makes changes to other files (such as lvm script) unnecessary.
For initrd compability I should probably readd the boot options. Thats an
issue for bug 358452 though.
nice but missing essential crypto modules, see attached hook file.
I'm working on setting up cryptroot support in debian-installer
(partman-crypto). Since the installer knows which kinds of crypto it has
setup, it can also add the necessary modules. The hook on the other hand
cannot.
Maybe I should add some probing or just add more of the cryptomodules from the
hook (e.g. serpent, blowfish and twofish considering the current patches I
have for partman-crypto).
also i'm real curious about that cryptgetpw, what's in there?
mounting usb stick for reading the key?
The idea was to make things a bit more flexible. The user can create a
cryptgetpw script which gets a key from a usb stick, from a cd-rom, via the
network, whatever. As long as it outputs a key to stdout, everything should be
fine.
For example, I have a script which checks for a usbstick containing a
filesystem with a given uuid. It then loads a keyfile from that stick, asks
for a passphrase, hashes said passphrase and XOR's the two together to create
the key for the root partition.
I can clean it up later and submit as an example to put in /usr/share/doc...
hmm that looks very much in the initrd-tools spirit where you
putted an script to get executed later.
Is that good or bad? :)
for cs_x in ${runlist}; do
${initdir}/${cs_x}
+ if [ -e /dev/.initramfs/source.me ]; then
+ . /dev/.initramfs/source.me
+ rm -f /dev/.initramfs/source.me
+ fi
done
}
nack this is really strange, i had to triple look when that would be run.
See the arguments above. This is the only part that remains to be discussed in
this bug report. Would the change be more acceptable if I add a big fat
comment explaining what this does and why?
+if [ $FSTYPE != luks -a -z $cryptopts ]; then
$FSTYPE is not exported so the check fails at this stage,
also this seems to only work if luks and cryptopts are set,
which seems not to match the code below.
It should exit if no cryptopts are set and no luks filesystem was found (i.e.
no encrypted root partition).
+# Check which cryptosolution we want
+if [ $FSTYPE = luks ]; then
we need to run fstype to know that.
I'll fix
hmm the loop broke out with me having typed in a bad password,
need to recheck that.
I'll check
need to properly read the initrd-tools report about cryptoroot to know
what people wants and i guess we can get that working till that weekend.
i need to check the initrd-tools boot args too as cat /proc/cmdline
root=/dev/sda2 ro cryptopts=node=sda2
looks somehow ugly.
Yes, I should take a look at the boot args used by initrd-tools and see if we
can use the same to avoid confusion.
ps my quick trick to make the attached hook and the attached bootscript
working was this hack (which doesn't work of course with lvm and md):
This should be fixed in the version of the scripts contained in bug 358452.
Regards,
David
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348147: Patch version 3
Hi,
I've attached a third version of the patch. The changes to the init
script have been removed and I intend to add the script/hooks files to
the cryptsetup package instead (separate wishlist bug to be filed soon).
Thus, the patch is reduced to a four-line change to scripts/functions, I
hope you'll find time to fix this soon.
Regards,
David
diff -Nur initramfs-tools-0.57b-orig/scripts/functions
initramfs-tools-0.57b/scripts/functions
--- initramfs-tools-0.57b-orig/scripts/functions2006-03-17
17:13:51.0 +0100
+++ initramfs-tools-0.57b/scripts/functions 2006-03-22 19:01:39.0
+0100
@@ -161,6 +161,10 @@
{
for cs_x in ${runlist}; do
${initdir}/${cs_x}
+ if [ -e /dev/.initramfs/source.me ]; then
+ . /dev/.initramfs/source.me
+ rm -f /dev/.initramfs/source.me
+ fi
done
}
Bug#348147: LVM-Crypt
Hadmut Danisch wrote: So before mounting /root the initram needs to scan for RAID, setup encryption, scan the LVM device and then mount / . The first two are already there with the patch, i.e. regular scanning is first done (RAID, LVM, EVMS, etc) and encryption is then setup. Currently, the setup decrypted device is expected to be the root partition, but it should be quite trivial to also as a filesystem check and possible lvm scan as well. This is a separate issue though, as it requires (among other things) a patch to fstype from klibc (which I'll whip up and send upstream soon). The above patch should therefore, IMHO, be commited independently of Hadmut's feature request (which I'll try to satisfy as well). Regards, David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#351523: initramfs-tools: Add support for filesystem labels and uuid's
Package: initramfs-tools Version: 0.51 Severity: wishlist Tags: patch By adding /sbin/vol_id to the generated initramfs image, udev is able to create the persistent device nodes under /dev/disk such as /dev/disk/by-label/rootpartition which means that the kernel can be booted with an argument such as root=/dev/disk/by-label/rootpart. This also means that the item fstab label and UUID in the wiki InitrdReplacementOptions page can be marked as working (it is marked as such today but I think that is due to a misunderstanding). Re, David --- initramfs-tools-bak/hooks/udev 2006-01-31 12:50:50.0 +0100 +++ initramfs-tools/hooks/udev 2006-02-05 13:42:47.0 +0100 @@ -22,6 +22,9 @@ copy_exec /sbin/udevd /sbin/ copy_exec /sbin/udevsynthesize /sbin/ +# This allows udev to create /dev/disk/by-label and friends +copy_exec /sbin/vol_id /sbin/ + mkdir $DESTDIR/lib/udev/ cp /lib/udev/hotplug.functions $DESTDIR/lib/udev/ copy_exec /lib/udev/vio.agent /lib/udev/
Bug#348147: New version of patch
I've attached an updated version of the previous patch. The changes are:
* Adds support for cryptsetup-luks (see http://luks.endorphin.org/).
LUKS support is now present in the regular Debian cryptsetup package.
If root points at a partition with a luks header, it will be
automagically recognized. This depends on support for luks detection
in fstype in klibc (patch submitted upstream).
* Adds support for changing variables in the main init script, this is
performed by checking for the file /dev/.initramfs/source.me after
running each script and sourcing it if it does. This is probably
necessary if we ever want to support features such as ROOT=probe as it
would require changing the ROOT variable as the real root is found.
* Uses the above feature to remove the cryptroot boot option and also
makes changes to other files (such as lvm script) unnecessary.
Regards,
David
--
diffstat for the previous patch:
hooks/cryptroot | 26 +++
init|9 +
scripts/local-top/cryptroot | 75
scripts/local-top/lvm |6 ++-
4 files changed, 115 insertions(+), 1 deletion(-)
diffstat for the new patch:
hooks/cryptroot | 26 ++
init |5 +
scripts/functions|4 +
scripts/local-premount/cryptroot | 99 +++
4 files changed, 134 insertions(+)
Index: initramfs-tools-quilt/hooks/cryptroot
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ initramfs-tools-quilt/hooks/cryptroot 2006-02-05 00:11:39.0
+0100
@@ -0,0 +1,26 @@
+#!/bin/sh
+
+PREREQ=
+
+prereqs()
+{
+ echo $PREREQ
+}
+
+case $1 in
+prereqs)
+ prereqs
+ exit 0
+ ;;
+esac
+
+. /usr/share/initramfs-tools/hook-functions
+
+if [ -x /sbin/cryptsetup ]; then
+ copy_exec /sbin/cryptsetup /sbin
+ if [ -x /etc/mkinitramfs/cryptgetpw ]; then
+ copy_exec /etc/mkinitramfs/cryptgetpw /sbin
+ fi
+fi
+
+exit 0
Index: initramfs-tools-quilt/init
===
--- initramfs-tools-quilt.orig/init 2006-01-24 11:29:32.0 +0100
+++ initramfs-tools-quilt/init 2006-02-05 00:12:17.0 +0100
@@ -34,6 +34,8 @@
export resume=${RESUME}
export rootmnt=/root
export debug=
+export cryptopts=${CRYPTOPTS}
+
for x in $(cat /proc/cmdline); do
case $x in
init=*)
@@ -65,6 +67,9 @@
exec /tmp/initramfs.debug 21
set -x
;;
+ cryptopts=*)
+ cryptopts=${x#cryptopts=}
+ ;;
break=*)
break=${x#break=}
;;
Index: initramfs-tools-quilt/scripts/functions
===
--- initramfs-tools-quilt.orig/scripts/functions2006-01-24
13:11:16.0 +0100
+++ initramfs-tools-quilt/scripts/functions 2006-02-05 00:12:56.0
+0100
@@ -162,6 +162,10 @@
{
for cs_x in ${runlist}; do
${initdir}/${cs_x}
+ if [ -e /dev/.initramfs/source.me ]; then
+ . /dev/.initramfs/source.me
+ rm -f /dev/.initramfs/source.me
+ fi
done
}
Index: initramfs-tools-quilt/scripts/local-premount/cryptroot
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ initramfs-tools-quilt/scripts/local-premount/cryptroot 2006-02-05
00:13:58.0 +0100
@@ -0,0 +1,99 @@
+#!/bin/sh
+
+PREREQ=
+
+prereqs()
+{
+ echo $PREREQ
+}
+
+case $1 in
+# get pre-requisites
+prereqs)
+ prereqs
+ exit 0
+ ;;
+esac
+
+# Sanity checks
+if [ $FSTYPE != luks -a -z $cryptopts ]; then
+ # Apparently the root partition isn't encrypted
+ exit 0
+elif [ ! -x /sbin/cryptsetup ]; then
+ echo $0: no cryptsetup present
+ exit 0
+fi
+
+# There are two possible scenarios here:
+#
+# 1) The fstype of the root device has been identified as luks
+# 2) The fstype is not luks but cryptopts has been set
+#
+# The former means that we use the luks functionality of cryptsetup, the
+# latter means that we do it the old-fashioned way.
+
+# Start by parsing some options, all options are relevant to regular cryptsetup
+# but only cryptnode is relevant to luks which picks up the rest of the
+# parameters by reading the partition header
+cryptcipher=aes-cbc-essiv:sha256
+cryptsize=256
+crypthash=sha256
+cryptnode=cryptroot
+if [ -n $cryptopts ]; then
+ IFS= ,
+ for x in $cryptopts; do
+ case $x in
+ hash=*)
+ crypthash=${x#hash=}
+ ;;
+ size=*)
+ cryptsize=${x#size=}
+ ;;
+
Bug#339092: Simpler fix
A simpler fix is probably to simply change line 28 in /scripts/local
from modprobe ${FSTYPE} to modprobe -q ${FSTYPE} as it is the only
place where a fs is loaded and since almost all other modprobe
invocations use the -q parameter.
Re,
David
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343302: initramfs-tools: should not regenerate images on upgrade
On Mon, Jan 16, 2006 at 08:13:41PM +0100, maximilian attems wrote: On Tue, 17 Jan 2006, Adam Conrad wrote: Unless this change was merged in a more vicious fashion when it was pulled from Ubuntu to Debian, the update in postinst should only be updating the default kernel version, not ALL of them update-initramfs only touches your new kernel. it is designed safely by jbailey. i left the bug open to see if other submitters would voice themself, as none did we can close it i guess. Thanks for the feedback, I can confirm that the problem no longer seems to be present with a recent version of initramfs-tools. I still believe that one of the earlier versions did behave differently though (as all of my initramfs images were updated), but that is no longer relevant. The bug can be closed... By the way, what is meant by updating the default kernel version, which version is considered to be default? Re, David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348147: Add support for cryptoroot
Package: initramfs-tools
Version: 0.49
Severity: wishlist
Tags: patch
I've attached a first attempt at adding cryptroot support.
It adds two new boot options:
cryptroot: the device which the encrypted filesystem resides on
example: cryptroot=/dev/hda1
cryptopts: a comma-separated list of arguments to cryptsetup, currently
supported options are hash, size and cipher. If none are
specified, defaults (the example below) will be used.
example:
cryptopts=hash=sha256,size=256,cipher=aes-cbc-essiv:sha256
if cryptroot is present, the root argument is expected to be the node
where cryptsetup should setup the unencrypted fs, so it should be under
the /dev/mapper hierarchy. An example of a complete set of arguments
for cryptroot is:
root=/dev/mapper/cryptroot cryptroot=/dev/hda1
cryptopts=hash=sha256,size=256,cipher=aes-cbc-essiv:sha256
Admittedly, having both a root and a cryptroot command line option is
somewhat ugly, but avoiding it would require the init script to source
the files under scripts instead of executing them. The ROOT variable
could then be set to the encrypted node (/dev/hda1 in the example above)
until the cryptroot script is run which could setup the
/dev/mapper/cryptroot node and change the ROOT variable accordingly.
This would for instance have the advantage of making any changes to the
lvm script unnecessary. Alas, this is not possible without major changes...
The cryptroot hook copies cryptsetup to the initramfs (if present) and
if /etc/mkinitramfs/cryptgetpw is present on the system it is also
included.
If no cryptgetpw script is present, the cryptroot script will ask the
user to input the password via keyboard. If the script is present, it is
executed and its output piped to cryptsetup. This allows users to create
more complex password schemes (for example, I currently use a cryptgetpw
which loads the password from a USB key) by creating an appropriate
script.
Comments/suggestions are very welcome (especially a clean way of
altering the ROOT variable from the scripts/local-top/cryptroot would be
nice)...
Re,
David Härdeman
diff -Nur -x udev initramfs-tools-bak/hooks/cryptroot
initramfs-tools/hooks/cryptroot
--- initramfs-tools-bak/hooks/cryptroot 1970-01-01 01:00:00.0 +0100
+++ initramfs-tools/hooks/cryptroot 2006-01-14 20:50:37.0 +0100
@@ -0,0 +1,26 @@
+#!/bin/sh
+
+PREREQ=
+
+prereqs()
+{
+ echo $PREREQ
+}
+
+case $1 in
+prereqs)
+ prereqs
+ exit 0
+ ;;
+esac
+
+. /usr/share/initramfs-tools/hook-functions
+
+if [ -x /sbin/cryptsetup ]; then
+ copy_exec /sbin/cryptsetup /sbin
+ if [ -x /etc/mkinitramfs/cryptgetpw ]; then
+ copy_exec /etc/mkinitramfs/cryptgetpw /sbin
+ fi
+fi
+
+exit 0
diff -Nur -x udev initramfs-tools-bak/init initramfs-tools/init
--- initramfs-tools-bak/init2005-12-28 01:27:43.0 +0100
+++ initramfs-tools/init2006-01-12 22:06:29.0 +0100
@@ -28,6 +28,9 @@
export resume=${RESUME}
export rootmnt=/root
export debug=
+export cryptroot=
+export cryptopts=
+
for x in $(cat /proc/cmdline); do
case $x in
init=*)
@@ -59,6 +62,12 @@
exec /tmp/initramfs.debug 21
set -x
;;
+ cryptroot=*)
+ cryptroot=${x#cryptroot=}
+ ;;
+ cryptopts=*)
+ cryptopts=${x#cryptopts=}
+ ;;
break=*)
break=${x#break=}
;;
diff -Nur -x udev initramfs-tools-bak/scripts/local-top/cryptroot
initramfs-tools/scripts/local-top/cryptroot
--- initramfs-tools-bak/scripts/local-top/cryptroot 1970-01-01
01:00:00.0 +0100
+++ initramfs-tools/scripts/local-top/cryptroot 2006-01-15 09:27:03.0
+0100
@@ -0,0 +1,75 @@
+#!/bin/sh
+
+PREREQ=md lvm evms
+
+prereqs()
+{
+ echo $PREREQ
+}
+
+case $1 in
+# get pre-requisites
+prereqs)
+ prereqs
+ exit 0
+ ;;
+esac
+
+if [ ! -x /sbin/cryptsetup ]; then
+ echo $0: no cryptsetup present
+ exit 0
+fi
+
+# If we have a cryptroot, root must be a device-mapper partition
+if [ -n $cryptroot ]; then
+ cryptnode=${ROOT#/dev/mapper/}
+ if [ $cryptnode = $ROOT ]; then
+ panic $0: root must be a device-mapper partition
+ fi
+else
+ exit 0
+fi
+
+cryptciper=aes-cbc-essiv:sha256
+cryptsize=256
+crypthash=sha256
+
+if [ -n $cryptopts ]; then
+ argc=0
+ while [ 1 ]; do
+ arg=$( echo $cryptopts | cut -d , -f $argc )
+ [ -n $arg ] || break
+ argc=$(( argc + 1 ))
+
+ case $arg in
+ hash=*)
+ crypthash=${arg#hash=}
+ ;;
+ size=*)
+ cryptsize=${arg#size=}
+ ;;
+ cipher=*)
+ cryptcipher=${arg#cipher=}
+ ;;
+ esac
Bug#339087: initramfs-tools: activate all lvm volumes
On Fri, Dec 23, 2005 at 02:19:47PM +0100, maximilian attems wrote: This is wrong and can lead to data loss. lvm2 will cheerfully activate even incomplete volumes. I see, feel free to close the bug then, I'll work on a better solution. Re, David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332824: fixed udev - fixed initramfs-tools?
Jonathan Brandmeyer wrote: So, what do I need to edit to fix this? Alternatively, what command should I try to run after modprobing in ide-disk and ide-generic? The problem is that ide-disk and ide-generic are not loaded when dm-mod is loaded so when it performs its initial device scan it skips the ide discs. The easiest workaround until the bug is properly fixed is the one suggested by Maximilian (i.e. add the modules to /etc/initramfs/modules and regenerate the image). The devices should then be present when dm-mod is loaded which should generate the lvm nodes. Alternatively, you could force dm-mod to do a rescan but I do not remember how to do it :) Re, David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#338406: initramfs-tools: Doesn't create /dev/hda* device nodes on LVM system
maximilian attems wrote: please retest with latest initramfs-tools in unstable And when doing so, please take note of merged bugs 332824, 337497 and 342925 (i.e. make sure that ide-disk and possibly ide-generic are added to /dev/mapper/control before generating the new initramfs image). It seems likely that this could be the same bug (at least with recent initramfs-tools versions)... Re, David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343302: initramfs-tools: should not regenerate images on upgrade
Package: initramfs-tools Severity: important The latest version of initramfs-tools (0.44) calls update-initramfs in postinst to regenerate the latest initramfs on upgrades (see initramfs-tools changelog, version 0.40ubuntu6). This can be potentially very dangerous if the newer initramfs-tools for some reason generates unbootable images as all images will be replaced with unbootable ones (meaning that even older kernels kept in /boot as a fallback solution might fail). For instance, earlier combinations of initramfs-tools and udev automatically loaded the ide-disk module for me. 0.44 doesn't and since it replaced all initramfs-images without warning, none of my kernels boot (ok, it was simple to fix, insmod the module, resume boot, then fix the error and regenerate the images). I think the auto-regereration should: o be reverted; or o carry a big warning; or o be configurable Regards, David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339091: initramfs-tools: lacking documentation
tags 339091 - moreinfo stop maximilian attems ([EMAIL PROTECTED]) wrote: can you please confirem that your manpage was written under PUBLIC DOMAIN license as the initramfs-tools package? I hope this is sufficient: I, the creator of this work, hereby release it into the public domain. This applies worldwide where legally possible. In jurisdictions where this is not legally possible I grant anyone the right, without any conditions unless required by law, to use this work for any purpose including unrestricted redistribution, commercial use, and modification. i've included some small updates to it to match current state. as it's late please proof read too ;-) I'll try to find time to proofread it later this week. If the man page is already in the package by then I'll just file a new bug :) Re, David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340494: initramfs-tools: make dir and node creation more robust
Package: initramfs-tools Severity: minor Currently, initramfs-tools relies upon usr/initramfs_list in 2.6 kernels to create the /dev and /root directories. The attached patch will make sure that they are created along with the console and null device nodes. This has two advantages: 1) If usr/initramfs_list changes, the initramfs will still work 2) The initramfs generated by update-initramfs can be compiled into the kernel (thus replacing usr/initramfs_list). This is still not straightforward to do (you have to first compile a kernel, then generate the initramfs for it, copy it somewhere, ungzip it, configure the kernel config to use that cpio archive as the initramfs and then compile it again) but at least it is doable. Re, David --- init.old2005-11-23 21:06:56.0 +0100 +++ init2005-11-23 21:10:43.0 +0100 @@ -2,6 +2,11 @@ echo Loading, please wait... +[ -d /dev ] || mkdir --mode=0755 /dev +[ -e /dev/console ] || mknod /dev/console c 5 1 +[ -e /dev/null ] || mknod /dev/null c 1 3 +touch /dev/.initramfs-tools +[ -d /root ] || mkdir --mode=0700 /root mkdir /sys mkdir /proc mkdir /tmp @@ -9,9 +14,6 @@ mount -t sysfs sysfs /sys mount -t proc proc /proc mount -t ramfs none /dev -touch /dev/.initramfs-tools -mknod /dev/console c 5 1 -mknod /dev/null c 1 3 . /conf/initramfs.conf . /scripts/functions
Bug#339365: initramfs-tools: fails with recent udev versions
Package: initramfs-tools Severity: important With the recent udev version (0.074-3), /sbin/udevsynthesize tries to run /lib/udev/udevsynthesize if the kernel is a recent version. This fails as /lib/udev/* is not copied to the initramfs image meaning that the boot fails. Re, David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339087: initramfs-tools: activate all lvm volumes
Package: initramfs-tools
Severity: wishlist
Currently the last line in
/usr/share/initramfs-tools/scripts/local-top/lvm only activates the
volume group which seems to contain the root fs.
In order to support features such as root-auto-probing (bug #337682) and
cryptoroot-over-lvm, it would be desirable to activate all lvm volumes.
It seems that the only change needed is to change the last line from the
above mentioned script from vgchange -ay ${vg} to vgchange -ay.
Re,
David
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339089: initramfs-tools: delay rootfs-type check
Package: initramfs-tools
Severity: wishlist
Currently /usr/share/initramfs-tools/scripts/local checks for the
presence of the root device node after local-top has been run but before
local-premount has been run an panics if it can't find it:
# Get the root filesystem type
if [ ! -e ${ROOT} ]; then
panic ALERT! ${ROOT} does not exist.
Dropping to a shell!
fi
eval $(fstype ${ROOT})
This seems a bit counter-intuitive as one would expect a dir called
premount to be run before doing the rootfs checks, so maybe the test
could be moved down to be just below local-premount instead of below
local-top invocation?
If rootfstype might be needed in premount, how about setting FSTYPE to
undefined instead of a panic and delaying the panic to after
local-premount?
Re,
David
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339091: initramfs-tools: lacking documentation
the boot stage
at which the scripts are executed.
.SS Header
Like for hook scripts, there are no guarantees as to the order in which the
different scripts in one subdirectory (see Subdirectories below) are
executed. In order to define a certain order, a similar header as for hook
scripts should be used:
.RS
.nf
#!/bin/sh
PREREQ=
prereqs()
{
echo $PREREQ
}
case $1 in
prereqs)
prereqs
exit 0
;;
esac
.fi
.RE
Where PREREQ is modified to list other scripts in the same subdirectory if
necessary.
.SS Help functions
A number of functions (mostly dealing with output) are provided to boot scripts:
.TP
\fB \fI
log_success_msg
Logs a success message
.RS
.PP
.B Example:
log_success_msg Frobnication successful
.RE
.TP
\fB \fI
log_failure_msg
Logs a failure message
.RS
.PP
.B Example:
log_failure_msg Frobnication component froobz missing
.RE
.TP
\fB \fI
log_warning_msg
Logs a warning message
.RS
.PP
.B Example:
log_warning_msg Only partial frobnication possible
.RE
.TP
\fB \fI
log_begin_msg
Logs a message that some processing step has begun
.TP
\fB \fI
log_end_msg
Logs a message that some processing step is finished
.RS
.PP
.B Example:
.PP
.RS
.nf
log_begin_msg Frobnication begun
# Do something
log_end_msg
.fi
.RE
.RE
.TP
\fB \fI
panic
Logs an error message and executes a shell in the initramfs image to allow the
user to investigate the situation.
.RS
.PP
.B Example:
panic Frobnication failed
.RE
.SS Subdirectories
Both /usr/share/initramfs-tools/scripts and /etc/mkinitramfs/scripts contains
the following subdirectories.
.TP
\fB \fI
init-top
the scripts in this directory are the first scripts to be executed after sysfs
and procfs have been mounted and /dev/console and /dev/null have been created.
No other device files are present yet.
.TP
\fB \fI
init-premount
these scripts are run after udev has populated the /dev tree (udev is still
running) and after modules specified by hooks and /etc/mkinitramfs/modules have
been loaded.
.TP
\fB \fI
local-top OR nfs-top
udev is no longer running. After these scripts have been executed, the root
device node is expected to be present (local) or the network interface is
expected to be usable (nfs).
.TP
\fB \fI
local-premount OR nfs-premount
are run after the sanity of the root device has been verified (local) or the
network interface has been brought up (nfs), but before the actual root fs has
been mounted.
.TP
\fB \fI
local-bottom OR nfs-bottom
are run after the rootfs has been mounted (local) or the nfs root share has
been mounted.
.TP
\fB \fI
init-bottom
are the last scripts to be executed before procfs and sysfs are unmounted and
execution is turned over to the init binary which should now be found in the
mounted rootfs.
.SH EXAMPLES
.SS Hook script
An example hook script would look something like this (and would usually be
placed in /etc/mkinitramfs/hooks/frobnicate):
.RS
.nf
#!/bin/sh
# Example frobnication hook script
PREREQ=lvm
prereqs()
{
echo $PREREQ
}
case $1 in
prereqs)
prereqs
exit 0
;;
esac
. /usr/share/initramfs-tools/hook-functions
# Begin real processing below this line
if [ ! -x /sbin/frobnicate ]; then
exit 0
fi
force_load frobnicator interval=10
cp /sbin/frobnicate ${DESTDIR}/sbin
exit 0
.fi
.RE
.SS Boot script
An example boot script would look something like this (and would usually be
placed in /etc/mkinitramfs/scripts/local-top/frobnicate):
.RS
.nf
#!/bin/sh
# Example frobnication boot script
PREREQ=lvm
prereqs()
{
echo $PREREQ
}
case $1 in
prereqs)
prereqs
exit 0
;;
esac
# Begin real processing below this line
if [ ! -x /sbin/frobnicate ]; then
panic Frobnication executable not found
fi
if [ ! -e /dev/mapper/frobb ]; then
panic Frobnication device not found
fi
log_begin_msg Starting frobnication
/sbin/frobnicate /dev/mapper/frobb || panic Frobnication failed
log_end_msg
exit 0
.fi
.RE
.SH AUTHOR
The initramfs-tools are written by Jeff Bailey [EMAIL PROTECTED].
.PP
This manual was written by David Härdeman [EMAIL PROTECTED].
Bug#339092: initramfs-tools: check if filesystem is already present in kernel
Package: initramfs-tools
Severity: minor
Tags: patch
This patch adds a separate function to load a filesystem driver which
first checks if it is already compiled into the kernel which should
remove some superflous modprobe error messages if it is.
Re,
David
Index: initramfs-tools-0.38/scripts/functions
===
--- initramfs-tools-0.38.orig/scripts/functions 2005-11-14 22:42:06.0
+0100
+++ initramfs-tools-0.38/scripts/functions 2005-11-14 22:44:11.0
+0100
@@ -270,3 +270,13 @@
mknod /dev/root b ${major} ${minor}
ROOT=/dev/root
}
+
+load_fs()
+{
+ if [ -e /proc/filesystems ]; then
+ grep -q $1 /proc/filesystems return 0
+ fi
+
+ modprobe $1 || return 1
+ return 0
+}
Index: initramfs-tools-0.38/scripts/local
===
--- initramfs-tools-0.38.orig/scripts/local 2005-10-21 18:37:46.0
+0200
+++ initramfs-tools-0.38/scripts/local 2005-11-14 22:44:04.0 +0100
@@ -24,8 +24,7 @@
roflag=-w
fi
- # FIXME This has no error checking
- modprobe ${FSTYPE}
+ load_fs ${FSTYPE} || panic Failed to load root fs type ${FSTYPE}
# FIXME This has no error checking
# Mount root
Bug#339093: initramfs-tools: kill udevd as late as possible
Package: initramfs-tools
Severity: minor
Tags: patch
Currently /usr/share/initramfs-tools/init kills udev after init-premount
scripts have executed. However, more devices might become available as a
result of running the local scripts.
I therefore suggest to kill udev as late as possible (right before
chaining to the real root filesystem). If any script has a problem with
udev running it can easilly call killall udevd itself.
Re,
David
Index: initramfs-tools-0.38/init
===
--- initramfs-tools-0.38.orig/init 2005-10-21 18:37:46.0 +0200
+++ initramfs-tools-0.38/init 2005-11-14 22:53:56.0 +0100
@@ -91,8 +91,6 @@
run_scripts /scripts/init-premount
log_end_msg
-killall udevd
-
log_begin_msg Mounting root file system
mountroot
log_end_msg
@@ -103,6 +101,7 @@
# Move our /dev to the real filesystem. Do the setup that udev otherwise
# would.
+killall udevd
mkdir -p /dev/.static/dev
chmod 700 /dev/.static/
mount -n -o bind ${rootmnt}/dev /dev/.static/dev
Bug#338406: LVM on hda - works for me
Russel Coker wrote: The initramfs generated on a LVM IDE system does not create /dev/hda* device nodes, so vgchange doesn't discover any LVM devices and therefore the machine can't boot. That is weird, I have root-on-lvm-on-hda and the devices are created + the system boots just fine for me. Using initramfs-tools 0.38, udev 0.74-2, self-compiled kernel 2.6.14 Re, David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#338404: Not an initramfs-tools bug
This was discussed on debian-devel [1]. As long as the debian kernel is shipped with CONFIG_LEGACY_PTYS enabled I'd say that the current behaviour is correct. The proper fix would be to: a) change the default kernel config; or b) change the udev rules not to do any special changes to initramfs-tools (IMHO). Re, David [1] http://marc.theaimsgroup.com/?t=11313614343r=1w=2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
