Bug#494466: [patch, RFC] Allow to select driver inclusion policy for initramfs-tools
On Friday 12 September 2008, maximilian attems wrote: I thought about that, but that assumes the default of initramfs-tools won't ever change. I'd prefer not to base code on that assumption. i'm happy with d-i setting it for specific embedded arch, but please drop that file when it is useless. Done. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494466: [patch, RFC] Allow to select driver inclusion policy for initramfs-tools
sorry for the late dropin, haven't seen that before today #498712 came in. which clearly shows the uglyness of the current situation, why should the same variable be set on *two* places. On Mon, 25 Aug 2008, Frans Pop wrote: On Monday 25 August 2008, Martin Michlmayr wrote: - the question was not asked (because debconf priority medium) That would break the case where the architecture default if different from the default of initramfs-tools. - the policy is the same as the default of initramfs-tools (most) I thought about that, but that assumes the default of initramfs-tools won't ever change. I'd prefer not to base code on that assumption. it won't change. initramfs-tools per default has the concept of generating an allmost generic initramfs. i'm happy with d-i setting it for specific embedded arch, but please drop that file when it is useless. as tbm said ($RET != most) is easy to check. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494466: [patch, RFC] Allow to select driver inclusion policy for initramfs-tools
Just for the record, this works as expected. Thanks a lot for implementing this, Frans! -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494466: [patch, RFC] Allow to select driver inclusion policy for initramfs-tools
Frans, There's one thing that imho could be improved with the current driver-policy handling. IMHO it would make sense not to create the /etc/initramfs-tools/conf.d/driver-policy file if these conditions are met: - the question was not asked (because debconf priority medium) - the policy is the same as the default of initramfs-tools (most) The second is easy ($RET != most) but I'm not sure how to check for the first. Any comments? -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494466: [patch, RFC] Allow to select driver inclusion policy for initramfs-tools
On Monday 25 August 2008, Martin Michlmayr wrote: - the question was not asked (because debconf priority medium) That would break the case where the architecture default if different from the default of initramfs-tools. - the policy is the same as the default of initramfs-tools (most) I thought about that, but that assumes the default of initramfs-tools won't ever change. I'd prefer not to base code on that assumption. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494466: [patch, RFC] Allow to select driver inclusion policy for initramfs-tools
* Frans Pop [EMAIL PROTECTED] [2008-08-25 10:10]: On Monday 25 August 2008, Martin Michlmayr wrote: - the question was not asked (because debconf priority medium) That would break the case where the architecture default if different from the default of initramfs-tools This would be met by the 2nd condition: - the policy is the same as the default of initramfs-tools (most) I thought about that, but that assumes the default of initramfs-tools won't ever change. I'd prefer not to base code on that assumption. Okay, fair enough. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494466: [patch, RFC] Allow to select driver inclusion policy for initramfs-tools
* Jérémy Bobbio [EMAIL PROTECTED] [2008-08-17 01:05]: The patch has been commited by Christian, although I have then removed the defaulting to dep on i386 and amd64 based on your comments. Please make the necessary adjustements for the relevant NAS devices. Done. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494466: [patch, RFC] Allow to select driver inclusion policy for initramfs-tools
On Fri, Aug 15, 2008 at 10:05:59PM +0300, Martin Michlmayr wrote: Frans said earlier: It is also needed for e.g. arm where in some cases the initrd is getting too big for the flash memory it needs to fit in. So, do you think that it would make sense for NAS or similar devices? Yeah, I need it for some NAS devices. I'm not sure yet if I'll simply define dep as the default for all of armel, but I probably will. So this patch is very useful to me. The patch has been commited by Christian, although I have then removed the defaulting to dep on i386 and amd64 based on your comments. Please make the necessary adjustements for the relevant NAS devices. Cheers, -- Jérémy Bobbio.''`. [EMAIL PROTECTED]: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#494466: [patch, RFC] Allow to select driver inclusion policy for initramfs-tools
On Sun, Aug 10, 2008 at 09:03:46AM +0300, Martin Michlmayr wrote: * Frans Pop [EMAIL PROTECTED] [2008-08-09 19:53]: With the default initrd now being over 6 GB on amd64 and the fact that lilo has structural problems with large initrds, I think that implementing something like the attached patch for Lenny is almost unavoidable. Nice patch. I wouldn't change the default to dep on amd64 and i386 though: 1) These arches are the most generic ones we support in terms of hardware and MODULES=most makes most sense on them (unlike on embedded hardware which doesn't change). I do agree that it is always nice when you can just take an hard drive out of a system, plug it into another, and that everything works as usual. 2) The LILO bug has been fixed. Frans said earlier: It is also needed for e.g. arm where in some cases the initrd is getting too big for the flash memory it needs to fit in. So, do you think that it would make sense for NAS or similar devices? Cheers, -- Jérémy Bobbio.''`. [EMAIL PROTECTED]: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#494466: [patch, RFC] Allow to select driver inclusion policy for initramfs-tools
* Jérémy Bobbio [EMAIL PROTECTED] [2008-08-15 17:51]: 2) The LILO bug has been fixed. Frans said earlier: It is also needed for e.g. arm where in some cases the initrd is getting too big for the flash memory it needs to fit in. So, do you think that it would make sense for NAS or similar devices? Yeah, I need it for some NAS devices. I'm not sure yet if I'll simply define dep as the default for all of armel, but I probably will. So this patch is very useful to me. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494466: [patch, RFC] Allow to select driver inclusion policy for initramfs-tools
* Frans Pop [EMAIL PROTECTED] [2008-08-09 19:53]: With the default initrd now being over 6 GB on amd64 and the fact that lilo has structural problems with large initrds, I think that implementing something like the attached patch for Lenny is almost unavoidable. Nice patch. I wouldn't change the default to dep on amd64 and i386 though: 1) These arches are the most generic ones we support in terms of hardware and MODULES=most makes most sense on them (unlike on embedded hardware which doesn't change). 2) The LILO bug has been fixed. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494466: [patch, RFC] Allow to select driver inclusion policy for initramfs-tools
Package: base-installer
Version: 1.93
Severity: wishlist
Tags: patch
With the default initrd now being over 6 GB on amd64 and the fact that
lilo has structural problems with large initrds, I think that
implementing something like the attached patch for Lenny is almost
unavoidable.
It is also needed for e.g. arm where in some cases the initrd is getting
too big for the flash memory it needs to fit in.
My personal guess is that selecting MODULES=dep for x86 is unlikely to
result in unbootable systems. As I've no idea about other architectures
the default can be set per architecture (to be determined by their
porters).
Note that the patch adds a new dialog (at medium priority).
Note that this will also need to be documented in the installation guide.
Index: debian/bootstrap-base.templates
===
--- debian/bootstrap-base.templates (revision 54931)
+++ debian/bootstrap-base.templates (working copy)
@@ -62,6 +62,23 @@
The package ${GENERATOR} that was selected to generate the
initrd is not supported.
+Template: base-installer/initramfs-tools/driver-policy
+Type: select
+Choices-C: most, dep
+# :sl3:
+__Choices: generic: include all available drivers, targeted: only include drivers needed for this system
+# :sl3:
+_Description: Drivers to include in the initrd:
+ The primairy function of an initrd is to allow the kernel to mount the
+ root file system. It therefore needs to contain all drivers and supporting
+ programs required to do that.
+ .
+ A generic initrd is much larger than a targeted one and may even be so
+ large that some bootloaders are unable to load it but has the advantage that
+ it can be used to boot the target system on almost any hardware. With the
+ smaller targeted initrd there is a very small chance that not all needed
+ drivers are included.
+
Template: base-installer/kernel/failed-install
Type: error
_Description: Unable to install the selected kernel
Index: debian/templates-arch
===
--- debian/templates-arch (revision 54931)
+++ debian/templates-arch (working copy)
@@ -18,6 +18,14 @@
Description: for internal use; can be preseeded
Package to use to generate initramfs
+Template: base-installer/kernel/linux/initramfs-tools/driver-policy
+Type: string
+Default: most
+Default[amd64]: dep
+Default[i386]: dep
+Description: for internal use
+ Default driver inclusion policy for initramfs-tools
+
Template: base-installer/kernel/linux/extra-packages
Type: string
Default:
Index: library.sh
===
--- library.sh (revision 54931)
+++ library.sh (working copy)
@@ -512,7 +512,7 @@
# initramfs-tools needs busybox pre-installed (and only
# recommends it)
- if [ $rd_generator = initramfs-tools ]; then
+ if [ $rd_generator = initramfs-tools ]; then
if ! log-output -t base-installer apt-install busybox; then
db_subst base-installer/kernel/failed-package-install PACKAGE busybox
exit_error base-installer/kernel/failed-package-install
@@ -549,6 +549,29 @@
rm $QUEUEFILE
FIRSTMODULE=0
done
+
+ # Select and set driver inclusion policy for initramfs-tools
+ if [ $rd_generator = initramfs-tools ]; then
+ if db_get base-installer/initramfs-tools/driver-policy \
+ [ $RET = ]; then
+# Get default for architecture
+db_get base-installer/kernel/linux/initramfs-tools/driver-policy
+db_set base-installer/initramfs-tools/driver-policy $RET
+ fi
+ db_input medium base-installer/initramfs-tools/driver-policy || true
+ if ! db_go; then
+db_progress stop
+exit 10
+ fi
+
+ db_get base-installer/initramfs-tools/driver-policy
+ cat /target/etc/initramfs-tools/conf.d/driver-policy EOF
+# Driver inclusion policy selected during installation
+# Note: this setting overrides the value set in the file
+# /etc/initramfs-tools/initramfs.conf
+MODULES=$RET
+EOF
+ fi
else
info Not installing an initrd generator.
fi
signature.asc
Description: This is a digitally signed message part.
Bug#494466: [patch, RFC] Allow to select driver inclusion policy for initramfs-tools
On Saturday 09 August 2008, Frans Pop wrote: With the default initrd now being over 6 GB on amd64 and the fact that That should have been MB. Still insane. signature.asc Description: This is a digitally signed message part.
