Re: [RFC] flash-kernel hook to prepend to boot script
On Fri, May 30, 2014 at 09:50:37AM +0100, Ian Campbell wrote:
> On Wed, 2014-05-28 at 16:30 -0600, dann frazier wrote:
> > 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?
>
> It does.
>
> I'm travelling right now but I took a brief look through the patches, I
> think you should go ahead and push them.
My target platform is actually an arm64 system, which I can't easily
test it with Debian's d-i (yet). But I did manage to find an armhf
system to test on this week. There were a few issues with my changes
that I found/fixed (multiline support for ubootenv stubs,
brokendebconf-set-selections call, etc), but it seems to be working as
expected now. I went ahead and also added support for the armhf test
system I used (Calxeda Highbank) and my target platform (APM Mustang),
which also required turning on arm64 support.
> Reading the diffs in my mail
> client suggested there was some mixing of hard and soft tabs, butthat's
> only a minor thing.
Should be fixed in the merged version.
> I didn't see any boot.scr using this stuff, I suppose that is to
> come?
Yeah - added this for both new platforms I've introduced.
> I'll probably make the sunxi/cubietruck stuff use it at some point.
Cool. In the meantime, I'll plan to do an f-k upload tomorrow, in case
anyone wants to take some time to review the merged changes.
-dann
> Ian.
>
> >
> > -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.
> > >
> > >
> >
> >
>
>
>
Reply to: