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
Processed: Re: Bug#750586: syslinux-common: Boot fails. Failed to load ldlinux.c32. File must be in /. Upstream bug
Processing commands for cont...@bugs.debian.org: reassign 750586 debian-installer Bug #750586 [syslinux-common] syslinux-common: Boot fails. Failed to load ldlinux.c32. File must be in /. Upstream bug Bug reassigned from package 'syslinux-common' to 'debian-installer'. No longer marked as found in versions syslinux/3:6.03~pre1+dfsg-4. Ignoring request to alter fixed versions of bug #750586 to the same values previously set thanks Stopping processing here. Please contact me if you need assistance. -- 750586: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750586 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.140196829621601.transcr...@bugs.debian.org
Re: 7.6 and 6.0.10
On Wed, Jun 04, 2014 at 09:53:21PM +0100, Adam D. Barratt wrote: Giving ourselves the usual pre-window to get organised, some suggested dates would be: - June 28/29 If it's early on the 29th, that's ok. Otherwise I'll be away. I could do it at a push though - July 5/6 Running a half marathon, so not free :) - July 12/13 - July 19/20 - July 26/27 All fine. Neil -- 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/20140605121637.go7...@halon.org.uk
Bug#750698: libevdev: please build libevdev2-udeb
Source: libevdev Version: 1.2.1+dfsg-1 Severity: normal Tags: d-i X-Debbugs-Cc: debian-boot@lists.debian.org Hi, recent versions of xf86-input-evdev require libevdev, which means we're going to need a libevdev2-udeb package to include in debian-installer builds. I can prepare a patch if needed, just let me know. Cheers, Julien signature.asc Description: Digital signature
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 :) Fix pushed. 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. flash-kernel upgrade rather than on install via di is a worry. Bootargs gets overridden to the default from
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. 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 :) Fix pushed. 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
Linux kernel ABI bump in experimental: from 3.15-rc7 to 3.15-rc8
Linux kernel ABI bump in experimental: from 3.15-rc7 to 3.15-rc8 Full summary: http://d-i.debian.org/kernel-summary.html#experimental -- 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/e1wsi2s-m7...@dillon.debian.org
