On Sun, 2014-06-15 at 15:14 +0200, Karsten Merker wrote: > 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 think Dann did it this way because that's the way bootloaders on other platforms (at least grub on x86) are handled. I think we want to be consistent in this. > 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. AFAICT this is a good plan. Ian. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
