Bug#767037: Grub EFI fallback - patches for review
On Sun, Dec 21, 2014 at 08:24:08PM +, Steve McIntyre wrote: >On Sun, Dec 21, 2014 at 10:49:59AM +, Ian Campbell wrote: >>On Sat, 2014-12-20 at 09:45 +0100, David Härdeman wrote: >>> one option that doesn't seem to have been considered would be to create >>> a separate package (let's call it UEFIx) that installs an UEFI binary to >>> EFI/boot/bootx64.efi. That binary could then do what the UEFI BIOS >>> should've done (i.e. look at the EFI vars for bootorder, bootnext, etc >>> and then go on to load the right bootloader). >> >>Interesting idea, does this stub bootloader already exist, or is it >>something someone would need to write? (Either way I think it's likely >>too late for Jessie, but perhaps something to think about for Stretch) > >Exactly. :-/ I tried writing a stub bootloader. It works fine in a TianoCore QEMU environmentunfortunately it's a no go on my HP laptop (8570p). The HP UEFI BIOS helpfully deletes the BootOrder variable altogether :/ So...it was a promising idea, but one that won't work :( -- David Härdeman -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#767037: Grub EFI fallback - patches for review
Hi, one option that doesn't seem to have been considered would be to create a separate package (let's call it UEFIx) that installs an UEFI binary to EFI/boot/bootx64.efi. That binary could then do what the UEFI BIOS should've done (i.e. look at the EFI vars for bootorder, bootnext, etc and then go on to load the right bootloader). That way you'll have a solution that'll work across the different bootloaders (grub-efi, gummiboot, etc), requires no changes to existing bootloaders and which will only have an effect if explicitly installed (adding d-i rescue code to optionally install the package should be pretty straightforward as well). It also means that efibootmgr will work as expected on both buggy and non-buggy machines. I realize you're alredy pretty well ahead on a different solution and that it's late in the Jessie game, but I thought I should at least throw this idea into the ring (it's basically what Matthew originally suggested in http://mjg59.dreamwidth.org/4125.html). -- David Härdeman -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#695702: cec-utils: Cannot load libcec.so
Package: cec-utils Version: 1.6.2-1 Severity: grave Justification: renders package unusable Dear Maintainer, running cec-client or cec-config results in the following error messages: No device type given. Using 'recording device' cannot find libcec.solibcec.so: cannot open shared object file: No such file or directory Cannot load libcec.so And then the application exits. A workaround is to do: ln -s /usr/lib/x86_64-linux-gnu/libcec.so.1.0.6 /usr/lib/x86_64-linux-gnu/libcec.so -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (700, 'unstable'), (650, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.5-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- David Härdeman -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#491107: Solution
/etc/udev/rules.d/65_dmsetup.rules needs to be changed so that the three first lines all have GOTO="device_mapper_end". -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#422989: Probably 422979
This is probably not a bug in usplash but instead #422979 that you're seeing... -- David Härdeman
Bug#414842: #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: 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#397973: parted: Fix mac partition table corruption
The attached patch changes libparted so that it doesn't corrupt the mac
parition table when flags that alter the system_name entry are
set/unset. This fixes the error for me (using a mac partition table on a
i386 machine).
Some minor fixes remain in partman-md and partman-lvm (lvm, swap and
raid flags are mutually exclusive)
--
David Härdeman
diff -ur ./parted-1.7.1.orig/libparted/labels/mac.c ./parted-1.7.1/libparted/labels/mac.c
--- ./parted-1.7.1.orig/libparted/labels/mac.c 2006-05-25 19:28:55.0 +0200
+++ ./parted-1.7.1/libparted/labels/mac.c 2007-03-03 02:41:42.0 +0100
@@ -1260,19 +1260,23 @@
return 1;
case PED_PARTITION_LVM:
- mac_data->is_lvm = state;
- if (state)
+ if (state) {
strcpy (mac_data->system_name, "Linux_LVM");
- else
- mac_partition_set_system (part, part->fs_type);
+ mac_data->is_lvm = state;
+ } else {
+ if (mac_data->is_lvm)
+mac_partition_set_system (part, part->fs_type);
+ }
return 1;
case PED_PARTITION_RAID:
- mac_data->is_raid = state;
- if (state)
+ if (state) {
strcpy (mac_data->system_name, "Linux_RAID");
- else
+ mac_data->is_raid = state;
+ } else {
+ if (mac_data->is_raid)
mac_partition_set_system (part, part->fs_type);
+ }
return 1;
default:
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?
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 - 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: > >> > 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 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?
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#411240: kolab-cyrus-imapd: Fix bug 411240 by checking for null data pointers in quota_read
tags 411240 +patch
thanks
The attached patch changes the quota_read function from imap/quota_db.c
to check for a null data pointer (caused by zero length files) before
trying to work with it. Thanks to Ulrich P. Klein for the detailed BR.
--
David Härdeman
diff -ur ./kolab-cyrus-imapd-2.2.13.orig/imap/quota_db.c ./kolab-cyrus-imapd-2.2.13/imap/quota_db.c
--- ./kolab-cyrus-imapd-2.2.13.orig/imap/quota_db.c 2004-05-22 05:45:52.0 +0200
+++ ./kolab-cyrus-imapd-2.2.13/imap/quota_db.c 2007-02-20 23:21:38.0 +0100
@@ -89,6 +89,8 @@
switch (r) {
case CYRUSDB_OK:
+ if (!data)
+ return IMAP_IOERROR;
sscanf(data, "%lu %d", "a->used, "a->limit);
break;
Bug#405461: jabber 1.4.3-3.1 does not allow ssl connections
On Tue, Feb 20, 2007 at 09:51:51PM +, 0ryn wrote: Yup Tue Feb 20 21:50:23 2007 mio_ssl.c:83 Handling: /etc/jabber/key.pem Tue Feb 20 21:50:23 2007 mio_ssl.c:93 Could not create SSL Context: error:140A90A1:SSL routines:SSL_CTX_new:library has no ciphers Good, then Lukazs patch should work, do you know how to build debian packages from source, and if yes, could you try to build one using the patch from: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=405461;msg=22 -- David Härdeman
Bug#405461: jabber 1.4.3-3.1 does not allow ssl connections
Lukasz Grochal wrote: > If we're talking about the same bug, then jabberd -D (debug) should > print out something like: > > Fri Feb 9 23:12:59 2007 mio_ssl.c:93 Could not create SSL Context: > error:140A90A1:SSL routines:SSL_CTX_new:library has no ciphers Tony, Oryn...if you run jabberd with the debug "-D" option, do you get output similar to the above line? -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#409349: apcupsd: Generates lots of kernel hid-core error messages
Tom Wright wrote: > Package: apcupsd > Version: 3.12.4-2 > Severity: critical > Justification: breaks unrelated software > > After the system has been running for a few hours, I get a lot of > kernel hid-core.c error messages in /var/log/messages: Were you able to reproduce this with the latest Debian packaged Linux 2.6 kernel? -- 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 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
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
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 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} -g
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:
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#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: 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#405676: Re #405676
Wasn't this package kept in the archive just to not break d-i RC1? If so, now would perhaps be a good time remove the package as d-i RC1 is broken anyways due to the old security key issue? -- 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:
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
Bug#401916:
Looking at: http://cvs.mandriva.com/cgi-bin/viewvc.cgi/gi/tools/draklive?revision=1.116&view=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#403136: 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
#include
#include
#include
#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
Bug#403687: [EMAIL PROTECTED]: Re: Bug #406697 - Device nodes are not removed when devices are brought down]
I'll forward the same message to this bug that I forwarded to #406697 (which is now closed). Feel free to substitute "cryptsetup" for lvm or any other suitable packages in the text below... ... udev currently receives uevents from the kernel when a new device-mapper device mapping is created and creates a /dev/dm-* node. libdevmapper knows when devices are created/removed and creates the /dev/mapper/* nodes. However, the kernel will not (AFAIK) send uevents when device-mapper mappings are renamed, changed or removed, so udev is not able to remove the devices when appropriate. So the "fix" would be to add support for those uevents to the kernel and to change udev to act on them. Ideally it would create the /dev/dm-* devices and symlinks in /dev/mapper/*. Once that is in place, node creation can be removed from libdevmapper (meaning it will have to wait for the nodes to magically appear instead). There is a writeup on this with some more details at: https://wiki.ubuntu.com/UdevDeviceMapper However, I can't see that anything needs to be done in cryptsetup (except making sure that all works when/if this behaviour is changed in libdevmapper). -- David Härdeman
Bug#403075: [Pkg-cryptsetup-devel] Bug#403075: cryptsetup luksOpen can kill unrelated processes (out of memory killer)
severity 403075 normal tags 403075 -security tags 403075 +moreinfo thanks On Thu, Dec 14, 2006 at 01:46:33PM +, Rob Walker wrote: Package: cryptsetup Version: 2:1.0.4-8 Severity: grave Tags: security Justification: user security hole If I run cryptsetup luksOpen, giving it a file instead of a device, it tries to allocate lots of memory, eventually triggering the oomkiller to kill processes. A normal user can do this, so this could be used for some kind of denial of service attack: system performance will be impaired and processes of other users may be killed. Hence the grave serverity. Ehh..any user can run a process which uses any amount of memory unless you use ulimit. I agree this would be a bug in crypsetup, but calling it a user security hole is not correct. To reproduce # produce a dummy file dd if=/dev/zero of=/tmp/foo bs=1k count=1024 # try to run cryptsetup /sbin/cryptsetup luksOpen /tmp/foo /dev/mapper/_tmp_foo The first argument after luksOpen should be a device, the second should be a mapping name. /tmp/foo is no device, it's a file. /dev/mapper/_tmp_foo is no mapping name, it's a complete path. The correct syntax would be something like: /sbin/cryptsetup luksOpen /dev/something tmpfoo Furthermore, I can't reproduce this (using the version currently in unstable): # dd if=/dev/zero of=/tmp/foo bs=1k count=1024 # losetup -f /tmp/foo # crypsetup luksOpen /dev/loop0 tmpfoo # Enter LUKS passphrase: # /dev/loop0 is not a LUKS partition # cryptsetup luksFormat /dev/loop0 WARNING! This will overwrite data on /dev/loop0 irrevocably. Are you sure? (Type uppercase yes): YES Enter LUKS passphrase: Verify passphrase: Command successful. # cryptsetup luksOpen /dev/loop0 footmp Enter LUKS passphrase: key slot 0 unlocked. Command successful. # ls -al /dev/mapper/footmp brw-rw 1 root disk 254, 3 2006-12-14 19:14 /dev/mapper/footmp # cryptsetup remove footmp # losetup -d /dev/loop0 -- David Härdeman
Bug#397450: cryptsetup: tries to check readability of key even if keyscript is set
Package: cryptsetup Version: 2:1.0.4-3 Severity: serious If an entry in /etc/crypttab specifies the keyscript= option, the key (third option in the file) is just used as an argument to that keyscript and can be set to anything (what it actually means depends on the keyscript itself). However, the init.d scripts check for readability of the key and refuses to try to setup the mapping if it's not readable. I will commit a fix for this later today, updated package should be included in Etch. -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#397454: cryptsetup: root and swap on lvm on crypto can result in boot failure
Package: cryptsetup Version: 2:1.0.4-4 Severity: serious Starting with 2:1.0.4-4, the cryptsetup initramfs scripts will also try to setup the swap partition in order to support (u)swsusp. In the case where both root and swap use the same underlying dm-crypt device, this will lead to duplicate entries in /conf/conf.d/cryptroot in the initramfs image and the boot will fail. The fix is simply to check in the initramfs script whether a device has already been setup, and if so - ignore the second entry. This will work with LVM/etc without changes as the same dm-crypt device can't be a physical volume for several LVM vg's so no additional setup is necessary for the second device. I will commit a fix for this later today, updated package should be included in Etch. -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#396126: Cryptsetup bug #396126: FTBFS: Incompatible with etch versions
Hi Jonas, I've looked at the FTBFS and I think the best thing to do would be to change debian/rules so that dpatches are applied before the configure script is executed (thereby allowing the dpatch to change Makefile.in instead of the generated Makefile). I'll write a patch, test it and commit it to SVN this evening. Since a new upload is necessary for d-i RC1, and since it fixes two RC bugs, I'll ask Frans Pop to do a NMU upload unless you've told me by then that you have time to do the upload. -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#395414: [Pkg-cryptsetup-devel] Bug#395414: cryptsetup: Command failed: device-mapper: reload ioctl failed: Invalid argument
On Thu, Oct 26, 2006 at 10:49:09PM +0200, Noèl Köthe wrote: I cannot decrypt my encrypted data anymore: ... # dmesg ... dm_crypt: disagrees about version of symbol struct_module This means the dm-crypt module wasn't loaded, most probably because it is not exactly the same version (same GCC, same options, etc) as the kernel itself. This doesn't sound like a cryptsetup problem... What kernel are you using? Are you sure the dm-crypt module is ok? Are you able to manually insmod dm-crypt? -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#391071: partman-auto-crypto: No confirmation before hard-drive wiping
On Thu, October 5, 2006 2:07, Frans Pop said: > I personally would prefer to consistently delay disk selection to a second > level in _all_ cases and explain what the next step will be in the > description; something like: > > >... > Automatic - use the largest continuous free space > Automatic - erase entire disk > Automatic - erase entire disk and set up LVM > Automatic - erase entire disk and set up encrypted LVM > Manual > Strange, it sounds familiar...oh yes...it's what I've been suggesting all along [1]. So I think its safe to say that we fully agree. I can whip up a patch or two once I have confirmation that this is the final decision on this issue. > This may need to be revised again when we can offer RAID1, but that > depends on the implementation and could probably be solved by mentioning > that option in the description. In which way would the scheme need to change for RAID1? > It would probably be a could idea to repeat the fact that existing data > will be erased after selecting a method that does and we need to add an > extra confirmation dialog before the partition table is written when > using LVM anyway (see #368633). Yup > BTW. I also noticed that with "Use the largest continuous free space" > there is currently no indication of what disk will actually be used or > how big the free space is. It is of course kind of implied (whichever > disk has the largest free space), but IMO it would be kind of nice to > tell the user before it is done. Perhaps we should add the "select disk" dialogue to the "Use the largest continuous free space" choice as well...with the modification that we only present disks with free space? -- David Härdeman [1] http://lists.debian.org/debian-boot/2006/08/msg00854.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#391071: partman-auto-crypto: No confirmation before hard-drive wiping
On Wed, Oct 04, 2006 at 11:05:51PM +0200, Frans Pop wrote: On Wednesday 04 October 2006 22:06, David Härdeman wrote: Where has the "Erase entire disk and ..." part of this menu entry (and the one for auto-lvm disappeared to? IIRC that was in the original discussion. How about changing them to: "Select disk to partition (please note that the entire disk will be erased):" What's against bringing it back in the method dialog? Nothing, it's a matter of taste (meaning it's up to you to decide) :) But I think it might be a bit confusing to see the "regular" entries on the method dialog and a similar entry for the other methods but without the disk: "Erase entire disk: IDE1 Master (hda) - 1.1Gb Qemu harddisk" "Erase entire disk: IDE2 Master (hdb) - 1.1Gb Qemu harddisk" ... "Erase entire disk and automatically set up encrypted lvm" The user would probably be left wondering which disk the last option refers to...not knowing that the disk choice will be the subject of the next dialogue? -- David Härdeman
Bug#391071: partman-auto-crypto: No confirmation before hard-drive wiping
On Wed, Oct 04, 2006 at 08:23:29PM +0200, Frans Pop wrote: On Wednesday 04 October 2006 19:19, Jérémy Bobbio wrote: I have tried to use partman-auto-crypto by selecting "Automatically set up encrypted LVM" in the partman menu. I initially thought that it was going to use the free space which was available on the hard-drive. David: Where has the "Erase entire disk and ..." part of this menu entry (and the one for auto-lvm disappeared to? IIRC that was in the original discussion. It is currently only used on the first menu for the regular partitioning method. I understand the confusion this may cause...so perhaps the best solution would be to expand the partman-auto/select_disk and partman-auto/select_disks templates. They currently say: "Select disk to partition:" How about changing them to: "Select disk to partition (please note that the entire disk will be erased):" -- David Härdeman
Bug#389456: p-a-c: Fails to configure encrypted volumes
On Tue, Sep 26, 2006 at 07:36:10PM +0200, Max Vozeler wrote: - tools="/bin/blockdev-keygen /sbin/dmsetup /sbin/cryptsetup" + tools="$tools /sbin/dmsetup /sbin/cryptsetup /lib/libpopt.so.0" This won't work, I think? We test for [ -x $tool ] further down in crypto_check_required_tools(). I think we'd need to change the test to [ -e .. ] or test separately for libs. Somehow I feel we should find a better way to test for required libraries though. Perhaps changing the error reporting in anna-install so that we could tell if a dependency couldn't be loaded? Oh, right...I've changed the test to [ -e ] for now and we can always do this in a different way if/when anna-install allows for dependency download error checking. -- David Härdeman
Bug#389456: p-a-c: Fails to configure encrypted volumes
On Tue, Sep 26, 2006 at 01:02:02PM +0200, Frans Pop wrote: On Tuesday 26 September 2006 09:51, Frans Pop wrote: Also, if loading modules can result in new devices, update-dev (from di-utils) needs to be called. Again, grep in hwdetect for examples. Adding a 'depmod -a' does fix the problem. Ok, I've fixed this in p-a-c. update-dev is not necessary since the crypto modules create no devices. Note that there is this issue too. As I've said earlier in this BR, anna-install will likely not return an error if not all dependencies can be met (my logs attached earlier confirm this), so this needs to be checked in a different way. The on-demand-loaded packages are (from your previous mail): - cdebconf-newt-entropy - crypto-modules-$kvers - cryptsetup-udeb - dmsetup-udeb - libpopt0-udeb - partman-crypto-dm cryptsetup and dmsetup are checked in crypto_check_required_tools partman-crypto-dm is the argument to anna-install and I'd assume that anna-install returns an error if the primary target is not downloaded correctly crypto-modules-$kvers is checked in crypto_load_modules crypto_load_modules and crypto_check_required_tools are called from crypto_prepare_method which is called from p-a-c and partman-crypto where appropriate This leaves libpopt0 and cdebconf-newt-entropy I've committed a preliminary test for the presence of those two libs to crypto_check_required_tools. (the above mentioned crypto_* methods are all in crypto_tools.sh from partman-crypto) -- David Härdeman
Bug#389456: p-a-c: Fails to configure encrypted volumes
On Tue, September 26, 2006 3:44, Frans Pop said: > Although the log does not show which udebs were actually installed, > after the failure /var/lib/dpkg shows the following packages installed > (probably newly installed as they are at the bottom of the file): > - cdebconf-newt-entropy > - crypto-modules-$kvers > - cryptsetup-udeb > - dmsetup-udeb > - libpopt0-udeb > - partman-crypto-dm > So it looks to me like dependencies were correctly pulled in? > (libdevmapper1.02-udeb was of course already installed) Hmmm...random idea of the day (which I can't test right now): Using a crypto means that device-mapper calls crypto_alloc_tfm --> crypto_alg_mod_lookup --> try_then_request_module --> request_module, which does a modprobe of a module with the same name as the crypto. Perhaps "depmod -ae" needs to be executed after the crypto-modules-$kvers module has been downloaded and unpacked? -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#389456: p-a-c: Fails to configure encrypted volumes
On Mon, Sep 25, 2006 at 11:25:53PM +0200, Max Vozeler wrote: On Mon, Sep 25, 2006 at 09:53:31PM +0200, Frans Pop wrote: /var/log/syslog shows: kernel: device-mapper: crypt: Error allocating crypto tfm kernel: device-mapper: error adding target to table kernel: device-mapper: device doesn't appear to be in the dev hash table. partman-crypto: Command failed: device-mapper: reload ioctl failed: Invalid argument I think I've seen this kind of error before, IIRC with a manual d-i build that what missing the required kernel modules. This could indicate that our new delayed package loading is not working as expected now that the priorities have really changed. Agreed...the problem is probably with the on-demand loading of modules and not with p-a-c. It's weird though, partman-crypto-dm does rely on the virtual crypto-modules package... Did the syslog have any failure messages wrt. udeb download before the device-mapper errors? -- David Härdeman
Bug#332824: fixed udev -> fixed initramfs-tools?
Jonathan Brandmeyer wrote: > /dev/mapper is empty except for control Does running "vgscan" and/or "vgchange -ay" from the initramfs shell create any nodes in /dev/mapper? -- 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]
