Re: [RFC] flash-kernel hook to prepend to boot script
On Wed, 2014-06-04 at 11:40 -0600, dann frazier wrote:
> 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.
Mostly looks good too me.
The xgene script is missing the extra bootenv marker.
Bootloader-Sets-Incorrect-Root is marked "required" in the README but is
omitted from X-gene. I think since 850c8fc3 the behaviour when missing
is now to treat it as "no" which is the sane default, so perhaps the fix
is to make the README reflect that rather than fiddle with the Xgene db
entry.
flash-kernel upgrade rather than on install via di is a worry. Bootargs
gets overridden to the default from /etc/default/flash-kernel which will
be missing root= etc. On my cubietruck after dpkg -i of 3.20 I 've ended
up with:
setenv bootargs 'quiet'
in my boot.scr, which isn't going to boot I think. (actually, I as
discovered below it probably would, although missing console= is a
concern...)
This could just mean that we need to be a bit careful when adding
@@LINUX_KERNEL_CMDLINE@@ to existing bootscripts, since we've not
released with CT support I think it would be safe to do in that case.
Other than that I'm at a loss what to suggest, perhaps something probed
from /proc/cmdline when first installing a version >= 3.20?
Then I edited /etc/default/flash-kernel by hand to
LINUX_KERNEL_CMDLINE="quiet root=/dev/sda2
console=ttyS0,115200n"
But:
# flash-kernel
Installing sun7i-a20-cubietruck.dtb 3.15-rc7-armmp into /boot
flash-kernel: installing version 3.15-rc7-armmp
Generating boot script u-boot image... sed: -e expression #2, char 40: unknown option to `s'
Because of the / in /dev/sda2 perhaps. It turns out root= can be omitted
here because it's also done in
initramfs-tools/hooks/flash_kernel_set_rootm which sets the default in
case the command line is missing it. That's OK, but it would be nice if
we could be arranging for / to be allowed here -- someone is eventually
going to add root= to /etc/defaults and break their system...
With root= gone from there things work on my CT.
Cheers,
Ian.
Reply to: