Re: [RFC] flash-kernel hook to prepend to boot script
On Thu, 2014-06-05 at 16:49 -0600, dann frazier wrote: > > + if dpkg --compare-versions "$configver" ge "$transver"; then > > hm.. that should probably be s/ge/ge-nl/. In the case of a fresh > install, I don't think we want to incorporate /proc/cmdline. f-k-i > will do that for us at d-i install time, and we probably don't want to > make assumptions about the environment if the user is installing f-k > outside of d-i. Yes, I think supporting apt-get install flash-kernel is useful for people trying to install on a system which doesn't yet have flash-kernel support. Sure they could edit /etc/defaults/flash-kernel by hand while they are mucking around with /etc/flash-kernel/db -- but it would be better if they didn't have to. Ian -- 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/1402039951.7269.92.ca...@dagon.hellion.org.uk
Re: [RFC] flash-kernel hook to prepend to boot script
On Thu, 2014-06-05 at 15:13 -0600, dann frazier wrote: > > 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. > > Either works for me. Lets update the README then, this setting is supposed to be used for exceptional cases anyhow. If you feel like nuking all the existing :yes entries that would be great too. > > 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? > > That sounds reasonable/correct to me - I don't want to make anyone > unbootable, even in sid->sid upgrades. But my debconf foo is weak, so > I'm not sure what the best way to do this is. Me neither. > Maybe we could add a > mapping of model strings and the corresponding f-k version at which > each model started including L_K_C support to the postinst. When > crossing that boundary (version test), we could preload any > non-duplicate /proc/cmdline options to flash-kernel/linux_cmdline. > > Here's an untested patch to explain using code: I think you can put the transition version into the DB eg. Bootscript-Bootargs-From: 3.20 > "Cubietech Cubietruck") > + transver=1.20 ;; ITYM 3.20? Another approach would be to add the marker to all of the scripts and just do it unconditionally for installs of 3.20 onwards and require all new scripts to use it in the future. I appreciate why you might not want to risk changing some of the existing ones though. Another possible alternative would be to check for the presence of magic string in the specified boot.scr. Ian; -- 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/1402039793.7269.89.ca...@dagon.hellion.org.uk
Re: [RFC] flash-kernel hook to prepend to boot script
On Thu, Jun 05, 2014 at 03:13:33PM -0600, dann frazier wrote: > On Thu, Jun 05, 2014 at 08:43:02AM +0100, Ian Campbell wrote: > > 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. >
Re: [RFC] flash-kernel hook to prepend to boot script
On Thu, Jun 05, 2014 at 08:43:02AM +0100, Ian Campbell wrote: > 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. Oh, good catch - obviously I haven't tested a Debian install on that system yet
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
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))" > > > > > > > >
Re: [RFC] flash-kernel hook to prepend to boot script
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. Reading the diffs in my mail client suggested there was some mixing of hard and soft tabs, butthat's only a minor thing. I didn't see any boot.scr using this stuff, I suppose that is to come? I'll probably make the sunxi/cubietruck stuff use it at some point. 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. > > > > > > -- 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/1401439837.15871.51.ca...@hastur.hellion.org.uk
Re: [RFC] flash-kernel hook to prepend to boot script
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? -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. > > -- 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/20140528223053.GC5663@fluid.dannf
Re: [RFC] flash-kernel hook to prepend to boot script
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
Re: [RFC] flash-kernel hook to prepend to boot script
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? 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). > +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? 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)? Ian. -- 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/1401101671.24177.14.ca...@dagon.hellion.org.uk
[RFC] flash-kernel hook to prepend to boot script
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?
diff -urpN flash-kernel-3.17.orig/debian/dirs flash-kernel-3.17/debian/dirs
--- flash-kernel-3.17.orig/debian/dirs 2012-03-31 00:48:17.0 -0600
+++ flash-kernel-3.17/debian/dirs 2014-05-21 14:15:37.775191416 -0600
@@ -1 +1,3 @@
usr/sbin
+etc/flash-kernel/ubootenv.d
+usr/share/flash-kernel/ubootenv.d
diff -urpN flash-kernel-3.17.orig/debian/flash-kernel-installer.postinst
flash-kernel-3.17/debian/flash-kernel-installer.postinst
--- flash-kernel-3.17.orig/debian/flash-kernel-installer.postinst
2014-02-28 20:20:00.0 -0700
+++ flash-kernel-3.17/debian/flash-kernel-installer.postinst2014-05-21
14:55:40.397881137 -0600
@@ -100,6 +100,10 @@ fi
trap - EXIT HUP INT QUIT TERM
mv /target/tmp/flash-kernel.$$ /target/usr/sbin/flash-kernel
+user_params="$(echo $(user-params))"
+echo "setenv bootargs '$user_params'" > \
+/target/etc/flash-kernel/ubootenv.d/00bootargs
+
# We need the udev /dev which has the MTD devices
mount -o bind /dev /target/dev
if ! in-target flash-kernel; then
diff -urpN flash-kernel-3.17.orig/functions flash-kernel-3.17/functions
--- flash-kernel-3.17.orig/functions2014-04-11 09:50:32.0 -0600
+++ flash-kernel-3.17/functions 2014-05-21 14:17:19.616268524 -0600
@@ -215,6 +215,19 @@ gen_kernel() {
} >"$output"
}
+gen_ubootenv() {
+ ENVSTUBDIRS="/etc/flash-kernel/ubootenv.d
/usr/share/flash-kernel/ubootenv.d"
+ ENVSTUBS="$(find $ENVSTUBDIRS -type f -regex '.*/[0-9a-zA-Z_-]+'
-printf '%f\n' | LC_ALL=C sort -u)"
+ for file in $ENVSTUBS; do
+ for dir in $ENVSTUBDIRS; do
+ if [ -f $dir/$file ]; then
+ cat $dir/$file
+ break
+ fi
+ done
+ done
+}
+
append_dtb() {
local kernel="$1"
local dtb="$2"
@@ -623,7 +636,9 @@ case "$method" in
fi
if [ -n "$boot_script_path" ]; then
boot_script_path="$boot_mnt_dir/$boot_script_path"
- boot_script="$BOOTSCRIPTS_DIR/$usname"
+ boot_script="$tmpdir/bootscript"
+ gen_ubootenv > "$boot_script"
+ cat "$BOOTSCRIPTS_DIR/$usname" >> "$boot_script"
mkimage_script "$usaddr" "boot script" "$boot_script" \
"$tmpdir/boot.scr"
boot_script="$tmpdir/boot.scr"
--
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/20140521205940.GB30318@fluid.dannf
