Bug#831003: support gzip'd kernel image
Package: flash-kernel Version: 3.67 Tags: patch flash-kernel currently always sets the compression type to "none" when generating uImages. However, if the source vmlinuz file is gzip'd - as is the case if you build the "Image.gz" kernel target - this will prevent U-Boot from being able to boot it[1]. If the uImage is generated with a compression type of "gzip", then it boots fine. The attached patch checks the source image type and sets the compression setting appropriately. [1] At least, this is true on APM Mustang systems diff -urpN flash-kernel-3.67/debian/changelog flash-kernel-3.68/debian/changelog --- flash-kernel-3.67/debian/changelog 2016-06-20 00:20:31.0 -0600 +++ flash-kernel-3.68/debian/changelog 2016-07-13 09:33:53.714642651 -0600 @@ -1,3 +1,9 @@ +flash-kernel (3.68) UNRELEASED; urgency=medium + + * Add support for gzip-compressed kernel images + + -- dann frazier Wed, 13 Jul 2016 09:22:49 -0600 + flash-kernel (3.67) unstable; urgency=medium [ Vagrant Cascadian ] diff -urpN flash-kernel-3.67/functions flash-kernel-3.68/functions --- flash-kernel-3.67/functions 2016-04-01 21:01:45.0 -0600 +++ flash-kernel-3.68/functions 2016-07-13 09:25:43.520547829 -0600 @@ -409,15 +409,31 @@ get_kernel_cmdline_defaults() { echo "$LINUX_KERNEL_CMDLINE_DEFAULTS" } +compress_type() { +local file="$1" +magic="$(od -x -N2 $file | head -1 | cut -d' ' -f2)" +case $magic in + 8b1f) + echo "gzip" + ;; + *) + echo "none" + ;; +esac +} + mkimage_kernel() { local kaddr="$1" local epoint="$2" local kdesc="$3" local kdata="$4" local uimage="$5" + local comp + + comp="$(compress_type $kdata)" printf "Generating kernel u-boot image... " >&2 - mkimage -A arm -O linux -T kernel -C none -a "$kaddr" -e "$epoint" \ + mkimage -A arm -O linux -T kernel -C $comp -a "$kaddr" -e "$epoint" \ -n "$kdesc" -d "$kdata" "$uimage" >&2 1>/dev/null echo "done." >&2 } diff -urpN flash-kernel-3.67/test_functions flash-kernel-3.68/test_functions --- flash-kernel-3.67/test_functions 2016-02-14 21:01:43.0 -0700 +++ flash-kernel-3.68/test_functions 2016-07-13 09:28:35.812630206 -0600 @@ -569,23 +569,40 @@ test_set_machine_id() { } add_test test_set_machine_id -test_mkimage_kernel() { +_test_mkimage_kernel() { +local kdata="$1" +local expected="$2" ( mkimage() { saved_args="$@" } . "$functions" saved_args="" -mkimage_kernel "0xdeadbeef" "0xbaddcafe" "desc" "input" "output" 2>/dev/null -expected="-A arm -O linux -T kernel -C none -a 0xdeadbeef -e 0xbaddcafe -n desc -d input output" +mkimage_kernel "0xdeadbeef" "0xbaddcafe" "desc" "$kdata" "output" 2>/dev/null if [ "$expected" != "$saved_args" ]; then echo "Expected mkimage_kernel to be called with \"$expected\" but it was called with \"$saved_args\"" >&2 -exit 1 +return 1 fi ) } + +test_mkimage_kernel() { +local kdata="/dev/zero" +local expected="-A arm -O linux -T kernel -C none -a 0xdeadbeef -e 0xbaddcafe -n desc -d $kdata output" +_test_mkimage_kernel "$kdata" "$expected" || exit 1 +} add_test test_mkimage_kernel +test_mkimage_kernel_gzip() { +local kdata="$(mktemp)" +gzip < /dev/null > "$kdata" + +local expected="-A arm -O linux -T kernel -C gzip -a 0xdeadbeef -e 0xbaddcafe -n desc -d $kdata output" +_test_mkimage_kernel "$kdata" "$expected" || exit 1 +rm -f "$kdata" +} +add_test test_mkimage_kernel_gzip + test_mkimage_initrd() { ( mkimage() {
Bug#776782: x86/mac: false warning about being in EFI mode
Package: partman-efi Version: 62 Severity: normal Tags: d-i patch If you boot an x86/mac in legacy BIOS mode with a pre-existing non-UEFI OS installed, you will get the following warning: "This machine's firmware has started the installer in UEFI mode but it looks like there may be existing operating systems already installed using "BIOS compatability mode". .. "Force UEFI Installation?" The following patch resolves the issue for me. diff --git a/init.d/efi b/init.d/efi index 7b71990..42f95dd 100755 --- a/init.d/efi +++ b/init.d/efi @@ -8,7 +8,11 @@ ARCH="$(archdetect)" # Give the kernel a chance to create /proc/efi if appropriate. modprobe efivars >/dev/null 2>&1 || true -if [ -d /proc/efi ] || [ -d /sys/firmware/efi ]; then +in_efi_mode() { +[ -d /proc/efi ] || [ -d /sys/firmware/efi ] +} + +if in_efi_mode; then > /var/lib/partman/efi else case $ARCH in @@ -86,7 +90,7 @@ done log "Found $NUM_ESP ESPs, $NUM_NO non-ESPs" -if [ $NUM_ESP = 0 ] && [ $NUM_NO -gt 0 ]; then +if in_efi_mode && [ $NUM_ESP = 0 ] && [ $NUM_NO -gt 0 ]; then case $ARCH in i386/*|amd64/*) db_input critical partman-efi/non_efi_system || true -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- 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/20150201171327.24292.29007.reportbug@fluid.dannf
Re: libdebian-installer_0.99_source.changes ACCEPTED into unstable
On Fri, Jan 30, 2015 at 07:15:32AM +0100, Cyril Brulebois wrote: > Christian PERRIER (2015-01-30): > > Quoting dann frazier (da...@dannf.org): > > > On Thu, Jan 29, 2015 at 07:01:32AM +0100, Christian PERRIER wrote: > > > > Unless I'm wrong, the released changelog hasn't been pushed in git nor > > > > has the 0.99 released been tagged. > > > > > > I did push it - and I do see the tag: > > > http://anonscm.debian.org/cgit/d-i/libdebian-installer.git/ > > > > > > But perhaps I did something incorrectly? Did you expect to see it on > > > the jessie branch? That branch looked pretty out of date, so I just > > > pushed to master. > > > > ...which is fine...but I don't see anything on my local copies, even > > after a "git pull". > > > > May anyone else confirm (KiBi?) so that I know if that's a problem > > only on my side? > > master wasn't pushed to the repository, meaning that the (pushed) 0.99 > tag isn't reachable by any of the branches you're fetching from the > repository. That explains why you're not seeing an updated master *and* > the (pushed) 0.99 tag. dann's pushing his local master branch should fix > both issues. Ah, I see. Pushed now - thanks for explaining! -- 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/20150130161455.GA32435@fluid.dannf
Re: libdebian-installer_0.99_source.changes ACCEPTED into unstable
On Thu, Jan 29, 2015 at 07:01:32AM +0100, Christian PERRIER wrote: > > > Changes: > > libdebian-installer (0.99) unstable; urgency=medium > > . > >* Replace NULL terminator for the arm map_hardware table, accidentally > > dropped in 0.92 (Closes: #776488). > > > Hello Dann, hey Christian! > Unless I'm wrong, the released changelog hasn't been pushed in git nor > has the 0.99 released been tagged. I did push it - and I do see the tag: http://anonscm.debian.org/cgit/d-i/libdebian-installer.git/ But perhaps I did something incorrectly? Did you expect to see it on the jessie branch? That branch looked pretty out of date, so I just pushed to master. > Though not urgent at all, can you fix this at some moment. > > Thanks for your work on D-I (it has been s long:-)) Yeah - I do enjoy it when I have the opportunity :) -- 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/20150129201534.GB32024@fluid.dannf
Bug#776488: regression: arm map_hardware[] not NULL terminated
On Wed, Jan 28, 2015 at 06:10:49PM +0100, Cyril Brulebois wrote: > dann frazier (2015-01-28): > > Package: libdebian-installer4 > > Version: 0.98 > > Severity: serious > > Tags: d-i patch > > > > The map_hardware[] table in src/system/subarch-arm-linux.c is no longer NULL > > terminated. I believe this could lead to a segfault on armel/armhf > > platforms, > > resulting in a failed install. > > > > This bug was introduced back in version 0.92. The end of the table was > > trimmed, > > and accidentally took the NULL terminator with it: > > > > http://anonscm.debian.org/cgit/d-i/libdebian-installer.git/commit/?id=3a7209e49fa5cfe8c4e4122325405022031a8afc > > > > DISCLAIMER: I haven't actually observed a crash, I just discovered this > > while > > reviewing source. But it does seem like a potential time-bomb we should fix > > pre-release. Here's the obvious patch: > > > > diff --git a/src/system/subarch-arm-linux.c b/src/system/subarch-arm-linux.c > > index 590576a..3fc5e2a 100644 > > --- a/src/system/subarch-arm-linux.c > > +++ b/src/system/subarch-arm-linux.c > > @@ -103,6 +103,7 @@ static struct map map_hardware[] = { > > { "OMAP3 Beagle Board", "omap" }, > > { "OMAP4 Panda Board", "omap" }, > > { "ARM-Versatile Express", "vexpress" }, > > +{ NULL, NULL } > > }; > > I was about to push it but you apparently already did; adjusting tags > accordingly. Cool, thanks :) Do you +1 me uploading this? If so, should I request an unblock or does that need to come from you? -- 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/20150128171615.GD15696@fluid.dannf
Bug#776488: regression: arm map_hardware[] not NULL terminated
Package: libdebian-installer4 Version: 0.98 Severity: serious Tags: d-i patch The map_hardware[] table in src/system/subarch-arm-linux.c is no longer NULL terminated. I believe this could lead to a segfault on armel/armhf platforms, resulting in a failed install. This bug was introduced back in version 0.92. The end of the table was trimmed, and accidentally took the NULL terminator with it: http://anonscm.debian.org/cgit/d-i/libdebian-installer.git/commit/?id=3a7209e49fa5cfe8c4e4122325405022031a8afc DISCLAIMER: I haven't actually observed a crash, I just discovered this while reviewing source. But it does seem like a potential time-bomb we should fix pre-release. Here's the obvious patch: diff --git a/src/system/subarch-arm-linux.c b/src/system/subarch-arm-linux.c index 590576a..3fc5e2a 100644 --- a/src/system/subarch-arm-linux.c +++ b/src/system/subarch-arm-linux.c @@ -103,6 +103,7 @@ static struct map map_hardware[] = { { "OMAP3 Beagle Board", "omap" }, { "OMAP4 Panda Board", "omap" }, { "ARM-Versatile Express", "vexpress" }, +{ NULL, NULL } }; static int read_dt_model(char *entry, int entry_len) -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libdebian-installer4 depends on: ii libc6 2.19-13 ii multiarch-support 2.19-13 libdebian-installer4 recommends no packages. libdebian-installer4 suggests no packages. -- no debconf information -- 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/20150128160256.22696.62545.reportbug@fluid.dannf
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 > > &
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 arm
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.
[PATCH 1/3] Generate flash-kernel-installer.postinst based on a template
This is a no-op preparatory commit, intended to make it easier to review future commits. f-k-i.postinst becomes f-k-i.postinst.in, which is now used to "generate" the former using cat as a placeholder. --- debian/flash-kernel-installer.postinst| 114 -- debian/flash-kernel-installer.postinst.in | 114 ++ debian/rules | 13 3 files changed, 127 insertions(+), 114 deletions(-) delete mode 100755 debian/flash-kernel-installer.postinst create mode 100755 debian/flash-kernel-installer.postinst.in diff --git a/debian/flash-kernel-installer.postinst b/debian/flash-kernel-installer.postinst deleted file mode 100755 index 9017ac3..000 --- a/debian/flash-kernel-installer.postinst +++ /dev/null @@ -1,114 +0,0 @@ -#!/bin/sh - -# This code is covered by the GNU General Public License (GPLv2 or higher) - -set -e - -FK_DIR="/usr/share/flash-kernel" - -. "${FK_CHECKOUT:-$FK_DIR}/functions" - -. /usr/share/debconf/confmodule - -log() { - logger -t flash-kernel-installer "$@" -} - -error() { - log "error: $@" - db_progress STOP - exit 1 -} - -findfs () { - mount | grep "on /target${1%/} " | tail -n1 | cut -d' ' -f1 -} - -get_machine - -if machine_uses_flash "$machine"; then - db_progress START 0 3 flash-kernel-installer/progress -else - db_progress START 0 3 flash-kernel-installer/progress_disk -fi -db_progress INFO flash-kernel-installer/prepare - -# Stop fsck from prompting the user for input since most users don't -# have a serial console. -if [ -e /target/etc/default/rcS ]; then - sed -i -e "s/^FSCKFIX=no$/FSCKFIX=yes/" /target/etc/default/rcS || true -fi -if [ -e /target/etc/default/fsck ]; then - sed -i -e "s/^#FSCKFIX=no$/FSCKFIX=yes/" -e "s/^FSCKFIX=no$/FSCKFIX=yes/" /target/etc/default/fsck || true -fi - -if ! apt-install flash-kernel; then - error "apt-install flash-kernel failed" -fi - -# Temporarily move flash-kernel out of the way so update-initramfs -# won't call flash-kernel; otherwise we might call it twice. -mv /target/usr/sbin/flash-kernel /target/tmp/flash-kernel.$$ -trap "mv /target/tmp/flash-kernel.$$ /target/usr/sbin/flash-kernel" EXIT HUP INT QUIT TERM - -db_progress STEP 1 - -for package in $(get_machine_field "$machine" "Optional-Packages"); do - if ! apt-install "$package"; then - log "apt-install $package failed" - fi -done -for package in $(get_machine_field "$machine" "Required-Packages"); do - if ! apt-install "$package"; then - error "apt-install $package failed" - fi -done - -case "$machine" in - "Linksys NSLU2") - # installing nslu2-utils will call update-initramfs -u - : - ;; - *) - in-target update-initramfs -u || true - ;; -esac - -if [ "$machine" = "HP Media Vault mv2120" ]; then - # The firmware loads /boot/uImage from the first partition - # but uImage will be in / if a separate boot partition is - # used. In this case, create a /boot/boot -> /boot symlink. - # Note that a partman check will make sure that /boot (if - # it exists) or / (if there's no separate /boot) are on the - # first partition. - rootfs=$(findfs /) - bootfs=$(findfs /boot) - if [ "$rootfs" != "$bootfs" ]; then - if [ ! -e /target/boot/boot ]; then - ln -s . /target/boot/boot - fi - fi -fi - -db_progress STEP 1 -if machine_uses_flash "$machine"; then - db_progress INFO flash-kernel-installer/flashing -else - db_progress INFO flash-kernel-installer/generating_image -fi - -trap - EXIT HUP INT QUIT TERM -mv /target/tmp/flash-kernel.$$ /target/usr/sbin/flash-kernel - -# We need the udev /dev which has the MTD devices -mount -o bind /dev /target/dev -if ! in-target flash-kernel; then - umount /target/dev || true - error "flash-kernel failed" -fi -umount /target/dev || true - -db_progress STEP 1 -db_progress STOP - -# vim:noexpandtab shiftwidth=8 diff --git a/debian/flash-kernel-installer.postinst.in b/debian/flash-kernel-installer.postinst.in new file mode 100755 index 000..9017ac3 --- /dev/null +++ b/debian/flash-kernel-installer.postinst.in @@ -0,0 +1,114 @@ +#!/bin/sh + +# This code is covered by the GNU General Public License (GPLv2 or higher) + +set -e + +FK_DIR="/usr/share/flash-kernel" + +. "${FK_CHECKOUT:-$FK_DIR}/functions" + +. /usr/share/debconf/confmodule + +log() { + logger -t flash-kernel-installer "$@" +} + +error() { + log "error: $@" + db_progress STOP + exit 1 +} + +findfs () { + mount | grep "on /target${1%/} " | tail -n1 | cut -d' ' -f1 +} + +get_machine + +if machine_uses_flash "$machine"; then + db_progress START 0 3 flash-kernel-installer/progress +else + db_progress START 0 3 flash-kernel-installer/progress_disk +fi +db_progress INFO flash-k
[PATCH 0/3] flash-kernel u-boot command/console support
Here's a patch series that implements the aforementioned changes for making it possible to have packages prepend u-boot commands to the boot.scr, and a special case for managing the kernel cmdline. I'd appreciate reviews, and any +/-1s for pushing these changes. -- 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/1401414889-16498-1-git-send-email-da...@debian.org
[PATCH 3/3] Add support for prepending arbitrary u-boot commands to a bootscript
Allow packages to drop in files containing U-Boot commands to be executed by a platform's bootscript before starting the OS. These files should be dropped in /usr/share/flash-kernel/ubootenv.d. Users can add additional stubs, or override stubs provided by packages, by adding files to /etc/flash-kernel/ubootenv.d. Files in the /etc path that have the same name as files in the /usr path will override the /usr counterparts. Platform bootscripts must contain the @@UBOOT_ENV_EXTRA@@ macro for the contents of these stubs to be incorporated. --- README | 18 ++ debian/dirs | 2 ++ functions | 14 ++ 3 files changed, 34 insertions(+) diff --git a/README b/README index 99e63a2..38d2953 100644 --- a/README +++ b/README @@ -172,6 +172,24 @@ Configuration files currently supported: * /etc/flash-kernel/db allows overriding / adding fields from the Machine database (but it doesn't allow removing fields or entries). +* /etc/flash-kernel/ubootenv.d can be used to add or override u-boot + script snippets. See "Adding U-Boot Commands for Pre-Boot Execution" + below for more details. + * /etc/default/flash-kernel currently contains a single variable, LINUX_KERNEL_CMDLINE, which should be used by bootscripts to set kernel options. + + +Adding U-Boot Commands for Pre-Boot Execution +- - - - - - - - - - - - - - - - - - - - - - - + +Packages can drop in files containing U-Boot commands to be executed by a +platform's bootscript before starting the OS. These files should be +dropped in /usr/share/flash-kernel/ubootenv.d. Users can add additional +stubs, or override stubs provided by packages, by adding files to +/etc/flash-kernel/ubootenv.d. Files in the /etc path that have the same +name as files in the /usr path will override the /usr counterparts. + +Platform bootscripts must contain the @@UBOOT_ENV_EXTRA@@ macro for the +contents of these stubs to be incorporated. diff --git a/debian/dirs b/debian/dirs index 236670a..2788a14 100644 --- a/debian/dirs +++ b/debian/dirs @@ -1 +1,3 @@ usr/sbin +etc/flash-kernel/ubootenv.d +usr/share/flash-kernel/ubootenv.d diff --git a/functions b/functions index fc10684..58b7ad1 100644 --- a/functions +++ b/functions @@ -216,6 +216,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" @@ -293,6 +306,7 @@ mkimage_script() { printf "Generating boot script u-boot image... " >&2 sed -e "s/@@KERNEL_VERSION@@/$kvers/g" \ -e "s/@@LINUX_KERNEL_CMDLINE@@/$(get_kernel_cmdline)/g" \ +-e "s/@@UBOOT_ENV_EXTRA@@/$(gen_ubootenv)/g" \ < $sdata > $tdata mkimage -A arm -O linux -T script -C none -a "$saddr" -e "$saddr" \ -n "$sdesc" -d "$tdata" "$script" >&2 1>/dev/null -- 2.0.0 -- 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/1401414889-16498-4-git-send-email-da...@debian.org
[PATCH 2/3] Add kernel commandline configuration support
/etc/default/flash-kernel is added with a LINUX_KERNEL_CMDLINE variable that can optional be used in u-boot bootscripts. This command line is generated using the distribution default (defaults for Debian and Ubuntu are provided), and will incorporate any user-provided commandline arguments provided at install time. This setting is configured via debconf, so can be overridden in expert mode by the user. Most of this logic is heavily leveraged from grub2's packaging. Bootscripts can incorporate this setting by adding the @@LINUX_KERNEL_CMDLINE@@ macro. For example, a simple such bootscript might look like: setenv bootargs '@@LINUX_KERNEL_CMDLINE@@' ext4load scsi 0 ${kernel_addr_r} vmlinuz ext4load scsi 0 ${ramdisk_addr_r} initrd.gz bootz ${kernel_addr_r} ${ramdisk_addr_r} --- README| 5 +++- debian/control| 3 ++- debian/default/flash-kernel.in| 1 + debian/flash-kernel-installer.postinst.in | 20 ++ debian/flash-kernel.config| 8 ++ debian/flash-kernel.install | 1 + debian/flash-kernel.postinst | 43 --- debian/flash-kernel.postrm| 22 debian/flash-kernel.templates.in | 5 debian/rules | 12 +++-- functions | 6 + 11 files changed, 119 insertions(+), 7 deletions(-) create mode 100644 debian/default/flash-kernel.in mode change 100755 => 100644 debian/flash-kernel-installer.postinst.in create mode 100644 debian/flash-kernel.config create mode 100644 debian/flash-kernel.postrm create mode 100644 debian/flash-kernel.templates.in diff --git a/README b/README index 6865a17..99e63a2 100644 --- a/README +++ b/README @@ -165,10 +165,13 @@ The supported fields are: Configuration - - - - - - - -Two configuration files are currently supported: +Configuration files currently supported: * /etc/flash-kernel/machine allows skipping the machine auto-detection from /proc/cpuinfo or /proc/dtmodel and forcing a specific Machine. * /etc/flash-kernel/db allows overriding / adding fields from the Machine database (but it doesn't allow removing fields or entries). +* /etc/default/flash-kernel currently contains a single variable, + LINUX_KERNEL_CMDLINE, which should be used by bootscripts to set kernel + options. diff --git a/debian/control b/debian/control index 835f28f..8ba0400 100644 --- a/debian/control +++ b/debian/control @@ -16,7 +16,8 @@ Architecture: armel armhf Depends: ${misc:Depends}, devio, initramfs-tools (>= 0.92f), - linux-base (>= 3.2) + linux-base (>= 3.2), + ucf Suggests: u-boot-tools Description: utility to make certain embedded devices bootable flash-kernel is a script which will put the kernel and initramfs in diff --git a/debian/default/flash-kernel.in b/debian/default/flash-kernel.in new file mode 100644 index 000..347d8ac --- /dev/null +++ b/debian/default/flash-kernel.in @@ -0,0 +1 @@ +LINUX_KERNEL_CMDLINE="@DEFAULT_CMDLINE@" diff --git a/debian/flash-kernel-installer.postinst.in b/debian/flash-kernel-installer.postinst.in old mode 100755 new mode 100644 index 9017ac3..134da41 --- a/debian/flash-kernel-installer.postinst.in +++ b/debian/flash-kernel-installer.postinst.in @@ -24,6 +24,10 @@ findfs () { mount | grep "on /target${1%/} " | tail -n1 | cut -d' ' -f1 } +tac () { + sed '1!G;h;$!d' +} + get_machine if machine_uses_flash "$machine"; then @@ -100,6 +104,22 @@ fi trap - EXIT HUP INT QUIT TERM mv /target/tmp/flash-kernel.$$ /target/usr/sbin/flash-kernel +def_params="@DEFAULT_CMDLINE@" +# reverse them so we prefix them in the right order +rev_def_params="$(echo $def_params | tr ' ' '\n' | tac)" +user_params=$(user-params) || true +kopt_params="$user_params" +for d_param in $rev_def_params; do + # Don't add redundant default params + if echo $kopt_params | tr ' ' '\n' | grep -q "^${d_param}$"; then + continue + else + kopt_params="$d_param${kopt_params:+ $kopt_params}" + fi +done + +echo "flash-kernel flash-kernel/linux_cmdline string $kopt_params" | in-target debconf-set-selections + # We need the udev /dev which has the MTD devices mount -o bind /dev /target/dev if ! in-target flash-kernel; then diff --git a/debian/flash-kernel.config b/debian/flash-kernel.config new file mode 100644 index 000..c39f93f --- /dev/null +++ b/debian/flash-kernel.config @@ -0,0 +1,8 @@ +#!/bin/sh + +set -e + +. /usr/share/debconf/confmodule + +db_input medium flash-kernel/linux_cmdline || /bin/true +db_go diff --git a/debian/flash-kernel.install b/debian/flash-kernel.install index 5d3aebd..ee1bf9d 100644 --- a/debian/flash-kernel.install +++ b/debian/flash-kernel.install @@ -7,3 +7,4 @@ initramfs-tools usr/share bootscript usr/share/flash-k
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
[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
Re: getty and hw flow control
On Tue, May 13, 2014 at 03:15:51AM +0200, Samuel Thibault wrote: > dann frazier, le Mon 12 May 2014 18:56:04 -0600, a écrit : > > I'm working on enabling a platform that I'm told will be using > > hardware flow control on the serial console. To prepare for this, I've > > put together this patch to detect the crtscts setting on the console, > > and set the -h flag for the getty. It works, but I'd appreciate a > > review by someone who knows serial more than I. > > It looks fine to me. > > > Specifically, is it possible that a system that uses crtscts would not > > behave well w/ 'getty -h'? > > No, since passing -h is exactly enabling CRTSCTS. Thanks for the review! Change pushed. -- 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/20140513022856.GB8097@fluid.dannf
getty and hw flow control
hey, I'm working on enabling a platform that I'm told will be using hardware flow control on the serial console. To prepare for this, I've put together this patch to detect the crtscts setting on the console, and set the -h flag for the getty. It works, but I'd appreciate a review by someone who knows serial more than I. Specifically, is it possible that a system that uses crtscts would not behave well w/ 'getty -h'? diff --git a/finish-install.d/90console b/finish-install.d/90console index 272e0a1..2ec91cc 100755 --- a/finish-install.d/90console +++ b/finish-install.d/90console @@ -17,6 +17,13 @@ write_console() { fi } +uses_hw_flowcontrol() { + local dev="$1" + + chroot /target stty -a --file /dev/$dev | tr ' ' '\n' | \ + grep -q '^crtscts$' +} + KEEP_VT= if db_get finish-install/keep-consoles && [ "$RET" = true ]; then KEEP_VT=1 @@ -61,6 +68,11 @@ case "$console" in ttyspeed=$(chroot /target stty --file /dev/$console speed) ttyterm="$TERM" + flowctrlarg="" + if uses_hw_flowcontrol $console; then + flowctrlarg="-h " + fi + if [ -z "$ttyterm" ]; then ttyterm=vt100; fi if [ -z "$ttyspeed" ]; then ttyspeed=9600; fi @@ -73,12 +85,14 @@ case "$console" in sed -i -e "s/^#T0\(.*\)ttyS.*/T$ttyline\1$console $ttyspeed $ttyterm/" \ /target/etc/inittab sed -i -e "s/^\(T$ttyline.*\) -8/\1/" /target/etc/inittab + sed -i -e "s/^\(T$ttyline.* \)-L/\1$flowctrlarg-L/" /target/etc/inittab fi if [ "$upstart_tty1" ]; then sed -e "s/^\(exec.*getty \).*/\1-L $console $ttyspeed $ttyterm/" \ -e "s/tty1/$console/g" \ "$upstart_tty1" > "$(upstart_console "$console")" sed -i -e "s/^\(exec.*\) -8/\1/" "$(upstart_console "$console")" + sed -i -e "s/^\(exec.*\)-L/\1$flowctrlarg-L/" "$(upstart_console "$console")" fi write_console "$rawconsole" /target/etc/securetty -- 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/20140513005604.GA7874@fluid.dannf
Re: netcfg_1.114_amd64.changes ACCEPTED into unstable
On Sat, Feb 08, 2014 at 07:03:25PM +0300, Cyril Brulebois wrote: > Hi dann, > > can you please push the 1.113 and 1.114 tags? Thanks! oops - done. -dann > Mraw, > KiBi. > > Debian FTP Masters (2013-12-12): > > > > > > Accepted: > > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Format: 1.8 > > Date: Thu, 12 Dec 2013 15:02:28 -0700 > > Source: netcfg > > Binary: netcfg netcfg-static > > Architecture: source amd64 > > Version: 1.114 > > Distribution: unstable > > Urgency: low > > Maintainer: Debian Install System Team > > Changed-By: dann frazier > > Description: > > netcfg - Configure the network (udeb) > > netcfg-static - Configure a static network (udeb) > > Changes: > > netcfg (1.114) unstable; urgency=low > > . > >* Make netcfg Arch: any again. This reverts a change made in version > > 0.23 over a decade ago, intended to omit s390, which apparently > > is no longer needed. > > Checksums-Sha1: > > 04ee740d9d9a0590f250f6a4255cac8eace6fcf4 1876 netcfg_1.114.dsc > > 4cac0a8105bc51f2922756fe6fb4e9aa6c5f4cb5 770397 netcfg_1.114.tar.gz > > 72a9ed1717f1b06a6d26a1c1d56b5403930b1e7f 433326 netcfg_1.114_amd64.udeb > > b5433b21e0be5af92d3da654d8e55498347c3db5 339388 > > netcfg-static_1.114_amd64.udeb > > Checksums-Sha256: > > 7b75798bdad8434b6694b5ddd246409864e47c52e6e3c3ec53043d45570feea9 1876 > > netcfg_1.114.dsc > > 8e65876f98031f2432d6127cfa6d7b4075fe99901b7a321da3ca7361ce43caca 770397 > > netcfg_1.114.tar.gz > > b8e4984f3e6f4a4afe044d4919f5d01e566445428ad062638751be5b7ba7d676 433326 > > netcfg_1.114_amd64.udeb > > b238967fabf854f23734e8022ab710bb31b38766d0346d9696fe7a22f93ec91d 339388 > > netcfg-static_1.114_amd64.udeb > > Files: > > 87b0e3a505b5cac73a9b6711f25e8c09 1876 debian-installer optional > > netcfg_1.114.dsc > > 67da485846e7e48005b218aa2ca8e0a0 770397 debian-installer optional > > netcfg_1.114.tar.gz > > 577badb83154aee0f575a015605694be 433326 debian-installer optional > > netcfg_1.114_amd64.udeb > > 2252448a52864e6f1cdd28cee5616264 339388 debian-installer optional > > netcfg-static_1.114_amd64.udeb > > > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v1.4.15 (GNU/Linux) > > > > iQIcBAEBAgAGBQJSqjMkAAoJEBv4PF5U/IZAFLIP/16FccHr1fOTue/n6I3P/das > > yj+dRfoZHCVPGAQc3r2/qApJLi2oOCqYQdYL8E++J/ct3Vz1jNRhIdG1DzX4gxc1 > > LAa/BuV3W4YUlPRJ873T8dCXBFwpmBznsUlX1hFetrZE9GoXtXDXmi+5IMYNSQmL > > Z62ASyFAh267AzAlx7VgVrVgzBkvmoPIXMcftD+NGyntxAuTwThaTqv4ebtPStaK > > j0mq85UHQeJARr+Wzj+uxh0VZV1u9+KVGSR2ybCq2h70qK14qV/39NrLJKNbvE+u > > c6c15C0XPkb5d3TI/nIYScWne0zfSqUjr+fJQ7LGj5ltxkUx1ycXTehreylgU1hi > > 2aAA0HV2QE3qr1sFkM6WQSJ3sL9ZBcbxZ4c8oEW3biEa6F8ag4Zdd5HHfBuOZjXF > > R+8f4KhFEO2V+YLbcE5OE3LECCeLCIKr/lyz/ZOrBOC9fqHC7dwzQNJuYQ6x0k6L > > jBF+lC2vOyXtuBZqEAUOdv9K6Eiv/dDlUKPttREpxDDDkBzEeLc2E9XC93nrdQGm > > cgB9kkU9STJMzCZdm2zKcISPxim7I3nKhzJ6N2nfSV1iJCUdnRSA9uBZJZOEB5KF > > /uktmUCvMxUQ4aYzubCbgu80aEbHV2GH3SH3mxmlVSegRlzvphWl6YGkFgCI8vF7 > > QuZcEeOHuMPOKve7nqAS > > =1XpT > > -END PGP SIGNATURE- > > > > > > Thank you for your contribution to Debian. > > > > > Mraw, > KiBi. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140213194027.GB11384@fluid.dannf
Re: archdetect guessing on arm* != armel
On Thu, Jan 02, 2014 at 10:52:38PM +, Ian Campbell wrote: > Hi, > > In 2010[0,1] support was added to archdetect for guessing the subarch on > armel platforms by looking at the running kernel versions suffix, this > was useful because some armel kernel flavours supported multiple boards > and it meant that support for such platforms could come essentially for > free without having to edit the installer initrd. This is implemented by > di_system_subarch_analyze_guess() in libdebianinstaller and exposed via > "archdetect -g". > > However I can't actually find anywhere which uses archdetect -g though, > even for armel, was it never implemented or was it removed? (I couldn't > find it in a grep through the "git log -p" of some plausible repos) > > Anyway, armel is what it is but this functionality has now also been > extended to armhf and more recently arm64. I'm not sure this makes sense > going forward -- the upstream kernel folks have been moving towards a > single image "multiplatform" model (i.e. one kernel binary on all new > platforms, driven by Device Tree) and in Debian we have been following > suite in the armhf flavour where we have consolidated into just two > flavours (armmp and armmp-lpae/bigmem). For ARM64 the situation is even > more clear cut, there upstream has been multiplatform from day one and > there will never be multiple platforms. > > For armhf and arm64 I think we should be moving away from a model which > requires us to whitelist supported subarchs in the installer towards one > which takes advantage of the upstream progress to work on most > platforms. I've been experimenting with having archdetect return > "armhf/generic" and handling that in kernel.sh, which seems to work > fine. I agree with that - my reasoning for making the changes I did was to be able to *blacklist* certain subarchitectures which need to behave different than the default. For instance, knowing that a certain subarch uses u-boot/flash-kernel vs. grub-efi... which will be the case for at least one platform. Though perhaps subarch detection is an incorrect mechanism for this and we should instead look for the existance of efi interfaces? -dann > On the bootloader side we discussed at the ARM sprint in Cambridge > (notes at [2]) chainloading grub-uboot on armhf. On arm64 I expect the > choice will be grub-efi. Both should reduce or eliminate the need for > subarch specific code. > > So, I think di_system_subarch_analyze_guess should be disabled for armhf > and arm64, and that map_hardware should not have any new armhf platforms > added to it (or any arm64 ones added at all). > > But, I can't quite work out how this infrastructure actually worked in > practice, because I can't see the consumers anywhere. That makes me wary > since I think I might be missing something and I don't want to pull the > rug out on something which is useful. > > The only places where I foresee there might be any need for subarch > specific stuff on armhf are: > > * grub-installer or flash-kernel: Something needs to arrange to > chainload grub. A default of writing /boot/boot.scr (using > ${kernel_addr_r}?) will help keep this to a minimum I think > * grub-installer: On armhf needs to be able to select a load > address for grub (How? TBD, but could look > into /proc/device-tree/memory* or /sys files perhaps, or even > better maybe the upstream discussion[3] will result in a runtime > relocatable grub and eliminate this too) > > In all cases this should in any case be based on /proc/device-tree/model > (which is guaranteed to be present for armhf now that we use armmp). > > With EFI on arm64 there should be no need for subarch specific code. > > WRT the existing guessing on armel, does it actually work usefully? the > list of kernel version suffixes which we match today in order to make a > subarch guess (as opposed to an exact match) from is: > dove > omap (armhf kernel flavour until Wheezy) > omap4 > mx51 > mx5 (armhf kernel flavour until Wheezy, supported by >flash-kernel, supported by base-installer >kernel.sh) > vexpress (armhf kernel flavour until Wheezy, supported by >base-installer kernel.sh) > > AFAICT none of dove, omap4 or mx51 have ever been Debian kernel flavours > or supported by flash-kernel AFAICT. Perhaps they were Ubuntu kernel > flavours? Or old armeb flavours? Only mx5 and vexpress are understood by > the base-installer's kernel selection stuff. > > Given that I'm wondering if it might be easiest to just nuke all of this > stuff across the board even for armel. > > I've pushed my WIP to the devel/armhf-armmp branches > libdebian-installer.git and base-installer.git under > https://gitorious.org/ijc-debian . > > Ian. > > [0] https://lists.debian.org/debian-boot/2010/08/msg00641.html > [1] https:/
Re: 6.0.7 planning
On Sun, Feb 17, 2013 at 11:12:18PM +, Ben Hutchings wrote: > On Sun, 2013-02-17 at 13:33 -0800, dann frazier wrote: > > On Sun, Feb 17, 2013 at 03:14:04PM +, Adam D. Barratt wrote: > > > On Fri, 2013-02-15 at 11:32 +, Adam D. Barratt wrote: > > > > On Fri, 2013-02-15 at 01:41 +, Ben Hutchings wrote: > > > > > On Thu, 2013-02-14 at 10:28 -0800, dann frazier wrote: > > > > > > Security update has been uploaded. I'll post the builds somewhere as > > > > > > they become available for anyone interested in testing. > > > > > > > > > > Version 2.6.32-48 has also been uploaded. > > > > > > > > Flagged for acceptance; thanks. > > > > > > All the builds are now in, so we should be ready for lkdi updates when > > > convenient. > > > > > > I gather there's a chance there might need to be further security > > > updates; will that mean we need another update in p-u? > > > > Possibly; an alternative would be to release a 48squeeze1 via security > > to sync up w/ the fixes just before the point release. That would let > > us go ahead and get the lkdi/d-i updates ready and give us some > > flexibility to react to any follow-on changes that may appear this > > week as CVE-2013-0871 is discussed. On the other hand, I know Ben has > > another fix queued for stable, and I saw a mention of a possible > > s390/KVM regression - so those may justify the extra p-u update. > > > > Thoughts? > > I would prefer to give users the option to install just the urgent > security fixes and delay upgrading to the point release. Releasing a > 48squeeze1 means bundling together all those changes. Agreed; and I think I was unclear. I was taking for granted that we *will* do a 46squeeze2 now w/ the CVE-2013-0871 fix and bypass 46squeeze1. 46squeeze2 would provide the security-only option. The question was whether or not we should try and fix p-u by getting a -49 into -stable now w/ the CVE-2013-0871 fix, or just make sure there's a 48squeeze1 in security for after. Ah - but maybe the point you're making is that a 48squeeze1 in security would make 46squeeze2 harder to find/install - if so, I can understand that point. > I don't think it's critical that the installer has the same kernel > version as the stable suite. We do need to be careful with ordering of > the changelog to allow the installer kernel version to be constructed > from the later version by running debian/bin/patch.apply, and/or ask the > FTP team nicely to ensure the older version remains in squeeze. Ordering it properly shouldn't be a problem. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130217233634.gh18...@dannf.org
Re: 6.0.7 planning
On Sun, Feb 17, 2013 at 03:14:04PM +, Adam D. Barratt wrote: > On Fri, 2013-02-15 at 11:32 +, Adam D. Barratt wrote: > > On Fri, 2013-02-15 at 01:41 +, Ben Hutchings wrote: > > > On Thu, 2013-02-14 at 10:28 -0800, dann frazier wrote: > > > > Security update has been uploaded. I'll post the builds somewhere as > > > > they become available for anyone interested in testing. > > > > > > Version 2.6.32-48 has also been uploaded. > > > > Flagged for acceptance; thanks. > > All the builds are now in, so we should be ready for lkdi updates when > convenient. > > I gather there's a chance there might need to be further security > updates; will that mean we need another update in p-u? Possibly; an alternative would be to release a 48squeeze1 via security to sync up w/ the fixes just before the point release. That would let us go ahead and get the lkdi/d-i updates ready and give us some flexibility to react to any follow-on changes that may appear this week as CVE-2013-0871 is discussed. On the other hand, I know Ben has another fix queued for stable, and I saw a mention of a possible s390/KVM regression - so those may justify the extra p-u update. Thoughts? -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130217213323.gg18...@dannf.org
Re: 6.0.7 planning
On Wed, Feb 13, 2013 at 03:34:51PM +, Ben Hutchings wrote: > On Wed, 2013-02-13 at 15:18 +, Adam D. Barratt wrote: > > On 12.02.2013 02:15, Ben Hutchings wrote: > > > One or other of us will then need to merge the squeeze-security > > > branch > > > into squeeze and upload -48 in time for the point release. > > > > Is there an ETA for that? Sorry for chasing, but if we're going to go > > for the 23rd (which is looking likely atm) we'd be looking at closing > > p-u-NEW over the weekend and could really do with announcing that asap. > > (So "it'll be uploaded to p-u-NEW over the weekend" should be fine, as > > we can then plan around that.) > > I can do that but it depends on the security update being finalised > first. Security update has been uploaded. I'll post the builds somewhere as they become available for anyone interested in testing. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130214182821.gb9...@dannf.org
Re: 6.0.7 planning
On Wed, Feb 13, 2013 at 03:34:51PM +, Ben Hutchings wrote: > On Wed, 2013-02-13 at 15:18 +, Adam D. Barratt wrote: > > On 12.02.2013 02:15, Ben Hutchings wrote: > > > One or other of us will then need to merge the squeeze-security > > > branch > > > into squeeze and upload -48 in time for the point release. > > > > Is there an ETA for that? Sorry for chasing, but if we're going to go > > for the 23rd (which is looking likely atm) we'd be looking at closing > > p-u-NEW over the weekend and could really do with announcing that asap. > > (So "it'll be uploaded to p-u-NEW over the weekend" should be fine, as > > we can then plan around that.) > > I can do that but it depends on the security update being finalised > first. Yeah, and that should be finalised today, so this weekend seems reasonable. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130213162149.ge18...@dannf.org
Re: 6.0.7 planning
On Mon, Feb 11, 2013 at 03:41:03AM +, Ben Hutchings wrote: > On Sun, 2013-02-10 at 16:25 +, Adam D. Barratt wrote: > > Hi, > > > > We're somewhat overdue with the next Squeeze point release (6.0.7) and > > it'd be good to get it done before the wheezy release, so that we can > > pull in some upgrade fixes. As an opening gambit, some proposed dates, > > all of which appear to currently work for me: > > > > February 23rd > > > > March 2nd > > > > March 9th > > No opinion on dates, but here's the state of the Linux kernel: > > The current version in s-p-u (2.6.32-47) adds support for new SCSI > controllers, which should be included in the installer. However there > has been disappointingly little testing feedback about this. fyi, I did hear from an HP contact that the hpsa update was working for him on new servers. > There are a couple of pending non-security fixes: > * [s390] s390/time: fix sched_clock() overflow (Closes: #698382) > * Revert "time: Avoid making adjustments if we haven't accumulated > anything" (Closes: #699112, regression in 2.6.32.60) > These ought to be included in the point release but should not be need > in the installer. > > Dann/Moritz, do you have any plans for a security or other stable > update? Should I upload to stable with just these two fixes? I've been planning a security update, but work travel has been intervening. An upload in the next couple days should be doable though. Given your statement above, do you think this should be based on -47 or -46? I'll probably drop the fix for CVE-2012-3552, at least for this upload. Your suggestion for avoiding the ABI change is good, but I'm not yet confident enough w/ the backport. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130211163610.ga13...@dannf.org
Bug#687160: patch review
hey Dmitrijs! I prepared a similar fix for this a couple of weeks ago that has been in testing at a customer site. Looks like we crossed paths, but our fixes are very similar. My patch has been working well for my test case, and I've verified yours does too. However, I've a question on your patch by way of review.. and selfishly to find out if I've an issue in my implementation. Is the vgdisplay bit known to be necessary, or is it just precautionary? I wouldn't think that vgdisplay did anything more than vgs with respect to scanning - if that is true, it should should make the vgdisplay redundant with the vgs call in this call path: device_remove_lvm() -> pv_on_device() -> pvs()) If you can dispense w/ the vgdisplay, I'd propose moving the update-dev and device_remove_lvm calls into the preceding loop instead of adding a new one, just to improve readability. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121010003745.ge1...@dannf.org
Re: Squeeze point release (6.0.6)
On Mon, Sep 24, 2012 at 10:54:00PM +0100, Adam D. Barratt wrote: > On Mon, 2012-09-24 at 09:01 +0900, dann frazier wrote: > > On Sun, Sep 23, 2012 at 05:39:21PM +0100, Adam D. Barratt wrote: > > > Thanks for the upload; the builds seem to be going well. There don't > > > seem to be any new d-i changes in git, so I assume we "just" need lkdi, > > > a round of d-i binNMUs and then a d-i-n-i upload? > > > > afaik, that's correct. > > Cool; thanks. All of the kernel builds are (finally) in now; would you > have time to take care of the lkdi uploads? Yep, should after work today. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120925002142.ga26...@dannf.org
Re: Squeeze point release (6.0.6)
On Sun, Sep 23, 2012 at 05:39:21PM +0100, Adam D. Barratt wrote: > On Tue, 2012-09-18 at 11:30 -0600, dann frazier wrote: > > On Mon, Sep 17, 2012 at 03:58:13PM +0200, Philipp Kern wrote: > > > ok, given the replies, let's settle on this: > > > > > > On Fri, Sep 07, 2012 at 09:43:03PM +0200, Philipp Kern wrote: > > > > * Sep 29/30: ok from RT side > [...] > > Sorry, been travelling heavily for the past several days. We do have > > some changes queued, and I should be able to get a kernel uploaded by > > this weekend, but probably not sooner since I expect work to keep me > > pretty busy throught the work week. > > Thanks for the upload; the builds seem to be going well. There don't > seem to be any new d-i changes in git, so I assume we "just" need lkdi, > a round of d-i binNMUs and then a d-i-n-i upload? afaik, that's correct. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120924000123.ga14...@dannf.org
Re: Squeeze point release (6.0.6)
On Mon, Sep 17, 2012 at 03:58:13PM +0200, Philipp Kern wrote: > Hi, > > ok, given the replies, let's settle on this: > > On Fri, Sep 07, 2012 at 09:43:03PM +0200, Philipp Kern wrote: > > * Sep 29/30: ok from RT side > > We still need a press officer for somewhen in the evening to send out the > announcement, feedback from -live and a note from -kernel if there's still a > change staged for the next point release. > > p-u-NEW will close on the weekend of Sep 22nd/23rd (barring any breakage > induced by the ftp-master meeting ;-). Sorry, been travelling heavily for the past several days. We do have some changes queued, and I should be able to get a kernel uploaded by this weekend, but probably not sooner since I expect work to keep me pretty busy throught the work week. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120918173003.gf4...@dannf.org
Bug#671881: Don't abort on grub-probe failures
Source: os-prober Version: 1.52 Tags: patch I've a dual boot sid/Ubuntu setup using LVM, and at some point update-grub had stopped adding a boot entry for the Ubuntu volume. I traced this down to a failing grub-probe call: dannf@fluid:~$ sudo grub-probe -d /dev/mapper/fluid-ubuntu -t fs grub-probe: error: no such disk. dannf@fluid:~$ echo $? 1 Because this is called w/ set -e, os-prober aborts here leaving a stale fuse mount on /var/lib/os-prober/mount, and doesn't execute the subsequent calls that otherwise would've added the appropriate boot entries. I don't know if this is a regression w/ grub-probe or not, but seems like a good change either way. Please review :) commit 12acca65e63727fd678494fd1685e77045112b5b Author: dann frazier Date: Mon May 7 12:30:10 2012 -0700 Don't abort due to set -e on grub-probe errors diff --git a/debian/changelog b/debian/changelog index 03f2b49..0f75367 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +os-prober (1.53) UNRELEASED; urgency=low + + * Don't abort due to set -e on grub-probe errors + + -- dann frazier Mon, 07 May 2012 12:26:55 -0700 + os-prober (1.52) unstable; urgency=low [ Stéphane Graber ] diff --git a/linux-boot-probes/common/50mounted-tests b/linux-boot-probes/common/50mounted-tests index 41e26e6..6b99cf7 100755 --- a/linux-boot-probes/common/50mounted-tests +++ b/linux-boot-probes/common/50mounted-tests @@ -38,8 +38,7 @@ if type grub-mount >/dev/null 2>&1 && \ type grub-probe >/dev/null 2>&1 && \ grub-mount "$partition" "$tmpmnt" 2>/dev/null; then mounted=1 - type="$(grub-probe -d "$partition" -t fs)" - [ "$type" ] || type=fuseblk + type="$(grub-probe -d "$partition" -t fs)" && [ "$type" ] || type=fuseblk else ro_partition "$partition" for type in $types; do diff --git a/os-probes/common/50mounted-tests b/os-probes/common/50mounted-tests index 45b4b53..1498963 100755 --- a/os-probes/common/50mounted-tests +++ b/os-probes/common/50mounted-tests @@ -50,8 +50,7 @@ if type grub-mount >/dev/null 2>&1 && \ type grub-probe >/dev/null 2>&1 && \ grub-mount "$partition" "$tmpmnt" 2>/dev/null; then mounted=1 - type="$(grub-probe -d "$partition" -t fs)" - if [ "$type" ]; then + if type="$(grub-probe -d "$partition" -t fs)" && [ "$type" ]; then debug "mounted using GRUB $type filesystem driver" else debug "mounted using GRUB, but unknown filesystem?" -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120507200149.gb5...@dannf.org
Bug#610377: [PATCH] Allow mounting a logical volume as /boot
tags 610377 + patch thanks The current code allows you to boot from a logical volume, but only if /boot is on the / filesystem. This change permits having /boot on its own logical volume. Signed-off-by: dann frazier --- lib/auto-lvm.sh |8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/lib/auto-lvm.sh b/lib/auto-lvm.sh index 80856ba..7e357df 100644 --- a/lib/auto-lvm.sh +++ b/lib/auto-lvm.sh @@ -166,9 +166,13 @@ auto_lvm_prepare() { bail_out unusable_recipe fi - # Make sure a boot partition isn't marked as lvmok + # Make sure a boot partition isn't marked as lvmok, unless the user + # has told us it is ok for /boot to reside on a logical volume if echo "$scheme" | grep lvmok | grep -q "[[:space:]]/boot[[:space:]]"; then - bail_out unusable_recipe + db_input critical partman-auto-lvm/no_boot || true + db_go || return 255 + db_get partman-auto-lvm/no_boot || true + [ "$RET" = true ] || bail_out unusable_recipe fi # This variable will be used to store the partitions that will be LVM -- 1.7.9.1 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120329021904.ga24...@dannf.org
Re: Planning for final lenny point release (5.0.10)
On Sat, Mar 03, 2012 at 12:29:58PM +, Adam D. Barratt wrote: > On 29.02.2012 17:20, dann frazier wrote: > >On Wed, Feb 29, 2012 at 01:20:32PM +, Adam D. Barratt wrote: > >>Feel free to go ahead with the kernel upload, so we can get it > >>chucked at the buildds. > [...] > >Ack. > > Unfortunately, the powerpc build died: > > CC [M] arch/powerpc/oprofile/op_model_power4.o > arch/powerpc/oprofile/op_model_power4.c: In function 'pmc_overflow': > arch/powerpc/oprofile/op_model_power4.c:273: error: 'PV_POWER7' > undeclared (first use in this function) > arch/powerpc/oprofile/op_model_power4.c:273: error: (Each undeclared > identifier is reported only once > arch/powerpc/oprofile/op_model_power4.c:273: error: for each > function it appears in.) > make[4]: *** [arch/powerpc/oprofile/op_model_power4.o] Error 1 > > This appears to be a consequence of the patch for CVE-2011- 4347 > (http://anonscm.debian.org/viewvc/kernel/dists/lenny-security/linux-2.6/debian/patches/bugfix/powerpc/oprofile-handle-events-that-raise-an-exception-without-overflowing.patch?view=markup&pathrev=18552>). I reuploaded w/o that patch - that fix was POWER7 specific, and it looks like POWER7 support wasn't supported in the lenny timeframe anyway. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120305013106.ga8...@dannf.org
Re: Planning for final lenny point release (5.0.10)
On Wed, Feb 29, 2012 at 01:20:32PM +, Adam D. Barratt wrote: > On 27.02.2012 01:12, dann frazier wrote: > >Ok - sounds like no DSA, but maybe an upload via o-p-u. My vote is to > >do no kernel upload if the release gets scheduled for the first > >weekend in march - that's one week out, and I'll have spotty > >availability beginning mid-week. For later weekends, I'm for it. > > As you most likely saw already, we've scheduled the point release > for the 10th; i.e. a week and a bit from now. > > Feel free to go ahead with the kernel upload, so we can get it > chucked at the buildds. If we could look at getting lkdi and d-i > sorted fairly quickly after the kernel builds are in, that would be > great, so we don't end up with any last minute surprises; let us > know if there's anything you'd like us to assist with there. I was > hoping we could get away with binNMUing d-i, but we'd need a manual > upload for hppa anyway, so we might as well start with a source+hppa > upload I suppose... Ack. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120229172036.gb19...@dannf.org
Re: Planning for final lenny point release (5.0.10)
On Sat, Feb 25, 2012 at 10:12:11PM +0100, Philipp Kern wrote: > Hi, > > On Fri, Feb 24, 2012 at 08:44:46PM +, Adam D. Barratt wrote: > > Assuming the technical side still works, I do worry a little that a new > > DSA three weeks after the announced EOL for security support might > > confuse people. > > > > I suppose we could do a last-minute kernel update via o-p-u, although I > > don't know if we have any idea how many people actually upgrade to EOL > > point releases in the relatively short period before the move to > > archive.d.o. > > yeah, I wondered the same. I don't actually know when ftp-master gets > rid of oldstable on the mirrors. If we'd know that it's still around > for a few months I'd say o-p-u. The old suites used to stay on > security-master for ages, but AFAICS that's no longer the case > neither. > > Maybe the final announcement should point people at archive already > (it could already get synced there at that point, given that it won't > change anymore). Ok - sounds like no DSA, but maybe an upload via o-p-u. My vote is to do no kernel upload if the release gets scheduled for the first weekend in march - that's one week out, and I'll have spotty availability beginning mid-week. For later weekends, I'm for it. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120227011257.ga17...@dannf.org
Bug#630424: Maybe a Problem with "tip22"
On Sun, Jun 19, 2011 at 01:35:28PM +0200, Guido Günther wrote: > On Sun, Jun 19, 2011 at 02:39:05AM -0700, Edwin Kwan wrote: > > Hi Guido, > > > > Your package tested out OK. I only have an Indy. So I only tried > > "tip22". > Thanks for testing! I've uploaded a new version to unstable. > > I'm not sure what's the correct procedure to get the installer images > rebuilt with that for the next point release though. Can somebody from > debian-boot shed some light on this? I assume it includes uploading a > new arcboot version to stable-proposed-updates but is that enough? > Cheers, > -- Guido I believe what needs to be done is: 1) Propose an arcboot update for squeeze. You can coordinate this with the stable release team on debian-release@l.d.o. Please include a debdiff vs. current squeeze. 2) Once that's accepted, we need to ask the mips buildd maintainer to ensure this update gets included in the squeeze chroot(s). 3) Finally, we need to do a d-i rebuild (which we usually do with each point release anyway). You can coordinate with me on that. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110705232904.ga31...@dannf.org
Re: Debian installer build: failed or old builds
On Fri, May 20, 2011 at 06:59:35AM +0200, Christian PERRIER wrote: > Quoting Daily build aggregator (debian-boot@lists.debian.org): > > Debian installer build overview > > --- > > > > Failed or old builds: > > > > * FAILED BUILD: hppa May 19 06:00 didaily@c3700 build_cdrom > > > > http://d-i.debian.org/daily-images/hppa/daily/build_cdrom.log > > > > * FAILED BUILD: hppa May 19 06:01 didaily@c3700 build_netboot > > > > http://d-i.debian.org/daily-images/hppa/daily/build_netboot.log > > > > * FAILED BUILD: hppa May 19 06:01 didaily@c3700 build_miniiso > > > > http://d-i.debian.org/daily-images/hppa/daily/build_miniiso.log > > > HPPA porters, could you have a look at this? > > By the way, is there still a reason to keep an hppa autobuilder now > that hppa has been moved to debian-ports? For d-i, probably not - I've powered-down said box. Thanks for the notification. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110524140855.ga14...@dannf.org
Bug#622187: [ia64] CDROM drive not detected
On Mon, Apr 11, 2011 at 12:20:35AM +0100, Miguel Figueiredo wrote: > On Sunday 10 April 2011 19:54:28 dann frazier wrote: > > [...] > > > The ia64 cdrom flavor is missing the pata_cmd64x driver, which is needed to > > access the optical drive on various models of HP Itanium systems. > > [...] > > As the d-i's kernel depends on the kernel-wedge package it is needed > to include pata-modules in linux-kernel-di-ia64-2.6/modules/ia64/ so > it is included when the kernel-di-ia64-2.6 is rebuilt. > > IIUC the above makes kernel-wedge/modules/pata-modules be included > also for ia64. Yep, my installation report included patches for that. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110411102329.ga28...@dannf.org
Bug#599417: also affects ia64
Note that ia64 also suffers from this artificial restriction because the elilo.efi bootloader does not read files from the /boot directory. Rather, these files are read from a separate disk partition - the EFI partition - that is not mounted by the OS by default. The EFI partition is updated by a kernel hook when boot files are changed. In many ways this is similar to the flash-kernel case with the NVRAM replaced by a disk partition. It (perhaps naively) seems to me like the logical place to store this data would be to have the individual bootloader installer packages specify the list of filesystems from which they can boot, and have partman disallow /boot to reside on a filesystem for which no supportable bootloader is available. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110410202950.ga14...@dannf.org
Bug#622187: [ia64] CDROM drive not detected
ffcc0-3fd7f : PCI Bus :40 I/O Ports 3000-5fff /proc/iomem: 3fd80-3fdff : PCI Bus :60 I/O Ports 6000-7fff /proc/iomem: 3fe00-3feff : PCI Bus :80 I/O Ports 8000-bfff /proc/iomem: 3ff00-3ff7f : PCI Bus :c0 I/O Ports c000-dfff /proc/interrupts:CPU0 CPU1 /proc/interrupts: 28: 2 0 LSAPIC cpe_poll /proc/interrupts: 29: 0 0 LSAPIC cmc_poll /proc/interrupts: 31: 0 0 LSAPIC cmc_hndlr /proc/interrupts: 48: 0 0 IO-SAPIC-level acpi /proc/interrupts: 49: 6121 0 IO-SAPIC-edge serial /proc/interrupts: 51: 160343 0 IO-SAPIC-level eth0 /proc/interrupts: 53: 6 0 IO-SAPIC-level ehci_hcd:usb1 /proc/interrupts: 54: 0 0 IO-SAPIC-level ohci_hcd:usb2 /proc/interrupts: 55: 2635 0 IO-SAPIC-level ohci_hcd:usb3 /proc/interrupts: 56: 48178 0 IO-SAPIC-level ioc0 /proc/interrupts: 57:319 0 IO-SAPIC-level ioc1 /proc/interrupts: 232: 0 0 LSAPIC mca_rdzv /proc/interrupts: 238: 0 0 LSAPIC perfmon /proc/interrupts: 239: 157277 156996 LSAPIC timer /proc/interrupts: 240: 0 0 LSAPIC mca_wkup /proc/interrupts: 252: 0 0 LSAPIC tlb_flush /proc/interrupts: 253: 22100 23700 LSAPIC resched /proc/interrupts: 254: 43 30770 LSAPIC IPI /proc/interrupts: ERR: 0 /proc/meminfo: MemTotal: 12497840 kB /proc/meminfo: MemFree:11521520 kB /proc/meminfo: Buffers: 134304 kB /proc/meminfo: Cached: 645744 kB /proc/meminfo: SwapCached:0 kB /proc/meminfo: Active: 417040 kB /proc/meminfo: Inactive: 381792 kB /proc/meminfo: Active(anon): 19008 kB /proc/meminfo: Inactive(anon): 64 kB /proc/meminfo: Active(file): 398032 kB /proc/meminfo: Inactive(file): 381728 kB /proc/meminfo: Unevictable: 0 kB /proc/meminfo: Mlocked: 0 kB /proc/meminfo: SwapTotal: 296 kB /proc/meminfo: SwapFree:296 kB /proc/meminfo: Dirty: 592 kB /proc/meminfo: Writeback: 0 kB /proc/meminfo: AnonPages: 18880 kB /proc/meminfo: Mapped: 4064 kB /proc/meminfo: Shmem: 208 kB /proc/meminfo: Slab: 48464 kB /proc/meminfo: SReclaimable: 41904 kB /proc/meminfo: SUnreclaim: 6560 kB /proc/meminfo: KernelStack:2336 kB /proc/meminfo: PageTables: 2064 kB /proc/meminfo: Quicklists:67056 kB /proc/meminfo: NFS_Unstable: 0 kB /proc/meminfo: Bounce:0 kB /proc/meminfo: WritebackTmp: 0 kB /proc/meminfo: CommitLimit: 8249008 kB /proc/meminfo: Committed_AS: 32256 kB /proc/meminfo: VmallocTotal: 137429633024 kB /proc/meminfo: VmallocUsed: 52176 kB /proc/meminfo: VmallocChunk: 137429565696 kB /proc/meminfo: HugePages_Total: 0 /proc/meminfo: HugePages_Free:0 /proc/meminfo: HugePages_Rsvd:0 /proc/meminfo: HugePages_Surp:0 /proc/meminfo: Hugepagesize: 262144 kB /proc/bus/input/devices: I: Bus=0019 Vendor= Product=0001 Version= /proc/bus/input/devices: N: Name="Power Button" /proc/bus/input/devices: P: Phys=LNXPWRBN/button/input0 /proc/bus/input/devices: S: Sysfs=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input0 /proc/bus/input/devices: U: Uniq= /proc/bus/input/devices: H: Handlers=kbd /proc/bus/input/devices: B: EV=3 /proc/bus/input/devices: B: KEY=10 0 /proc/bus/input/devices: /proc/bus/input/devices: I: Bus=0019 Vendor= Product=0003 Version= /proc/bus/input/devices: N: Name="Sleep Button" /proc/bus/input/devices: P: Phys=LNXSLPBN/button/input0 /proc/bus/input/devices: S: Sysfs=/devices/LNXSYSTM:00/LNXSLPBN:00/input/input1 /proc/bus/input/devices: U: Uniq= /proc/bus/input/devices: H: Handlers=kbd /proc/bus/input/devices: B: EV=3 /proc/bus/input/devices: B: KEY=4000 0 0 /proc/bus/input/devices: -- System Information: Debian Release: 6.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: ia64 Kernel: Linux 2.6.32-5-itanium (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash commit 0c87c0d120f32c863e8ee63cf37c61241f759a13 Author: dann frazier Date: Sun Apr 10 12:42:53 2011 -0600 Add pata-modules to cdrom config for ia64. diff --git a/build/pkg-lists/cdrom/ia64.cfg b/build/pkg-lists/cdrom/ia64.cfg index 084a0a7..672ba26 100644 --- a/build/pkg-lists/cdrom/ia64.cfg +++ b/build/pkg-lists/cdrom/ia64.cfg @@ -13,5 +13,6 @@ usb-storage-modules-${kernel:Version} cdrom-core-modules-${kernel:Version} input-modules-${kernel:Version} s
Re: Debian installer build: failed or old builds
On Sun, Mar 06, 2011 at 05:32:49PM +0100, Christian PERRIER wrote: > Quoting dann frazier (da...@dannf.org): > > > > And how about hppa builds? > > > > > > IIRC, hppa is now only supported in unstable, so that may explain why > > > D-I daily builds are no longer run. Am I right? > > > > oops - powered down my hppa box before i went out of town. It should > > be back up & daily buildin' again. Thanks for the poke. > > As of today, we still have reports of old builds for hppa... > > * OLD BUILD:hppa Jan 17 07:06 didaily@c3700 build_cdrom > > > http://d-i.debian.org/daily-images/hppa/daily/build_cdrom.log > > > > > > * OLD BUILD:hppa Jan 17 07:10 didaily@c3700 build_netboot > > > > http://d-i.debian.org/daily-images/hppa/daily/build_netboot.log > > > > > > * OLD BUILD:hppa Jan 17 07:14 didaily@c3700 build_miniiso > > > > http://d-i.debian.org/daily-images/hppa/daily/build_miniiso.log > > > oops, how about now? -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110307154912.gb25...@dannf.org
Re: Debian installer build: failed or old builds
On Fri, Mar 04, 2011 at 08:51:08AM +0100, Christian PERRIER wrote: > Quoting Daily build aggregator (debian-boot@lists.debian.org): > > Debian installer build overview > > --- > > > > Failed or old builds: > > > > * FAILED BUILD: armel Mar 03 23:16 joey@box build_orion5x_network-console > > > > http://people.debian.org/~joeyh/d-i/armel/images/daily/build_orion5x_network-console.log > > > > * OLD BUILD:hppa Jan 17 07:06 didaily@c3700 build_cdrom > > > > http://d-i.debian.org/daily-images/hppa/daily/build_cdrom.log > > > > * OLD BUILD:hppa Jan 17 07:10 didaily@c3700 build_netboot > > > > http://d-i.debian.org/daily-images/hppa/daily/build_netboot.log > > > > * OLD BUILD:hppa Jan 17 07:14 didaily@c3700 build_miniiso > > > > http://d-i.debian.org/daily-images/hppa/daily/build_miniiso.log > > > And how about hppa builds? > > IIRC, hppa is now only supported in unstable, so that may explain why > D-I daily builds are no longer run. Am I right? oops - powered down my hppa box before i went out of town. It should be back up & daily buildin' again. Thanks for the poke. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110304221722.ga1...@dannf.org
Re: debian-installer daily builds on hppa buildd
On Fri, Dec 17, 2010 at 04:12:26PM -0700, dann frazier wrote: > On Mon, Dec 06, 2010 at 06:14:16PM +0100, Gaudenz Steinlin wrote: > > [ Sorry to those that receive this mail twice. I messed up the > > recipient list the first time. ] > > > > Hi Dann > > > > Excerpts from Andreas Barth's message of Mit Nov 10 22:51:05 +0100 2010: > > > * dann frazier (da...@debian.org) [101110 22:46]: > > > > I'd be glad to set this up on one of the hppa buildds (peri or > > > > penalosa) if DSA (CC'd) is ok with it. However, the above e-mail > > > > suggests we need to have working LVM snapshots. iirc, we've had > > > > problems with those on hppa in the past. Is that a hard requirement? > > > > > > LVM is just "the way it is done now" (basically we clone snapshots, > > > install stuff there, and then toss the chroot at the end). It could be > > > done different of course. > > > > Is there any progress on this. There are still no d-i builds for hppa. > > > > Or is this not going to happen and the daily builds for hppa should be > > removed from d-i.debian.org? > > In progress. I have builds going on a system at home & am working on > getting the ssh key setup now. ... and done. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101220221116.gf31...@dannf.org
Re: debian-installer daily builds on hppa buildd
On Mon, Dec 06, 2010 at 06:14:16PM +0100, Gaudenz Steinlin wrote: > [ Sorry to those that receive this mail twice. I messed up the > recipient list the first time. ] > > Hi Dann > > Excerpts from Andreas Barth's message of Mit Nov 10 22:51:05 +0100 2010: > > * dann frazier (da...@debian.org) [101110 22:46]: > > > I'd be glad to set this up on one of the hppa buildds (peri or > > > penalosa) if DSA (CC'd) is ok with it. However, the above e-mail > > > suggests we need to have working LVM snapshots. iirc, we've had > > > problems with those on hppa in the past. Is that a hard requirement? > > > > LVM is just "the way it is done now" (basically we clone snapshots, > > install stuff there, and then toss the chroot at the end). It could be > > done different of course. > > Is there any progress on this. There are still no d-i builds for hppa. > > Or is this not going to happen and the daily builds for hppa should be > removed from d-i.debian.org? In progress. I have builds going on a system at home & am working on getting the ssh key setup now. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101217231226.gf26...@dannf.org
scheduling 2.6.26-26
In order to get the kernel/d-i stack squared away for 5.0.7, I'd like to go ahead and upload 2.6.26-26 tomorrow. I had planned to push the changes in the lenny branch via security (w/ several other queued security fixes), but I'll need a little more time to get the security upload ready. Let me know if you have any stable changes in preparation that I should wait for. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101119235134.ge30...@dannf.org
Re: debian-installer daily builds on hppa buildd
On Tue, Nov 09, 2010 at 10:26:45PM +0100, Gaudenz Steinlin wrote: > Hi > > Since June there are no more daily builds for hppa. As I just found > out the buildd building these images (lafayette) is dead. Are there any > plans to setup the daily builds on another buildd? > > See http://lists.debian.org/debian-boot/2010/03/msg00599.html for how > to setup the daily builds. I'd be glad to set this up on one of the hppa buildds (peri or penalosa) if DSA (CC'd) is ok with it. However, the above e-mail suggests we need to have working LVM snapshots. iirc, we've had problems with those on hppa in the past. Is that a hard requirement? -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101110154058.gc22...@dannf.org
J5600 for developers/testers
hey, If you live in europe and are interested in a J5600 for parisc-linux development or testing, please contact me off-list with a blurb about what you would plan to do with it. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101101151257.ga3...@dannf.org
stable d-i update for 5.0.5
hey, I'd like to update d-i for 5.0.5 as it includes a new nic driver (be2net), and fixes several boot issues. I plan to prepare an upload of linux-kernel-di-* and d-i once the latest kernel upload has been built everywhere. Are there any additional changes that should go in? -- dann frazier -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100614162238.ga20...@lackof.org
Re: lkdi / etch
On Thu, Feb 25, 2010 at 03:50:18AM +0100, Frans Pop wrote: > On Thursday 25 February 2010, dann frazier wrote: > > fyi, I'm planning to upload a new set of linux-kernel-di packages for > > the upcoming etch point release, mainly to fix a regression on s390 > > (#562525). > > Ack. Let me/us know when there are images that could use testing. All updated d-i builds have now been uploaded by the respective buildds. -- dann frazier -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100303031003.ga10...@lackof.org
lkdi / etch
fyi, I'm planning to upload a new set of linux-kernel-di packages for the upcoming etch point release, mainly to fix a regression on s390 (#562525). -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100224235645.gb22...@lackof.org
Re: [(O)SRM] debian-installer update uploaded for Etch and Lenny
On Wed, Jan 13, 2010 at 10:10:28AM +0100, Frans Pop wrote: > On Monday 11 January 2010, Frans Pop wrote: > > On Thursday 24 December 2009, Frans Pop wrote: > > > For stable (20090123lenny5) all arches except mips were successful. > > > I've already mailed the mips buildd maintainers. > > > > I've not heard anything back from the mips buildd maintainers, despite > > sending several mails. Please retry on a different buildd than ball. > > It's now built correctly. Problem (error in regexps) has been identified > and fixed for future uploads. I'm currently uploading refreshed linux-kernel-di packages built against 2.6.26-21. Once accepted, I can go ahead and refresh d-i. Please let me know if there's any other pending d-i changes for stable that I should wait for. -- dann frazier -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [(O)SRM] debian-installer update uploaded for Etch and Lenny
On Mon, Jan 11, 2010 at 06:57:56PM +0100, Frans Pop wrote: > On Thursday 24 December 2009, Frans Pop wrote: > > As all packages needed to build D-I were now available, I have uploaded > > for both stable and oldstable. An accept is not needed; apparently D-I > > gets an automatic accept due to by-hand processing of the image > > tarballs. > > > > For stable (20090123lenny5) all arches except mips were successful. I've > > already mailed the mips buildd maintainers. > > I've not heard anything back from the mips buildd maintainers, despite > sending several mails. Please retry on a different buildd than ball. mayr had the same failure. The buildd admin is looking at it, but we're not sure what the problem is. Do you have a guess as to what is causing it? -- dann frazier -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [(O)SRM] debian-installer update uploaded for Etch and Lenny
On Thu, Dec 24, 2009 at 03:52:26PM +0100, Frans Pop wrote: > As all packages needed to build D-I were now available, I have uploaded for > both stable and oldstable. An accept is not needed; apparently D-I gets an > automatic accept due to by-hand processing of the image tarballs. > > For oldstable (20070308etch6) all arches have been built successfully. > > For stable (20090123lenny5) all arches except mips were successful. I've > already mailed the mips buildd maintainers. > > I will run some installation tests over the next few days. If I don't > follow up on this mail it means the tests were successful. > > Are there already plans to do the point releases? It would be great if it > could be fairly soon. > > Changes for stable (Lenny): > - improved mirror selection: better support for installation of oldstable > and from archive.debian.org > - updated mirror lists > - update of system date from NTP now also works correctly if the system > date after boot is before 1-1-1970 > - [arm/armel] QNAP NAS devices: leds and buzzer work again during installs > (qcontrol needed update after previous stable update of udev) > - [s390] booting (IPL) from CD fixed [1] > > There's no kernel update for the installer for Lenny. It's probably not > needed either, but maybe Dann will want to do an extra D-I upload to > include updated kernel udebs after the next kernel upload for p-u. yeah, we've added some new hardware support (intel nics), so I can take care of another d-i update once the kernel in p-u-new has been accepted/built everywhere. The acceptance of this package is currently on hold due to the debian-installer/mips build failure. Is the cause of that known? -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [OSRM] D-I kernel updates
On Thu, Dec 17, 2009 at 08:31:02PM +0100, Frans Pop wrote: > Please accept the new kernel udebs (linux-kernel-di-*-2.6) I've just > uploaded for Etch. done (pending next queue run) > After that I guess another run to process p-u-new by FTP masters will be > needed to get them in the archive. > > After that I will upload debian-installer for both stable and oldstable. > > Cheers, > FJP -- dann frazier -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [(old)stable] D-I kernel updates
On Thu, Dec 17, 2009 at 05:32:03PM +0100, Frans Pop wrote: > Hi Dann, > > I'm preparing to upload a new version of D-I for both stable and oldstable > and was wondering whether or not to update the kernel udebs. > > Are the current kernel images in (o-)p-u the versions intended for the next > point releases? Anything in them worth the effort? > > p-u has 2.6.26-20; o-p-u has 2.6.18.dfsg.1-26etch1. > > For both all arches look to be up-to-date, so building and uploading the > kernel udebs will be trivial. I can take care of that. hey Frans! p-u still needs an update, so I wouldn't bother there. The bits in o-p-u are candidates for the next oldstable release, though I believe they add no additional hardware support. Feel free to resync them though. -- dann frazier -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Problems with kernel 2.6.26-2-686-bigmem
On Fri, Aug 28, 2009 at 12:08:35PM -0600, David Vanfleet wrote: > > > Luk Claes wrote: > > David Vanfleet wrote: > > > Hi, I'm trying to get Debian (Lenny) to recognize 6 Gig of memory on a > Dell PE 2650 server. I installed the basic 5.02a Debian system with > just > a minimal install then I installed the 2.6.26-2-686-bigmem kernel so > it > will see all the memory. When I boot into the bigmem kernel it fails > to > boot, the errors I get are: > >WARNING boot device may be renamed. Try root=/dev/hda3 >... >ALERT! /dev/sda3 does not exist > > > Did you try with changing the root device for the bigmem kernel to > /dev/hda3? > > If you use grub for booting you could do that by pressing 'e' (for edit > on the line with the bigmem kernel) and afterwards pressing 'b' (for > boot) while in the grub menu (to just try it) or updating > /boot/grub/menu.lst (for the bigmem kernel) and running update-grub > before rebooting into the bigmem kernel. > > > > Thanks for your response, I did try what you suggested but got the same error, > except it says that "/dev/hda3 does not exist". Looking in /dev there is no > sda* or hda*, there only an hda which I think is the CD drive. When I boot to > the default Kernel then /dev/sda3 exists and is used to boot the kernel. Any > other ideas? Does this system use the aacraid driver? If so, please try testing the kernel from lenny-proposed-updates (2.6.26-19). -- dann frazier -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#446416: Bug does no longer exist, imho
On Sun, Aug 09, 2009 at 12:02:26PM +0200, Christian Perrier wrote: > tags 446416 unreproducible > thanks > > Hi Dann, > > Apparently, this old bug you reported back in 2007 hasa been ignored > and no further investigation happened. > > I just tried to reprocude it, exactly the way you mentioned: > > r...@mykerinos:/etc/whereami# cat >/usr/share/tasksel/dannf.desc > Task: dannf > Section: user > Description: dannf > long description > Relevance: 10 > Key: > Packages: list > hello > > Note the same trailing whitespace in synopsis. > > > Then I launched "taslsel --test" and did choose the "dannf" task. > > r...@mykerinos:/etc/whereami# tasksel --test > debconf-apt-progress -- aptitude -q -y install hello > > So, it seems that things are OK as of now... Thanks Christian. Looks like this is resolved, feel free to close. -- dann frazier -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [stable] Adding bnx2x driver in 5.0.3
On Sat, Aug 08, 2009 at 03:18:53PM +0200, Luk Claes wrote: > Otavio Salvador wrote: > > Hello dann, > > > > On Sun, Jul 26, 2009 at 4:04 PM, dann frazier wrote: > >> The bnx2x driver was disabled in lenny due to its use of non-free > >> firmware. I have put together a patch that would reenable this driver > >> in lenny's 2.6.26 kernel, making use of the firmware split-out patch > >> that has gone upstream in Linux 2.6.31-rc releases (and is currently > >> in use in the linux-2.6 2.6.30 packages in sid). > > > > Really good news :-) > > > >> I'd like to see if we can enable the use of this driver in 5.0.3. > >> As far as I can tell, the necessary steps would be: > >> > >> - Update the kernel (obviously) - planned for a p-u upload this week > >> - Backport the necessary changes for firmware-nonfree from sid to add > >> the firmware-bnx2x package > > AFAICS both above are done? yep. > >> - Update kernel-wedge/stable to include bnx2x if available (are there > >> space issues here?) > > > > The space usage is neglitable and I think it can be done with a very > > small risk of regressions. > > > > Be sure to use the kernel-wedge of lenny for building it since we've > > changed kernel-wedge a lot during the 2.6.30 migration and it is not > > suitable for the lenny usage. > > What's the status here? I can get this done tomorrow. > >> - Update d-i in 5.0.3 to incorporate this driver > > > > Yes, you got the picture right. > > > > I offer help if required. > > This can probably be done already when kernel-wedge is updated? Please > don't delay when unnecessary, TIA. Do we have an estimate for 5.0.3 yet? Reason I ask is that there is typically always some kernel changes queued - security or otherwise. I do understand wanting to have p-u in an always-releasable state, but it can be a lot of throwaway work given that a security update would force us to do a complete rebuild. If we have a target date in mind I could work up a schedule (w/ buffer room) to make sure that all the pieces are in place ahead of time. Thanks Luk. -- dann frazier -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
[stable] Adding bnx2x driver in 5.0.3
The bnx2x driver was disabled in lenny due to its use of non-free firmware. I have put together a patch that would reenable this driver in lenny's 2.6.26 kernel, making use of the firmware split-out patch that has gone upstream in Linux 2.6.31-rc releases (and is currently in use in the linux-2.6 2.6.30 packages in sid). I'd like to see if we can enable the use of this driver in 5.0.3. As far as I can tell, the necessary steps would be: - Update the kernel (obviously) - planned for a p-u upload this week - Backport the necessary changes for firmware-nonfree from sid to add the firmware-bnx2x package - Update kernel-wedge/stable to include bnx2x if available (are there space issues here?) - Update d-i in 5.0.3 to incorporate this driver -- dann frazier -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Next point release and the Installer
Here's some draft text: The debian installer has been rebuilt to use the updated kernel packages in 5.0.2. This resolves issues with: - installation on s390 G5 systems - installation on IBM summit-based i386 systems The installer also includes an updated cdebconf package with resolves several issues with installation menu rendering with the newt frontend, including: - explanatory text overlapping with the input box due to a height miscalculation - overlapping of the "Go Back" button and the select list on certain screens - suboptimal screen usage, particularly affecting debian-edu installations -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Upcoming Lenny Point Release
On Sat, Jun 20, 2009 at 11:19:59AM +0200, Luk Claes wrote: > dann frazier wrote: > > On Fri, Jun 05, 2009 at 08:25:00PM +0200, Philipp Kern wrote: > >> Hi there, > >> > >> we intend to do a Lenny Point Release on Saturday, June 20th. We will > >> clear stable NEW in the coming days and then declare the point release > >> frozen. Please hurry up if you still need something to go into Lenny > >> at that point. > > > > A regression was reported yesterday in the linux-2.6 package in > > proposed-updates. The bug is #533657. > > > > Let me know if you think this is worth a delay of the point release. > > We have a stable upload planned for immediately after 5.0.2, so if the > > release continues on schedule, we will be able to direct affected > > users to the p-u apt source for a fix. > > Yes, it's worth delaying the stable point release. > > Unfortunately I won't be available the next couple of days and Phil was > rather busy up to now (and I expect that to continue for some time > still), so the point release will be delayed for at least a week. > Hopefully we will be able to do the point release next Saturday, I hope > Phil or some of our Release Assistants can confirm that soon. I will proceed with the lowest risk option - reverting the change that caused #533657 - and upload asap. -- dann frazier -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Upcoming Lenny Point Release
On Sun, Jun 07, 2009 at 03:35:16PM -0300, Otavio Salvador wrote: > Hello, > > On Sat, Jun 6, 2009 at 6:01 AM, Holger Levsen wrote: > > Hi, > > > > for Debian Edu it would be great if cdebconf would be updated to 0.141 in > > stable and new d-i initrds would be build, as we are using them directly and > > are being bitten by #508042, #507372 and #343119. Those bugs were fixed in > > 0.140, but due to #525209 0.141 is desirable. > > > > I'm not sure if it's realistic at all (though the changes are just bugfixes > > and translation updates), but it would be good to have an answer, so either > > Debian Edu can use unmodified d-i or we have to fix it ourselves, which > > would > > mean branching d-i and a whole lot of more work (for the years to come). > > I have no problem in prepare that fix for it however it needs a full > d-i update to happen. If RM team is OK with it I can take a look at it > and prepare the packages during this week. If d-i does respin, it would be cool if we could include an updated lkdi-s390, which would make the fix for #511334 available at install time. -- dann frazier -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Raising minimum CPU requirement for i386 kernel
On Sun, May 24, 2009 at 09:07:49PM +0200, Bastian Blank wrote: > Hi folks > > I would like to raise the minimum CPU requirement for the shipped Linux > kernels in the i386 port to i686 (with cmov). For now I will not propose > a change of the default machine type setting used by the compiler. > > This means that Debian will get uninstallable on the following CPUs: > - Intel i486, > - Intel Pentium (MMX), > - AMD K5, > - AMD K6(-2, -3), > - Cyrix 6x86, > - VIA C3 before Nehemiah and > - National Semiconductor Geode (GXm, GXLV, GX1 and GX2). > > Except for the C3 and the Geodes, all of them were released in the last > Millenium and the successors will be available for at least 10 years at > the release of Squeeze. I actively use a VIA C3 (no-cmov) for a number of services, so would prefer not to lose that support. -- dann frazier -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
5.0.1 kernel upload, ABI change
On Mon, Feb 23, 2009 at 04:47:35PM -0700, dann frazier wrote: > hey, > The first lenny update is scheduled for early April, so I wanted to > start coordinating the kernel update. > > Security > > The lenny-security branch is currently caught up on security issues, > so I'd like to release a DSA later this week. I'd appreciate it if the > individual arch maintainers could test builds from this branch ahead > of time. The CVE-2009-0029 touch a lot of arch-specific code and > though they applied pretty easily to the lenny kernel, it'd still be > good to get some testing there. I noticed that the snapshot archive > now has a lenny-security dist for some archs (thanks waldi) This is now released, finally, as DSA-1749. The only regression I'm aware of is that user-mode-linux now FTBFS. A fix for that is queued for -14. > Stable > -- > There are several fixes queued up for a stable upload. I have a > few more small fixes from jmm to review/commit as well, and it looks > like tbm has an RTC regression fix pending. I've seen mentions of > OpenVZ fixes from Ola/maks - what is the status of those? Are there > any other changes people are working on? Obviously we've made a lot of progress here and have several changes queued up. I also have a handful of changes from Moritz to review. If you have any additional changes queued, please speak up. > ABI changes > --- > The security fixes don't currently break the ABI. It sounds like the > openvz fixes are ABI-breaking?. If it is going to be ready for this > update and does break the ABI, I'd also like to get the hppa > large-module fix in. And, of course, we'll need to notify the d-i team > of this change. Though several of the openvz changes have been committed and do not break the ABI, there are several openvz changes pending that do. These fix nfs support, ipv6, and some additional netfilter fixes. Maks is currently staging these additional fixes in his tree. There are also a couple of other non-openvz ABI changers ready, including #401439 and #520379. I spoke with Otavio and he noted that a d-i spin is going to happen for 5.0.1 anyway, so a kernel ABI change maybe better now than delaying for 5.0.2. So, I'd like to go ahead and bump the ABI and announce an upload to p-u for this Tuesday, March 24. -- dann frazier -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: linux-2.6 upload planned
On Sat, Jan 10, 2009 at 07:06:20AM +0100, Christian Perrier wrote: > Quoting dann frazier (da...@debian.org): > > hey, > > I wanted to give -release & -boot a heads up that the kernel team is > > looking to do a linux-2.6 upload to sid tomorrow. As discussed on the > > d-i channel, delays in the d-i release have given us a short window to > > introduce a new build for inclusion in RC2. > > > > Changes pending for this update include: > > - a few local DoS security issues > > - the hppa kernel fix that was causing crashes during ruby > > builds (doesn't fix the FTBFS - that may be a userspace issue) > > - reintroduces a driver for the ia64 rtc (regression) > > - several other fixes of >= important severity from Moritz's recent > > bug triage > > Does that include #508108?? yep > If there is a release, fixing that one would be worth it from what I > read in it. -- dann frazier -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: linux-2.6 upload planned
On Sat, Jan 10, 2009 at 01:08:01AM +0100, Petr Vyslouzil wrote: >> hey, >> I wanted to give -release & -boot a heads up that the kernel team is >> looking to do a linux-2.6 upload to sid tomorrow. As discussed on the >> d-i channel, delays in the d-i release have given us a short window to >> introduce a new build for inclusion in RC2. >> Changes pending for this update include: >> - a few local DoS security issues >> - the hppa kernel fix that was causing crashes during ruby >> builds (doesn't fix the FTBFS - that may be a userspace issue) >> - reintroduces a driver for the ia64 rtc (regression) >> - several other fixes of >= important severity from Moritz's recent >> bug triage > > Are XVR drivers (#508108) going to be included? If not, please, reconsider > as they've been successfully tried and tested in several different kernel > builds and on different HW. > Thanks. Yep! -- dann frazier -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
linux-2.6 upload planned
hey, I wanted to give -release & -boot a heads up that the kernel team is looking to do a linux-2.6 upload to sid tomorrow. As discussed on the d-i channel, delays in the d-i release have given us a short window to introduce a new build for inclusion in RC2. Changes pending for this update include: - a few local DoS security issues - the hppa kernel fix that was causing crashes during ruby builds (doesn't fix the FTBFS - that may be a userspace issue) - reintroduces a driver for the ia64 rtc (regression) - several other fixes of >= important severity from Moritz's recent bug triage -- dann frazier -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Call for testing of RC1 images
On Wed, Nov 05, 2008 at 01:54:20PM -0200, Otavio Salvador wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hello, > > The Debian-CD Team has prepared a testing set of images[1] of RC1 for us > to give it a try. If all goes well we should release Debian Installer > RC1 in Monday. > > 1. http://cdimage.debian.org/cdimage/.lenny_rc1/ > > Please give them a try and report any problem to us (in debian-boot > mailing list). fwiw, netinsts work fine on a HP ProLiant DL380 G5 (i386) and an HP Itanium rx2600 (ia64). thanks! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#496598: closed by Frans Pop <[EMAIL PROTECTED]> (Re: Bug#496598: fix for #494466 causes netinst to fail)
On Tue, Aug 26, 2008 at 06:51:03AM +, Debian Bug Tracking System wrote: > Problem is a version mismatch between bootstrap-base (1.93) and > base-installer (1.94). This is just the usual "arch all versus arch any" > breakage one can expect in unstable. > > Will fix itself with next images. > > Cheers, > FJP Indeed it did, thanks Frans! -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#496598: fix for #494466 causes netinst to fail
Package: base-installer Version: 1.94 Severity: serious hey, HP QA reported an issue with the most recent netinst builds for i386 and amd64. Their report follows: * New lenny builds of 24th Aug ??? both amd64 and i686 bit failed during installing the base system leading to installtion incomplete. SYSTEM CONFIGURATIONS: Server: BL480c and DL365G5 Operating System: Debian ??? Lenny amd64/i686 ??? netinstaller ??? 24th Aug Build Boot Controller: Smart Array P400i and E200i Network Controller: 373i STEPS TO REPRODUCE THE PROBLEM: 1. Select option - Install 2. Install the base system 3. After completing 79% of installation , the following error occurs The target file system contains files from a past installation. These files could cause problems with the installation process and if you proceed, some of the existing files may be overwritten. Proceed with installation to unclean target? Yes or No 4. When selected either, the step 2 restarts and the same error occurs when completes 79%. * I was able to reproduce this, and it appears to haev been introduced by the fix for #494466. I added 'set -x' into bootstrap-base postinst, and saw this[1] in syslog. To help verify, I retried the install w/ base-installer/initramfs-tools/driver-policy=most on the cmdline and the install completed w/o issue. [1] Aug 25 23:14:35 main-menu[1006]: (process:506): + break Aug 25 23:14:35 main-menu[1006]: (process:506): + [ initramfs-tools = initramfs-tools ] Aug 25 23:14:35 main-menu[1006]: (process:506): + db_get base-installer/initramfs-tools/driver-policy Aug 25 23:14:35 main-menu[1006]: (process:506): + _db_cmd GET base-installer/initramfs-tools/driver-policy Aug 25 23:14:35 main-menu[1006]: (process:506): + IFS= printf %s\n GET base-installer/initramfs-tools/driver-policy Aug 25 23:14:35 main-menu[1006]: (process:506): + IFS= Aug 25 23:14:35 main-menu[1006]: (process:506): read -r Aug 25 23:14:35 main-menu[1006]: _db_internal_line Aug 25 23:14:35 main-menu[1006]: (process:506): + RET=10 base-installer/initramfs-tools/driver-policy doesn't exist Aug 25 23:14:35 main-menu[1006]: (process:506): + return 10 Aug 25 23:14:35 main-menu[1006]: (process:506): + db_input medium base-installer/initramfs-tools/driver-policy Aug 25 23:14:35 main-menu[1006]: (process:506): + _db_cmd INPUT medium base-installer/initramfs-tools/driver-policy Aug 25 23:14:35 main-menu[1006]: (process:506): + IFS= printf %s\n INPUT medium base-installer/initramfs-tools/driver-policy Aug 25 23:14:35 main-menu[1006]: (process:506): + IFS= Aug 25 23:14:35 main-menu[1006]: (process:506): read -r _db_internal_line Aug 25 23:14:35 main-menu[1006]: (process:506): + RET=10 "base-installer/initramfs-tools/driver-policy" doesn't exist Aug 25 23:14:35 main-menu[1006]: (process:506): + return 10 Aug 25 23:14:35 main-menu[1006]: (process:506): + true Aug 25 23:14:35 main-menu[1006]: (process:506): + db_go Aug 25 23:14:35 main-menu[1006]: (process:506): + _db_cmd GO Aug 25 23:14:35 main-menu[1006]: (process:506): + IFS= printf %s\n GO Aug 25 23:14:35 main-menu[1006]: (process:506): + IFS= Aug 25 23:14:35 main-menu[1006]: (process:506): read -r _db_internal_line Aug 25 23:14:35 main-menu[1006]: (process:506): + RET=ok Aug 25 23:14:35 main-menu[1006]: (process:506): + return 0 Aug 25 23:14:35 main-menu[1006]: (process:506): + db_get base-installer/initramfs-tools/driver-policy Aug 25 23:14:35 main-menu[1006]: (process:506): + _db_cmd GET base-installer/initramfs-tools/driver-policy Aug 25 23:14:35 main-menu[1006]: (process:506): + IFS= printf %s\n GET base-installer/initramfs-tools/driver-policy Aug 25 23:14:35 main-menu[1006]: (process:506): + IFS= Aug 25 23:14:35 main-menu[1006]: (process:506): read -r _db_internal_line Aug 25 23:14:35 main-menu[1006]: (process:506): + RET=10 base-installer/initramfs-tools/driver-policy doesn't exist Aug 25 23:14:35 main-menu[1006]: (process:506): + return 10 Aug 25 23:14:35 main-menu[1006]: INFO: Menu item 'bootstrap-base' succeeded but requested to be left unconfigured. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#492899: partman-crypto: cancel button unusable on "Erasing data" screen
On Wed, Jul 30, 2008 at 11:58:38AM +0200, J?r?my Bobbio wrote: > On Tue, Jul 29, 2008 at 06:03:34PM -0600, dann frazier wrote: > > I wonder if there's a way to split the cancel checking and the > > progress checking? [???] > > It might be, but I am not inclined to do this kind of changes that tend > to breaks in very subtle way just before Lenny. makes sense > Dividing the progress bar in 65536 parts will give us an abitility to > cancel it every 1114112 written bytes, and should make it reactive > enough. Another option might be to make it dynamic, based on the size of the disk - I assume we'd need to add a parameter to the wipe utility to negotiate this in advance. That too might be something better suited for post-lenny exploration. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#492899: partman-crypto: cancel button unusable on "Erasing data" screen
On Wed, Jul 30, 2008 at 12:42:59AM +0200, J?r?my Bobbio wrote: > On Tue, Jul 29, 2008 at 11:47:59AM -0600, dann frazier wrote: > > When doing an LVM+crypto install, I am presented with a "Erasing data" > > screen with a Cancel button. It doesn't seem to be possible to use the > > cancel > > button - it is not highlighted, and pressing tab doesn't cause it to be. > > Are you using the newt frontend? In that case, could you try with the > GTK+ frontend? > > I have tried with both the newt and GTK+ frontend and the Cancel button > was usuable in both cases. hey Jeremy! I tried both - in the GTK+ frontend I am able to click cancel, but it doesn't seem to have any affect. > What size is the partition being erased? ~73G > After having a look at the source code, it's possible that, for a very > large partition, the progress would be updated rarely enough to give you > the impression that the Cancel button do not work, as its result would > not be checked often enough. That sounds plausible, and after adding some debug statments, I believe that your theory is correct. A kill does occur after the next iteration of the while loop after I click cancel. There's just a long time between iterations. But, I think the confusion might be the return value. At the end of crypto_do_wipe is this code: wait $pid ret=$? [ $cancelled -eq 1 ] && ret=0 return $ret } Which causes the function to return 0 if the user cancelled the process. Consider that a user might click cancel with no immediate result, then a minute or two later they are moved along to the next step (creating a password for the volume). They maybe led to believe that the wipe completed successfully, even though their cancel attempt did eventually succeed and cause the rest of the disk to not be cleared. > A possible fix in that case would be to divide the progress into more > steps than the current 100. But a deeper investigation would be > required before that. I wonder if there's a way to split the cancel checking and the progress checking? I'm still pretty green w/ d-i syntax, but it appears that we know of a cancellation when db_progress returns 30 - would it be possible/reasonable to do something like: crypto_do_wipe() { [existing code that starts up blockdev-wipe] ## fork a subshell to monitor for user cancels { while :; do sleep 1 db_progress if [ $? -eq 30 ]; then kill $pid echo somestring-to-advance-progress > $fifo fi } & watcherpid=$! [existing while loop that reads fifo] kill $watcherpid [...] } -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#492899: partman-crypto: cancel button unusable on "Erasing data" screen
Package: partman-crypto Version: 33 Severity: normal When doing an LVM+crypto install, I am presented with a "Erasing data" screen with a Cancel button. It doesn't seem to be possible to use the cancel button - it is not highlighted, and pressing tab doesn't cause it to be. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: ia64 Kernel: Linux 2.6.25-2-mckinley (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#492899: screenshot
http://free.linux.hp.com/~dannf/bugs/492899/no-can-cancel.png -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please review announcement of upcoming release of Debian 4.0r4 "etch-and-a-half"
On Sat, Jul 26, 2008 at 04:24:20PM +0200, Alexander Reichle-Schmehl wrote: > Hi! > > Attached you'll find the current draft for the announcement of > "etch-and-a-half". Please review it; current schedule for it to be send > out is tomorrow. > > I'll make the most up to date version available at > http://people.debian.org/~tolimar/tmp/ ; patches for the wml-file (which > is used to generate the HTML and the TXT version for the mail) are most > welcome, everything else is more work for me ;) hey Alexander, Thanks for working on this. Here's some suggested that helped clarify the language for me, and includes some stronger wording around the d-i network console issue (Frans may have something better though). --- /home/tolimar/public_html/tmp/20080726.wml 2008-07-26 10:10:56.0 -0600 +++ 20080726.wml2008-07-26 10:55:28.0 -0600 @@ -25,25 +25,25 @@ http://packages.debian.org/src:%0";>%0 The Debian project is pleased to announce the fourth update of its -stable distribution Debian GNU/Linux 4.0 (codename ). This update -not only adds corrections for security problems and a few adjustment to serious -problems to a stable release, it also adds support for newer hardware by giving +stable distribution Debian GNU/Linux 4.0 (codename ). In addition +to correcting several security problems and a few serious defects in the +stable release, this update also adds support for newer hardware by giving users the option to install newer drivers. -Please note that this update does not constitute a new version of Debian -GNU/Linux 4.0 but only updates some of the packages included. Even if you need -new drivers during installation time there is no need to throw away 4.0 CDs or -DVDs. If you do not need newer drivers you will only need to update against a -Debian mirror after an installation in order to incorporate these late -changes. - -Those who frequently install updates from security.debian.org will not have -to update many packages as most updates from security.debian.org are included -in this update. +Existing Debian GNU/Linux 4.0 installation CDs and DVDs can continue to be +used to install this update. After installation, upgrading via an up-to-date +Debian mirror will cause any out of date packages to be updated. However, users +of the network-console installation method are strongly encouraged to update +their media, see the "Debian Installer" portion of this announcment for +more information. + +Those who frequently install updates from security.debian.org won't have +to update many packages and most updates from security.debian.org are +included in this update. New CD and DVD images containing updated packages and the regular -installation media accompanied with the package archive will be available -soon at the regular locations. +installation media accompanied with the package archive respectively +will be available soon at the regular locations. Upgrading to this revision online is usually done by pointing the aptitude (or apt) package tool (see the sources.list(5) manual page) to @@ -91,16 +91,17 @@ Debian-Installer Update -The Debian-Installer was also updated due to changes regarding the creation -of SSL certificates used during installation via the network-console. Two other -issues regarding installation on existing RAID setups and recognizing PowerPC64 -systems have also been fixed. +The Debian-Installer was updated to repair an issue with the network-console +installation option. Due to a lack of entropy in how the host key is generated, +earlier Debian GNU/Linux 4.0 installers are vulnerable to a man-in-the-middle +attack. Two other issues regarding installation on already existing RAID +setups and recognizing PowerPC64 system have been fixed as well. Miscellaneous Bugfixes -This stable update adds several binary updates for various architectures -to packages whose version was not synchronised across all architectures. +This stable update adds several updates to packages for various +architectures whose version was not synchronised across all architectures. It also adds a few important corrections to the following packages: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#490542: k7 transitition
A few days ago, Frans said: > From a later discussion with some other people on IRC, it looks like > SSE support is probably the deciding factor. According to section > 2.2 in [1] and especially the note "Enabling SSE support" just above > section 2.3, models 0-5 for family 6 AMD processors may not have SSE > support and thus should continue to default to the 486 flavor. Thanks for the research Frans and the follow-up on IRC. However, after thinking about this, I'm not sure I follow the logic - or at least I need some hand holding to get it. >From reading the kernel source, it appears that a 686-configured kernel will cause gcc to use -march=i686. The gcc manual[1] implies that this will not cause sse instructions to be generated - pentium3 or athlon optimization (or greater) is required before SSE is enabled. The kernel does have some assembly routines coded in assembly that make use of SSE (e.g. the xor code used for raid checksumming), but they dynamically check for sse support by using cpu_has_xmm(). I do see why we wouldn't want to run a k7 kernel on all family 6 cpus. Google quickly found a /proc/cpuinfo file that shows a family 6 with no sse flag. However, I don't follow why this means a 686 kernel would not be safe on a family 6 cpu. [1] http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options [2] http://ubuntuforums.org/showpost.php?p=5119933&postcount=32 -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.24 upload for d-i
On Wed, May 07, 2008 at 09:06:01AM -0600, dann frazier wrote: > On Wed, May 07, 2008 at 12:14:14PM +0200, Bastian Blank wrote: > > On Tue, May 06, 2008 at 11:56:06PM -0600, dann frazier wrote: > > > Beta 2 of d-i will be using 2.6.24[1], the current version of which > > > is missing a couple of stable updates (including a handful of security > > > issues). > > > > Not necessary, 2.6.25 is available. So NACK from me. > > Right, but the d-i team has decided to go with 2.6.24 as explained in > Otavio's message. The sooner we help them get beta 2 out, the sooner > we can get 2.6.25 into testing. On the justification that 2.6.24 has been chosen for d-i beta2 and that an updated 2.6.24 is better than the existing 2.6.24, I'm going to proceed with preparing the t-p-u update. Granted, there are valid arguments for d-i to use 2.6.25 (as there were for staying with 2.6.24), but that decision belongs to the d-i team, and it has been made. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.24 upload for d-i
On Wed, May 07, 2008 at 12:14:14PM +0200, Bastian Blank wrote: > On Tue, May 06, 2008 at 11:56:06PM -0600, dann frazier wrote: > > Beta 2 of d-i will be using 2.6.24[1], the current version of which > > is missing a couple of stable updates (including a handful of security > > issues). > > Not necessary, 2.6.25 is available. So NACK from me. Right, but the d-i team has decided to go with 2.6.24 as explained in Otavio's message. The sooner we help them get beta 2 out, the sooner we can get 2.6.25 into testing. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
2.6.24 upload for d-i
hey, Beta 2 of d-i will be using 2.6.24[1], the current version of which is missing a couple of stable updates (including a handful of security issues). The d-i team poked me about doing an upload to t-p-u that includes these updates, which they'd like to happen quickly to get beta2 out of the way and permit 2.6.25 into testing. Therefore, I'd like to schedule an upload for Wednesday/Thursday of this week. By default I'd like to sync it with the changes queued for etchnhalf - this includes the two 2.6.24.y updates (minus the ABI changing tda10086 patch), and the bnx2/ich10 backports. Let me know if any other changes are necessary. [1] http://lists.debian.org/debian-boot/2008/05/msg00062.html -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#470707: rx2200?
hey Peter! I've been asking around for access to an rx2200 to debug this, but I'm told that no such model exists :) Can you doublecheck and/or provide a full boot log? It should print the model number out when ACPI is initialized. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: D-I Etch+1/2 CD images (was: D-I Etch+1/2 kernel selection)
On Wed, Feb 06, 2008 at 10:01:53PM +0100, Frans Pop wrote: > On Monday 04 February 2008, Frans Pop wrote: > > The required patches for the installer are attached. I have successfully > > tested them using a custom built netinst CD that had both the 2.6.18 and > > 2.6.22-686 kernels on it. > > The needed changes to D-I have now all been uploaded. > > > - There has as yet been no discussion about exactly which "Etch + Lenny > > D-I" CD images to create and exactly what should be included on them. > > I have just discussed this on #debian-cd with Sledge, and we've come up with > the following (rather brilliant) proposal. > > Architectures > = > Most architectures just do not have the type of hardware changes that will > prevent a user from installing with 2.6.18 and then upgrading to 2.6.24 > after the installation, so for those new installation CDs that use and > install the new kernels are really not needed. > > We therefore propose to _only_ create "etchnhalf" installation CDs for: > - i386 > - amd64 > - any other architectures for which a porter replies to this mail and can > demonstrate that some hardware that is not supported with the regular > Etch update, would be supported with the etchnhalf images > > Images > == > We don't really want to create a huge number of extra image and certainly > not additional full sets. Not only would that waste mirror space, but too > many different images will also just confuse users. > > Solution we propose is that we only create a netinst image with the > etchnhalf installer and kernels. However, this netinst image will be > modified in such a way that it can be used as "CD 0" of the regular updated > Etch full CD and DVD sets. > This idea makes use of the fact that the D-I Beta1 installer will offer to > scan additional CDs if the installation CD is part of a set. > > Nice extra is that this also means that the "etchnhalf netinst" could even > be used in combination with Etch CD/DVD sets from previous (point) > releases. Let me try and reiterate some points of your proposal to make sure I understand. The only install media for etchnhalf will be netinst cds. These cds will be limited to i386, amd64, and other archs for which a need is demonstrated. It sounds good to me - an additional benefit is that it reduces the number of images we need to test. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: D-I Etch+1/2 kernel selection (was: Beta1 missing decisions and possible timeline)
On Mon, Feb 04, 2008 at 01:53:43AM +0100, Frans Pop wrote: > Finally I created the etch-support udeb which does two things: > 1) add an early base-installer hook script that sets the 'altmeta' >template > 2) add an partman init.d hook script that changes the default >inode_size from 256 to 128 (only for i386 and amd64) [2] Is it known whether or not bootloaders on other archs (the etch versions, in particular) are affected by this change? I'm wondering if we shouldn't change the etch default to 128, except for archs with etch bootloaders that are known to support 256. > The result of 1) is IMO exactly what we want: > - the installer will automagically prefer the Etch+1/2 kernel [4] > (preseeding of the exact image as mentioned in [1] is /not/ > needed) that's a significant improvement, imo > - the installer will also install the etch+1/2 kernel meta package, which > ensures users will automatically get ABI-changing security updates > - if for some reason the etchnhalf kernels are not available, the installer > will fall back to the 2.6.18 kernels > - all this only happens if the Lenny installer is used and thus installs > using the regular (updated) Etch installer are not changed at all which is critical.. > There are still things to decide, and IMO consensus on this should be > reached soon! > - The naming of the etch+1/2 kernel meta packages is now suddenly essential > for the installer and should thus be decided on ASAP. We talked about this on #debian-kernel last week, and linux-image-2.6-$flavor-etchnhalf had no objections. > - There has as yet been no discussion about exactly which "Etch + Lenny D-I" > CD images to create and exactly what should be included on them [3]. > (Hell, the whole "Etch + Lenny D-I" concept hasn't even really been OKed.) > Because of mirror space issues _and_ because of required preparations on > the debian-cd side this _really_ needs to be discussed with Sledge > urgently. I'll reply to this on debian-cd only -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Beta1 missing decisions and possible timeline
On Sun, Feb 03, 2008 at 05:23:14PM -0200, Otavio Salvador wrote: > As suggested by Frans, with many good points, we'll release with > 2.6.22 but just after it, we'll start to work to release another beta > with 2.6.24 kernel. This should allow us to install a etchnhalf 2.6.24 on hardware supported by 2.6.22, and then the follow-on beta would add support for the remaining hardware (that supported by 2.6.24 but not 2.6.22). Unless someone sees a problem with this, it seems fine to me. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Beta1 missing decisions and possible timeline
On Thu, Jan 31, 2008 at 08:04:23PM -0200, Otavio Salvador wrote: > - kernel to release > >We have 2.6.22 as a safe bed on lenny now and their udebs are there >too however since EtchAndHalf intends to release with 2.6.24 and it >has been uploaded to sid already I'm considering a better option to >us to release with it. 2.6.24 is our default - 2.6.22 is a backup. We wanted to get some testing in sid first, and should be able to make a more informed decision based on user reports in about a week. >linux-2.6 has been built in all architectures and >linux-modules-extra-2.6 has been fastly processed (thanks >ftpmasters) and waldi, maks, panthera :) >and then we could manage to get a massbuild done in few >days (+- 5 of febuary or even before). I've started to check the >new modules and prepare the patches for kernel-wedge for it and >hope to get it ready for tomorrow or so. Awesome. Is there anything special we need to add to deal with etch 1/2 kernel metapackages? We were talking about using a name like linux-image-2.6-686-etchnhalf. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#454493: Display PCI slot for nics, if available
On Mon, Dec 31, 2007 at 09:43:15AM -0200, Otavio Salvador wrote: > dann frazier <[EMAIL PROTECTED]> writes: > > >> imo, the best and more widly solution would be the 2. That shouldn't > >> be too hard and would allow us to reduce the memory footprint not only > >> on your user case but in general usage too. > > > > Might be vearing off topic for this bug, but here's a wrapper I worked > > up (not yet tested in the d-i environment). > > It looks nice. > > I think that code might be more clear if you change the cleanup step > to be a funtion and it will make simpler to spot what is being done in > each case. Yes, this does improve readability. > I see no point in using aggresive policy. It would unload the modules > detected by udev and since we provide a small set of modules it looks > useless to me. Do you see any possible usage? No - it was just something I was playing with (see my comment in the code warning people not to use it). Also, I only think it makes sense to include a policy setting if its an option - e.g. an environment variable. If we find only only one policy useful, the others should be dropped to reduce code size/complexity. Attached is a new version that incorporates your factoring suggestion, and does away with the policy options. -- dann frazier modprobe-and-clean.sh Description: Bourne shell script
Bug#454493: Display PCI slot for nics, if available
On Thu, Dec 27, 2007 at 07:15:01PM -0200, Otavio Salvador wrote: > dann frazier <[EMAIL PROTECTED]> writes: > > Yeah. Options here would be: > > 1) big hammer - write a modprobe wrapper that cleans > > unused/unloadable modules after every load > > 2) smaller hammer - write a modprobe wrapper that remembers what was > > loaded before and, on failure, unloads all newly added, unused, > > unloadable modules > > 3) surgical hammer - whatever ends up loading acpihpi knows that, on > > failure, dock and pci_hotplug should be removed (if unused) > > > > fyi, the dependencies loaded, and left unused, eat 9476 (dock) and > > 28600 (pci_hotplug) bytes. > > imo, the best and more widly solution would be the 2. That shouldn't > be too hard and would allow us to reduce the memory footprint not only > on your user case but in general usage too. Might be vearing off topic for this bug, but here's a wrapper I worked up (not yet tested in the d-i environment). -- dann frazier modprobe-and-clean.sh Description: Bourne shell script
Bug#454493: Display PCI slot for nics, if available
On Thu, Dec 27, 2007 at 05:09:38PM -0200, Otavio Salvador wrote: > dann frazier <[EMAIL PROTECTED]> writes: > > > [1] Of course, acpiphp has module dependencies, and if these aren't > > cleaned up after a failed load, memory will still be lost to those > > modules > > It means that we'd need to find a way to get those dependencies and > walk throught them removing the unused ones. Yeah. Options here would be: 1) big hammer - write a modprobe wrapper that cleans unused/unloadable modules after every load 2) smaller hammer - write a modprobe wrapper that remembers what was loaded before and, on failure, unloads all newly added, unused, unloadable modules 3) surgical hammer - whatever ends up loading acpihpi knows that, on failure, dock and pci_hotplug should be removed (if unused) fyi, the dependencies loaded, and left unused, eat 9476 (dock) and 28600 (pci_hotplug) bytes. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#454493: Display PCI slot for nics, if available
(Good discussion so far, sorry for the late response..) On Sunday 09 December 2007, Frans Pop wrote: > On Friday 07 December 2007, dann frazier wrote: > > Understood. Note that this implementation doesn't *require* the > > module, it just takes advantage of it if its available. And, if > > other > > non-ACPI platforms begin populating the 'slot' sysfs field in the > > future, the installer would automatically work with it. > > Sure, but what use is it to implement it if we're not going to > actually use it? Adding support for it IMO also means adding any > modules needed to display the info (for platforms that support it of > course). My implication is that any installer builds that happen to include the appropriate acpi modules could use this functionality. However, I see you state elsewhere: On Sunday 09 December 2007, Frans Pop wrote: > For Dann's usage however, IMO it would really need to be part of the > initrd to ensure that we have consistent functionality between installation > methods, If consistency between install methods is a goal, then my note above isn't relevant... at least not while slot info requires additional modules. > Could you provide some data on what it would cost to add this module > to initrds? Needed is total of extra memory used because of increased > initrd size the module(s) getting loaded. Ideally we could do this experiment on i386 since its the only architecture I would expect to have ACPI and have tight memory requirements. Unfortunately, I don't have an i386 system that supports the acpiphp module - my systems only support cpqphp and acpiphp refuses to load if the system does not support it. However, if we can make the assumption that memory pressure isn't an issue on systems that support ACPI PCI HotPlug, then the memory lost to module load isn't significant[1]. I compared a standard build of the netboot/i386 flavor, and one where the acpiphp module were added to the acpi-modules udeb. acpiphp depends upon the pci_hotplug and dock modules, so they are also included. build initrd.gz sizeused memory standard 5005534 23864 w/ acpiphp5031680 24176 [1] Of course, acpiphp has module dependencies, and if these aren't cleaned up after a failed load, memory will still be lost to those modules Joey Hess wrote: > Frans Pop wrote: > > > eth0: foo bar description, eth0: mac address: xxx:xxx... [slot 1] > > > > > > That would be one way to do it without modifying debconf. You > > could also > > > get rid of the "eth0: " prefix if you wanted to by using > > Choices-C. > > > > I'm probably just being thick, but what exactly are you proposing > > here? > > Debconf would display the above example as: > > eth0: foo bar description > eth0: mac address: xxx:xxx... [slot 1] I like this idea, and Frans' suggestion to indent instead of duplicating the interface name would make it looks pretty nice. I can't think of any better way to do it w/o extending debconf. If noone has any major objections, I'll see if I can work up a patch. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: etch+1/2 D-I options (was: Meeting for etch and a half)
On Wed, Dec 12, 2007 at 10:20:45PM +0100, Frans Pop wrote: > 1) A new version of the Etch installer with support for both kernels > > This option would IMNSHO be insanity. > > First, I doubt people who are able and will want to work on the D-I side of > it can be found. > > Second, it would require having D-I initrds + kernel udebs + kernel packages > for 2 kernel versions on CDs meaning that netinst images would grow beyond > reasonable size and that an unacceptable number of other packages would get > pushed off the first full CD and DVD which would result in a significantly > reduced installation experience, mainly for the desktop task. > > > 2) Creating a second Etch installer based on the new kernel > --- > This is about on the same insanity level. > > It would also require extra work by FTP-masters because we'd somehow need > two separate D-I builds (sources, deb and images) in stable and on the > mirrors at the same time. > The only realistic option would be keeping the second installer outside the > archive, but that has its own disadvantages (chain of trust). > > And again I don't know who'd do the D-I work on it. Not saying its a good idea, but what would be the issues with creating additional flavors of select etch installers builds? e.g., netboot/netboot+, netinst/netinst+, etc. > > 3) Using the Lenny installer to install Etch > > This would be the easiest option. > > It is realistic for the following reasons: > - D-I is basically a mature product; a lot would have to go completely > wrong to have Lenny D-I releases that are not generally usable > - this has already been proven with Etch and D-I has only gotten more > stable; of course there will be a few errata, but there should be > nothing major; a lot of issues in betas have to do with _testing_ as > a suite and not with D-I > > The supported installation methods would be limited: no netinst CD or full > CD. What makes these two methods problematic? > For all other methods the user would have two options: > - run installation in expert mode or at medium priority; (s)he will then > be asked what suite to install and what kernel to install > - boot the installer with: > suite=stable base-installer/kernel/image=linux-image-2.6.24-x-$flavor > (or use 'suite=etch'); basically we tell the user to specify the actual > kernel instead of the default meta package; we can easily (and probably > should anyway) add an alias 'kernel' instead of the cumbersome parameter > 'base-installer/kernel/image' > > Of course you would need at least a Lenny beta 1 D-I release for this. > > Disadvantages (mainly netboot, not for businesscard and hd-media images): > - when a new Lenny D-I release is prepared, the old one can temporarily > be broken > - with later Lenny D-I releases the kernel used in the Lenny installer > could become newer than the etch+1/2 one > - if there were to be major changes at some point, supporting stable > installs could become harder or even impossible I would say an additional disadvantage is the complexity; these boot options seem pretty straightforward (esp if the "kernel" alias is added), but we lose the benefit of "just working". > 4) Option 3 + creating selected CD images based on the Lenny installer > -- > This would mainly depend on available debian-cd mirror capacity. > > This option is mostly relevant for netinst CDs and full CD/DVDs and > partially for businesscard CDs. It does not change 3) for netboot. > > It is relatively trivial to create CD images using packages from stable but > D-I from testing. I'd suggest not building full CD sets, but just the first > or first few images in a set. > > By including _only_ the new kernel packages on the CDs and omitting any meta > packages, the installer would automatically install the correct > kernel. I think I could use some clarification here. If there are metapackages for both etch and etch 1/2 kernels available (e.g. linux-image-2.6-686 and linux-image-2.6-23-686), would this prevent the installer from selecting the correct metapackage? Default metapackages are certainly something I'd like to see kept, to avoid the no-auto-upgrade problem we had w/ kernel abi changes in sarge. > For some architectures it should be possible to modify the default boot > parameters on the images so that the 'suite=etch' option is included by > default (with 'suite?=etch' th
Bug#454493: Display PCI slot for nics, if available
On Thu, Dec 06, 2007 at 01:34:25AM +0100, Frans Pop wrote: > On Wednesday 05 December 2007, dann frazier wrote: > > This patch to hw-detect adds slot information, if available, to the > > network device name. Its not uncommon for HP (or our customers) to > > have systems with many network devices, and knowing the physical slot > > number of an adapter makes configuration that much easier. > > I have several reservations against this patch: > - to have it work for all installation methods you'd need to to include > this acpi module (and others?) in initrds, which is something we don't > do lightly [1] Understood. Note that this implementation doesn't *require* the module, it just takes advantage of it if its available. And, if other non-ACPI platforms begin populating the 'slot' sysfs field in the future, the installer would automatically work with it. In fact, as to Otavio's point, it probably makes sense to do the module loading outside of hw-detect (e.g. his acpi-support-udeb suggestion), and just let hw-detect use the interface if its available. > - the "slot" indication is not translatable in the current patch I didn't think to make this translatable, but yes, it should be. > - the descriptions are already quite long and this will truncate some of > them even more than they already are Yeah, I expected someone would point this out. There are possible hacks like filtering out redundant words/phrases like "Ethernet Controller", but I think what we really need is to get out of the single-line description, more on this below. > - I'm not sure that as a user it would be clear to me what exactly a Slot > is in this context I could change this to "PCI Slot" or "PCI Card Slot", and would even prefer it, but that will of course take more space. > - looking at your screenshot it does not seem to add all that much > identification as there are still several NICs with identical slots The snapshot was taken from a machine w/ dual-port cards installed, so it is correct for both nics to claim the same slot. This case does leave some ambiguity, but much less ambiguity than before. > - it seems only a partial solution as not all NICs will be get a slot > identifier Again, it decreases ambiguity. In my screenshot, you can see that two nics aren't in slots because they are built into the system board. You don't know which one is which, but in a system with 20 nics, it certainly saves you some time finding the right one. (And 20 NICs really isn't a contrived example, but is of course a small minority of Debian users). > - I'm not sure that it makes sense to print slot if it's the only > identification Can you restate this one - I didn't really follow it. > We've had other requests to provide additional identification of NICs (see > #450605 and merged BRs) and so far we (or at least I) have been thinking of > some way to display the MAC address, possibly by allowing to switch between > display of the current descriptions and MAC address. That would help some users, but I'd like to see us find a more general way to display all the available information that a user might use for identification. And I expect a separate display, or "view" for each may prove not to scale. I do like the genearl principle of Geert's proposal: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=450605#31 With the exception that I don't like splitting the option list from the selection widget (and as Bastian points out, its not possible anyway). Some brainstorming: * Modify cdebconf to permit per-option descriptions, and use those descriptions to provide details about each nic. Frontends could use this to implement a "more info" button, or just include the description text in-line. * Modify cdebconf to support multi-line choice fields. Make each interface choice be a multi-lined option that includes things like vendor, model, mac, slot. * Change the flow from "select iface" -> "configure iface" to: "select iface" v "display info about iface & confirm" v "configure iface" This is probably the only one possible w/ today's cdebconf, but its pretty non-intuitive. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#454493: Display PCI slot for nics, if available
On Wed, Dec 05, 2007 at 05:03:41PM -0200, Otavio Salvador wrote: > dann frazier <[EMAIL PROTECTED]> writes: > > > Currently this patch only attempts to load the acpiphp driver - it > > should probably try and load others as well (e.g. pciehp & shchp, and > > the future possible pci_slot). > > Why acpihp isn't loaded by udev automaticaly? I'm probably not the best person to answer that question, but I can give you some handwavy guesswork :) I'm guessing that you're asking this because you've seen other pci hotplug drivers get loaded by udev. I've noticed this too - shpchp loads on some of my boxes, so I looked to see why. Turns out that shpchp registers itself as a driver for pci devices that are in the pci bridge class, so this mapping is available to udev in modules.pcimap. acpiphp doesn't register itself for any pci devices - in fact, the machine I test on doesn't show any pci bridges devices in lspci, so I'm assuming they're transparent to udev as well. The devices on this bridge work just fine, they are just not hotpluggable until the acpiphp module is loaded. I wondered if this was always the case with ACPI-described bridges, so I asked Matthew Wilcox: willy: is it the case that pci bridges described by ACPI never (or not always) appear as pci devices themselves? dannf: No correlation. If they're PCI-PCI bridges, they will show up in the PCI namespace, but there's no way to tell whether or not they support acpiphp I believe that currently the only way to know if a machine supports acpiphp is to load it. This seems to match up pretty well with my observations of other acpi drivers. acpid seems to take ownership of loading acpi modules like battery, fan, thermal, etc - it simply modprobes them and lets the driver do the discovery. Maybe it should also be loading acpiphp? Perhaps. Does d-i do anything wrt loading acpi drivers today (other than installing acpid into the target)? -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#454493: Display PCI slot for nics, if available
Package: hw-detect Version: 1.58 Severity: wishlist Tags: patch The linux kernel may expose slot information for PCI devices in sysfs. Currently slot info is only exposed if the PCI device is hotpluggable and the associated hotplug driver is loaded. However, work is underway[1] to expose slot information for non-hotplug pci devices that are exposed via ACPI. This patch to hw-detect adds slot information, if available, to the network device name. Its not uncommon for HP (or our customers) to have systems with many network devices, and knowing the physical slot number of an adapter makes configuration that much easier. Currently this patch only attempts to load the acpiphp driver - it should probably try and load others as well (e.g. pciehp & shchp, and the future possible pci_slot). Attached is a screen shot of a d-i build w/ this patch. Some nics share the same slot because they are dual-port cards, and some nics have no slot info because they are not hotplug and I'm using a standard kernel that does not yet have non-hotplug slot support. [1] http://lkml.org/lkml/2007/11/12/263 http://lkml.org/lkml/2007/11/14/331 http://lkml.org/lkml/2007/11/17/126 Index: hw-detect/debian/changelog === --- hw-detect/debian/changelog (revision 50286) +++ hw-detect/debian/changelog (working copy) @@ -1,3 +1,9 @@ +hw-detect (1.59) UNRELEASED; urgency=low + + * Display the PCI slot for network device, if exported in sysfs + + -- dann frazier <[EMAIL PROTECTED]> Tue, 04 Dec 2007 18:02:24 -0700 + hw-detect (1.58) unstable; urgency=low * Install acpi-support-base, needed now to get power button shutdowns to Index: hw-detect/sysfs-update-devnames.sh === --- hw-detect/sysfs-update-devnames.sh (revision 50286) +++ hw-detect/sysfs-update-devnames.sh (working copy) @@ -2,6 +2,35 @@ # Make sure that /etc/network/devnames is up to date, using sysfs. In # hotplug land, we may not get a chance to update it otherwise. +# This currently only works for hotplug devices, but may work for +# others devices in the future. +iface_to_slot() { + iface="$1" + + if [ ! -h "/sys/class/net/$iface/device" ]; then + return 1 + fi + + modprobe acpiphp || true + + if [ ! -d /sys/bus/pci/slots ]; then + return 2 + fi + + ifdevpath=$(readlink "/sys/class/net/$iface/device") + ifaddr=${ifdevpath##*/} + ifaddr=${ifaddr%.*} + + ifslot="" + for slot in /sys/bus/pci/slots/*; do + if [ "$ifaddr" = "$(cat $slot/address)" ]; then + echo ${slot##*/} + return 0 + fi + done + return 4 +} + if [ ! -d /sys/class/net ] || ! type lspci >/dev/null 2>&1; then exit fi @@ -14,12 +43,13 @@ [ -f "/sys/class/net/$dev/device/device" ]; then vendor="$(sed 's/^0x//' "/sys/class/net/$dev/device/vendor")" device="$(sed 's/^0x//' "/sys/class/net/$dev/device/device")" + slot="[Slot $(iface_to_slot $dev)] " || slot="" # 'tail -n 1' because for some reason lspci outputs two # Device: lines. vendorname="$(lspci -d "$vendor:$device" -m -v | grep ^Vendor: | tail -n 1 | sed 's/^Vendor:[[:space:]]*//; s/,/\\,/g')" devicename="$(lspci -d "$vendor:$device" -m -v | grep ^Device: | tail -n 1 | sed 's/^Device:[[:space:]]*//; s/,/\\,/g')" - if [ "$vendorname" ] || [ "$devicename" ]; then - echo "$dev:$vendorname $devicename" >> /etc/network/devnames + if [ "$vendorname" ] || [ "$devicename" ] || [ "$slot" ]; then + echo "$dev:$slot$vendorname $devicename" >> /etc/network/devnames fi elif [ "$(readlink -f /sys/class/net/$dev/device/bus)" = /sys/bus/ieee1394 ] || \ [ "$(readlink -f /sys/class/net/$dev/device/bus)" = /sys/bus/firewire ]; then -- dann frazier <>
Bug#453749: simpler solution
I couldn't find any difference in how the kernel was setting up the console that would affect the /proc/$dipid/fd/0 link, so I started looking into userspace. Busybox's console_init() tries to find and use the real console device. It starts by checking to see if its a serial device in much the same way that serial-console-info does. After determining what it thinks *should* be the right device name, init tries to open that device file. If this fails, it falls back to using /dev/console, which I believe leads to this problem. It turns out that rootskel init only creates two serial devices before calling busybox init - ttyS0 and ttyS1. My system where /proc/$dipid/fd/0 was pointing to /dev/console used ttyS3 as the real console, while my system where /proc/$dipid/fd/0 pointed to the real device used ttyS0. ttyS3 as a serial console is very commonplace for HP ia64 systems, as this is the device typically emulated by the management processor to make the console available over the network. Index: debian/changelog === --- debian/changelog(revision 50286) +++ debian/changelog(working copy) @@ -1,3 +1,11 @@ +rootskel (1.58) UNRELEASED; urgency=low + + * Create more serial device files in the ramdisk before calling +busybox init, in case they are needed for a serial console. +Closes: #453749. + + -- dann frazier <[EMAIL PROTECTED]> Mon, 03 Dec 2007 20:25:03 -0700 + rootskel (1.57) unstable; urgency=low * debian-installer-startup.d/S02netwinder-net: restructure so Index: src/lib/debian-installer/init-udev-devices === --- src/lib/debian-installer/init-udev-devices (revision 50286) +++ src/lib/debian-installer/init-udev-devices (working copy) @@ -13,6 +13,6 @@ for i in 0 1 2 3 4; do makedev 600 /dev/tty"$i" c 4 "$i" done -for i in 0 1; do +for i in 0 1 2 3; do makedev 600 /dev/ttyS"$i" c 4 "$(($i + 64))" done -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#453749: Fix serial console detection on ia64
Thanks for your responses. As I was writing this report, I began to wonder why exactly the proc trick doesn't work on some ia64 configs - I'm investigating this now. If I can find a workable solution there, we may be able to forego these changes - if not, I'll regenerate new patches based on your comments. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#453749: patches
Index: finish-install/debian/changelog === --- finish-install/debian/changelog (revision 50280) +++ finish-install/debian/changelog (working copy) @@ -1,3 +1,10 @@ +finish-install (2.13sci1) UNRELEASED; urgency=low + + * 90console: Use serial-console-info tool if /proc console +detection is being stubborn. + + -- dann frazier <[EMAIL PROTECTED]> Thu, 29 Nov 2007 14:32:24 -0700 + finish-install (2.13) unstable; urgency=low * 90console: avoid duplication of values on /etc/securetty. Index: finish-install/finish-install.d/90console === --- finish-install/finish-install.d/90console (revision 50280) +++ finish-install/finish-install.d/90console (working copy) @@ -21,6 +21,17 @@ # to tell the truth. inst_pid=$(pidof debian-installer | sed "s/ /\n/g" | sort -n | head -n 1) rawconsole=$(readlink /proc/${inst_pid}/fd/0) +# The proc trick doesn't always work +# For example, when ia64 detects EFI console settings, /proc only exposes +# /dev/console +if [ "$rawconsole" == "/dev/console" ] && \ + [ -x /bin/serial-console-info ] && \ + /bin/serial-console-info > /tmp/serial-console-info.out; then + sci_port=$(grep ^DEV= /tmp/serial-console-info.out | cut -d= -f2) + sci_baud=$(grep ^SPEED= /tmp/serial-console-info.out | cut -d= -f2) + rawconsole="/dev/$sci_port" +fi +rm -f /tmp/serial-console-info.out console=$(mapdevfs "$rawconsole") rawconsole=${rawconsole#/dev/} console=${console#/dev/} @@ -32,7 +43,11 @@ log "Configuring init for serial console" consoletype=${console%%[0-9]*} ttyline=${console#$consoletype} - ttyspeed=$(chroot /target stty --file /dev/$console speed) + if [ -n "$sci_baud" ]; then + ttyspeed="$sci_baud" + else + ttyspeed=$(chroot /target stty --file /dev/$console speed) + fi ttyterm="$TERM" if [ -z "$ttyterm" ]; then ttyterm=vt100; fi Index: debian-installer-utils/debian/changelog === --- debian-installer-utils/debian/changelog (revision 50280) +++ debian-installer-utils/debian/changelog (working copy) @@ -1,3 +1,9 @@ +debian-installer-utils (1.50sci1) UNRELEASED; urgency=low + + * Add serial-console-info utility + + -- dann frazier <[EMAIL PROTECTED]> Thu, 29 Nov 2007 14:48:58 -0700 + debian-installer-utils (1.50) unstable; urgency=low [ Frans Pop ] Index: debian-installer-utils/debian/rules === --- debian-installer-utils/debian/rules (revision 50280) +++ debian-installer-utils/debian/rules (working copy) @@ -42,7 +42,8 @@ dh_install -pdi-utils anna-install apt-install debconf-disconnect \ debconf-get debconf-set log-output \ register-module search-path update-dev \ - user-params in-target list-devices bin + user-params in-target list-devices \ + serial-console-info bin dh_install -pdi-utils chroot-setup.sh lib dh_installdirs -pdi-utils usr/lib/post-base-installer.d install register-module.post-base-installer debian/di-utils/usr/lib/post-base-installer.d/10register-module Index: debian-installer-utils/serial-console-info.c === --- debian-installer-utils/serial-console-info.c (revision 0) +++ debian-installer-utils/serial-console-info.c (revision 0) @@ -0,0 +1,32 @@ +/* + * If /dev/console is mapped to a serial device, report the device name + * and speed. The readlink /proc/self/fd/0 trick doesn't always work. + * An example of this is ia64, where the EFI console settings are detected + * and used by default. + */ + +#include +#include +#include +#include +#include + +int main(int argc, char **argv) +{ + int fd; + struct serial_struct serial_info; + + fd = open("/dev/console", O_RDWR); + if(fd < 0) + return -1; + + if(ioctl(fd, TIOCGSERIAL, &serial_info) == -1) + return -1; + + close(fd); + + printf("DEV=ttyS%d\n", serial_info.line); + printf("SPEED=%d\n", serial_info.baud_base); + + return 0; +} Index: debian-installer-utils/Makefile === --- debian-installer-utils/Makefile (revision 50280) +++ debian-installer-utils/Makefile (working copy) @@ -1,5 +1,5 @@ ifndef TARGETS -TARGETS=mapdevfs log-output +TARGETS=mapdevfs log-output serial-console-info endif CFLAGS=-Wall -W -Os -fomit-frame-pointer -g @@ -15,6 +15,9 @@ log-output: log-output.c $(CC) $(CFLAGS) $^ -o $@ -ldebian-installer +serial-console-info: serial-console-info.c + $(CC) $(CLFAGS) $^ -o $@ + strip: $(TARGETS) $(STRIP) $^
Bug#453749: Fix serial console detection on ia64
Package: finish-install Version: 2.13 Severity: important Tags: patch If you boot an ia64 system[1] without specifying a console= parameter, the kernel will try to map /dev/console to whatever settings were detected from EFI (firmware interface). If EFI uses a serial console, /dev/console will be mapped to that same serial device. d-i interacts with the user via /dev/console, so most of the time the installer doesn't really care what the underlying device is. That is, until the system needs to decide where it should run gettys, and where root logins are permitted. This works is done by 90console. 90console attempts to detect the real console device by dereferencing /proc//fd/0. If a system was booted w/ console=ttyS0, /proc//fd/0 will link to /dev/ttyS0. However, on certain ia64 platforms[2], this link points to the ever-so-helpful /dev/console. The only way we've found to identify the correct device is to use a small C program that issues an ioctl to the device to retrieve the line number and speed (thanks to Bryan Stillwell for this research/work[3]). The workaround for this in etch is to always specify a console= parameter, thereby disabling the automatic console setup. The attached patch to di-utils adds a slightly modified version of Bryan's utility. This utility was originally called getserialdev - I've renamed it to serial-console-info, since I think it better describes the function. Also, getserialdev's output was of the form: # ./getserialdev ttyS2 115200 I've modified this to instead tag the data, so that it should be easier to maintain backwards compatability should this utility provide additional output in the future. e.g.: # ./serial-console-info DEV=ttyS2 SPEED=115200 The attached patch to finish-install adds support for using serial-console-info, if available, to 90console. Processing behaves just as before, until it finds that /proc//fd/0 is pointing at /dev/console. It will only then run serial-console-info to see if it can determine that /dev/console is actually a serial device. I briefly considered implementing serial console detection entirely with serial-console-info - but decided against it. The major problem is that serial-console-info assumes that any device it finds has a ttyS prefix, which may not always be correct. [1] Possibly other EFI-based systems as well, I haven't verified [2] an rx1600 w/ an MP for one [3] https://launchpad.net/bugs/48752 -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[stable] another linux-2.6 before 4.0r2
A number of lower-priority security updates have been queuing up for linux-2.6, so I'm planning to issue a new DSA this week (2.6.18.dfsg.1-13etch5). This will mean that we need to do another update of the p-u kernel to avoid introducing regressions in 4.0r2, which will give us an opportunity to include the fix for #433187 (the infamous sparc hang). I am well aware that the arm port is still suffering from the linux-latest-2.6 breakage from 4.0r1, and my intent is not to increase the delay for that fix. If a 4.0r2 is expected to happen RSN, let me know and I can hold off for a week or so. No ABI change is planned, so a d-i respin shouldn't be necessary - but I'll leave it up to the d-i team to make that call. I should also point out that sarge has a number of issues piling up as well, but it would save a lot of effort to do it after 3.1r6 *hint* :) -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Meeting for etch and a half
On Wed, Oct 31, 2007 at 01:51:59PM -0600, dann frazier wrote: > On Tue, Oct 30, 2007 at 05:36:20PM -0600, dann frazier wrote: > > On Sun, Oct 28, 2007 at 07:14:06PM -0400, David Nusinow wrote: > > > Would someone please post irc logs for those of us who can't make that > > > date? > > > > Yes, we will. > > Here ya go: > http://meetbot.debian.net/meetbot/debian-release.20071031_1800.html > http://meetbot.debian.net/meetbot/debian-release.log.20071031_1800.html As per the minutes, and thanks to Michael Banck, we now have a mailing list for etch and a half discussions. Post address: [EMAIL PROTECTED] Subscribe address: [EMAIL PROTECTED] Archives: http://teams.debian.net/lurker/list/project-etchnahalf.en.html Sorry for the delay in setting it up; seems my first request never made it. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#389430: Updated patch; make mirror/udeb/suite support multiple suites
On Sat, Nov 03, 2007 at 02:04:28AM +0100, Frans Pop wrote: > On Saturday 03 November 2007, dann frazier wrote: > > Here's an updated patch that implements Joey's suggestion of extending > > mirror/udeb/suite to support multiple suites. Again I've omitted the > > indention of the inner loop to make it clear what has changed. > > Has this been tested? Damn - you had to ask that! Well, yes, it has been tested, but against the etch version of net-retriever. Let me test against the trunk yep, still works. > > * It doesn't solve the issue Frans highlighted about components > >coming from separate mirrors. A proper solution for that problem > >would probably involve letting users preseed with arbitrary sets of > >sources.list style entries, meaning components can be fetched from > >multiple types of media within one installation instance. That'd > >certainly be a better paradigm, but would require much more > >invasive changes. > > I don't really like the idea of leaving this open if we're going to make > changes here anyway. > > OTOH... > > + ? ?is available from multiple places, anna's current behavior is to use > > + ? ?the last one, not necessarily the one with the greatest version. > > This is completely broken of course if we want to use this for experimental > as that _can_ have older versions than the real suite being used. Yeah, anna could use improvement here; is there version comparison code in d-i somewhere already? > > Regarding the removal of this comment: > > -???# Setting codename to a suite is not very nice, but can do no harm > > if ! db_get mirror/udeb/suite || [ -z "$RET" ]; then > > if [ -f /etc/udebs-source ]; then > > Note that what you are doing now is just the opposite: in the _default_ > situation the contents of /etc/udebs-source is used and that _is_ a > codename (set at D-I images build time). All the rest are the exceptions! > This should at least remain clear from the code or comments. Ok. I thought the comment was explaining that the variable named 'codename' was being abused to possibly include a non-codename, and that renaming the variable to 'udebsuites' solved that problem. But anyway, I agree it could use some clarifying comments. What I'm hearing is: Changes this patch needs: * comments around the suite selection bit * proper indention of the loop Additional changes we want: * anna version selection smarts * refactoring the nested loops into subroutines * deprecate m/u/suite for m/u/suites, providing backwards compatability Does that look accurate? -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#389430: Updated patch; make mirror/udeb/suite support multiple suites
Frans, Joey: thanks for your beedback, and sorry for the latency - I was travelling/offline quite a bit in the past week. Here's an updated patch that implements Joey's suggestion of extending mirror/udeb/suite to support multiple suites. Again I've omitted the indention of the inner loop to make it clear what has changed. What I don't like about it: * I'd prefer mirror/udeb/suites to mirror/udeb/suite, but I don't think its a good enough reason to break an interface that's already part of a stable release. One option would be to deprecate the singular version, but support it for one more release - in the meantime we could use one as an alias for the other, giving precedence to the plural version. * I don't like how nested things are getting; if this is accepted, I'd probably want to follow up with a patch that moves some of the inner code into its own function. * It doesn't solve the issue Frans highlighted about components coming from separate mirrors. A proper solution for that problem would probably involve letting users preseed with arbitrary sets of sources.list style entries, meaning components can be fetched from multiple types of media within one installation instance. That'd certainly be a better paradigm, but would require much more invasive changes. Index: debian/changelog === --- debian/changelog(revision 50009) +++ debian/changelog(working copy) @@ -1,3 +1,12 @@ +net-retriever (1.19) UNRELEASED-unstable; urgency=low + + * Let mirror/udeb/suite support multiple values. Components from each +of these suites will be accessible by anna. In the case that a package +is available from multiple places, anna's current behavior is to use +the last one, not necessarily the one with the greatest version. + + -- dann frazier <[EMAIL PROTECTED]> Fri, 02 Nov 2007 17:41:47 -0600 + net-retriever (1.18) unstable; urgency=low * Use /etc/udebs-source as the default release from which to fetch udebs. Index: net-retriever === --- net-retriever (revision 50009) +++ net-retriever (working copy) @@ -96,7 +96,6 @@ rm -f "$1" touch "$1" - # Setting codename to a suite is not very nice, but can do no harm if ! db_get mirror/udeb/suite || [ -z "$RET" ]; then if [ -f /etc/udebs-source ]; then RET=$(cat /etc/udebs-source) @@ -104,18 +103,19 @@ db_get mirror/codename fi fi - codename="$RET" + udebsuites="$RET" Release="/tmp/net-retriever-$$-Release" - fetch "dists/$codename/Release" "$Release" || exit $? + for suite in $udebsuites; do + fetch "dists/$suite/Release" "$Release" || exit $? # If gpgv and a keyring are installed, authentication is # mandatory by default. if type gpgv >/dev/null && [ -f "$keyring" ]; then if db_get debian-installer/allow_unauthenticated && [ "$RET" = true ]; then log "Not verifying Release signature: unauthenticated mode enabled" else - if ! fetch "dists/$codename/Release.gpg" "$Release.gpg"; then - error "dists/$codename/Release is unsigned." + if ! fetch "dists/$suite/Release.gpg" "$Release.gpg"; then + error "dists/$suite/Release is unsigned." fi if ! log-output -t net-retriever --pass-stdout \ gpgv --status-fd 1 --keyring "$keyring" \ @@ -143,7 +143,7 @@ fi Packages="/tmp/net-retriever-$$-Packages" rm -f "$Packages" - fetch "dists/$codename/$pkgfile" "$Packages" || continue + fetch "dists/$suite/$pkgfile" "$Packages" || continue checkmatch "$Release" "$pkgfile" \ "$(md5sum "$Packages" | cut -d' ' -f1)" \ "$(wc -c < "$Packages" | tr -d ' ')" @@ -156,6 +156,8 @@ break done done + rm -f "$Release" + done exit $ret ;; -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Meeting for etch and a half
On Tue, Oct 30, 2007 at 05:36:20PM -0600, dann frazier wrote: > On Sun, Oct 28, 2007 at 07:14:06PM -0400, David Nusinow wrote: > > Would someone please post irc logs for those of us who can't make that date? > > Yes, we will. Here ya go: http://meetbot.debian.net/meetbot/debian-release.20071031_1800.html http://meetbot.debian.net/meetbot/debian-release.log.20071031_1800.html -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]