[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#551952: marked as done (initramfs-tools: make the order of script execution more robust/flexible/intelligent)

Your message dated Sun, 4 Apr 2010 02:45:28 +0200
with message-id <20100404004528.GI6199@stro.at>
and subject line re: initramfs-tools: make the order of script execution more robust/flexible/intelligent
has caused the Debian Bug report #551952,
regarding initramfs-tools: make the order of script execution more robust/flexible/intelligent
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
551952: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=551952
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: initramfs-tools
Version: 0.92o
Severity: normal


At the moment the order boot scripts are executed in depends solely on
'prereqs' that are - at least in the scripts on my system - rather
static. While the admin can *add* scripts under /etc/initramfs-tools
there is no elegant way to *override* scripts in
/usr/share/initramfs-tools (or at least their prereqs). Sure, I could
divert and edit them, but ...

Now, why is the prereqs-mechanism not sufficent? An example:

a) dm-crypt on lvm2 on md,
b) lvm2 on dm-crypt on md,
c) lvm2 on md on dm-crypt and even
d) md on lvm2

are all valid configurations, depending on the situation. That is, the
ordering of these layers (and consequently the exec order of the
corresponding scripts) is important but it cannot be assumed to be the
same across all possible systems.

Status: a works, so does b (but at first glance I can't see why),
while c is broken. While I haven't tested d), *someone* is bound to need
exactly such a setup and I don't see a reason to disallow it.

Is it possible within the current initramfs-tools framework to allow
a) through d) without ugly custom hacks?

Maybe it could be extended to honor an /etc/initramfs-tools/order file
to allow the admin to hardcode execution order? Or a dirctory
containing /etc/rc?.d-style symlinks?
Perhaps just specify that /usr/share/.../xxx is only executed if
/etc/.../xxx doesn't exist?
Or as a last resort run all scripts again in a different order if no
rootfs is found the first time 'round :-P

Thanks,

C.


-- System Information:
Debian Release: 5.0.3
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.30-bpo.2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages initramfs-tools depends on:
ii  cpio                      2.9-13         GNU cpio -- a program to manage ar
ii  findutils                 4.4.0-2        utilities for finding files--find,
ii  klibc-utils               1.5.12-2       small utilities built with klibc f
ii  module-init-tools         3.4-1          tools for managing Linux kernel mo
ii  udev                      0.125-7+lenny3 /dev/ and hotplug management daemo

Versions of packages initramfs-tools recommends:
ii  busybox                       1:1.10.2-2 Tiny utilities for small and embed

initramfs-tools suggests no packages.

-- no debconf information

--- End Message ---
--- Begin Message --- 
closing as no special bug request.

if you want to have discussions about initramfs-tools
debian-kernel@lists.debian.org or initramfs@vger.kernel.org
are the right lists.

thanks

-- 
maks

--- End Message ---
Reply to: