Re: flash-kernel and dtb
On Sun, Jun 15, 2014 at 11:18:49AM +0100, Ian Campbell wrote:
> On Sat, 2014-06-14 at 15:37 -0700, Vagrant Cascadian wrote:
> > As I've been writing up a few bootscripts for flash-kernel lately, I've been
> > wondering about what makes sense for bootargs...
> >
> > With flash-kernel 3.20+, bootargs from the u-boot env are silently ignored
> > when using bootscripts that set bootargs... the default bootargs is "quiet".
> >
> > Should the bootscript only set bootargs if not already set by u-boot?
>
> I'm not sure, but I agree that it is something which needs thinking
> about.
>
> dannf was looking into preserving /proc/cmdline
> into /etc/flash-kernel/default when upgrading to a new flash-kernel with
> this new behaviour, which would be a good start, I think.
I have just been looking at the code for copying over bootargs in d-i.
During installing with d-i, the code in flash-kernel-installer.postinst from
http://anonscm.debian.org/gitweb/?p=d-i/flash-kernel.git;a=commit;h=6dd3f0e7e5a3462999944e4b60720f418579a615
copies the d-i "user-params" part of /proc/cmdline, i.e. the
parameters listed after a "--", into /etc/flash-kernel/default, but not
any of the kernel/module parameters listed before the "--".
I am not sure that we should handle commandline parameters this way.
The current code tries to avoid copying "factory-defined" preseeding
parameters that are used on the d-i boot menu (and which are listed
before the "--"). AFAIK we do not have boot menu support on any arm
system and doing things this way poses a problem when setting
"console=foo" is required to have console output or when
module-specific parameters are needed during the boot process and those
parameters are put before the "--" (wich they usually are as they are
intended as kernel parameters and not as userland parameters).
_If_ we want to keep overwriting the u-boot envinronment in boot.scr, I
think we should copy all parameters from /proc/cmdline used while
booting d-i into /etc/flash-kernel/default. This will potentially put
unneeded preseeding information there, but on the other hand we can be
sure that required console and module parameters are preserved and the
superfluous preseeding parameters should not have any negative
influence on the boot process.
Personally I would prefer not to completely replace bootargs in the
boot.scr but to just append parameters from /etc/flash-kernel/default
to it. This could cause some parameters to appear more than once with
contradicting values, but AFAIK if this happens, the kernel always uses
the last value on the commandline, so this should result in a
deterministic behaviour.
Comments and opinions welcome :-)
Regards,
Karsten
--
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
Reply to: