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.
> 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/20140527163518.GA4756@fluid.dannf
