On Tue, May 27, 2014 at 10:35:18AM -0600, dann frazier wrote: > On Mon, May 26, 2014 at 11:54:31AM +0100, Ian Campbell wrote: > > On Wed, 2014-05-21 at 14:59 -0600, dann frazier wrote: > > > hey, > > > A couple of projects we're working on at work require some > > > tweaking of u-boot settings. These requirements can be summed up by: > > > > > > A) Maintain the console= setting, and ideally all userargs (the > > > cmdline args after "--") after install. This seems like standard > > > Debian functionality that exists on other architectures, but is > > > currently missing on flash-kernel platforms. > > > > > > B) The ability to let a package change settings in the u-boot > > > environment. We have a case where a u-boot envvar setting > > > needs to differ depending on whether or not certain software > > > will be used (their u-boot has special code that reconfigures > > > the hardware depending on the setting of this variable). > > > > > > The systems we're dealing with use a boot.scr script generated by > > > flash-kernel. So, we figure we could solve both by letting packages > > > drop in u-boot code snippets that will be prepended to the > > > boot.scr. To do this, we propose a scheme similar to initramfs-tools > > > where packages can drop snippets in a path under /usr/share (solving > > > B), and users can add their own new setings or override the /usr/share > > > versions by dropping snippets under /etc. With this scheme in place, > > > flash-kernel-installer could be extended to drop in a file in /etc > > > that does a 'setenv bootargs $userargs' to solve (A). Comments? > > > > I think snippets like this are a useful idea in general, but I wonder if > > something like the command line isn't deserving of "higher billing", > > e.g. via a setting in /etc/defaults/flash-kernel:COMMAND_LINE? > > It looks like Ubuntu is carrying a patch that does this today: > > > http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/utopic/flash-kernel/utopic/revision/443.2.7 > > There the the variable is called "UBOOT_DEFAULTS". I think > "KERNEL_CMDLINE" would be a more obvious name, but it would also be > nice to be reducing their diff.
Looking at grub as an example, I think we'll want to make the cmdline paramaters a debconf setting, giving the user the option to modify the proposed cmdline in expert mode. 1) f-k-i would use user-params to generate a reasonable default set cmdline args and set flash-kernel/linux_cmdline. 2) f-k/configure would prompt the user (priority=high) for changes to this default during configuration. 3) f-k/postinst would generate /etc/default/flash-kernel, and presumably using ucf to manage it from there on Sound reasonable? -dann > > FWIW latest Debian flash-kernel supports substituting @@KERNEL_VERSION@@ > > in the boot.scr with the actual kernel version in use. We could follow a > > similar path for command line args (e.g. if you agree /e/d/flash-kernel > > is a good place for this setting). > > Yeah, that makes sense. For non-cmdline options, should we make that a > substitution as well (e.g. @@UBOOT_ENV_EXTRA@@), or automatically prepend > the snippets for every boot.scr? The former might be nice if we want > to transition platforms over individually as we can test them. But, > the downside is inconsistency until then. > > > > +user_params="$(echo $(user-params))" > > > > What does this contain in practice? Just the post "--" stuff given to > > the installer or also the generated root= stuff etc? > > Just the post "--" stuff. It also works with preseeding > (debian-installer/add-kernel-opts). > > > How does this interact with the Bootloader-Sets-Incorrect-Root setting? > > Should it consume the same settings somehow (assuming root= is involved > > here at all)? > > It looks like that logic is all in an initramfs hook, so there should > be no interaction there. > > -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140528223053.GC5663@fluid.dannf