from:"dann frazier"

Bug#831003: support gzip'd kernel image

2016-07-13 Thread dann frazier

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 <da...@debian.org>  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

2015-02-01 Thread dann frazier

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 21 || 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

2015-01-30 Thread dann frazier

On Fri, Jan 30, 2015 at 07:15:32AM +0100, Cyril Brulebois wrote:
 Christian PERRIER bubu...@debian.org (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

2015-01-29 Thread dann frazier

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

2015-01-28 Thread dann frazier

On Wed, Jan 28, 2015 at 06:10:49PM +0100, Cyril Brulebois wrote:
 dann frazier da...@debian.org (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

2015-01-28 Thread dann frazier

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

2014-06-05 Thread dann frazier

On Thu, Jun 05, 2014 at 08:43:02AM +0100, Ian Campbell wrote:
On Wed, 2014-06-04 at 11:40 -0600, dann frazier wrote:
On Fri, May 30, 2014 at 09:50:37AM +0100, Ian Campbell wrote:
On Wed, 2014-05-28 at 16:30 -0600, dann frazier wrote:
On Tue, May 27, 2014 at 10:35:18AM -0600, dann frazier wrote:
On Mon, May 26, 2014 at 11:54:31AM +0100, Ian Campbell wrote:
On Wed, 2014-05-21 at 14:59 -0600, dann frazier wrote:
hey,
A couple of projects we're working on at work require some
tweaking of u-boot settings. These requirements can be summed up
by:

A) Maintain the console= setting, and ideally all userargs (the
cmdline args after --) after install. This seems like
standard
Debian functionality that exists on other architectures, but
is
currently missing on flash-kernel platforms.

B) The ability to let a package change settings in the u-boot
environment. We have a case where a u-boot envvar setting
needs to differ depending on whether or not certain software
will be used (their u-boot has special code that reconfigures
the hardware depending on the setting of this variable).

The systems we're dealing with use a boot.scr script generated by
flash-kernel. So, we figure we could solve both by letting
packages
drop in u-boot code snippets that will be prepended to the
boot.scr. To do this, we propose a scheme similar to
initramfs-tools
where packages can drop snippets in a path under /usr/share
(solving
B), and users can add their own new setings or override the
/usr/share
versions by dropping snippets under /etc. With this scheme in
place,
flash-kernel-installer could be extended to drop in a file in /etc
that does a 'setenv bootargs $userargs' to solve (A). Comments?

I think snippets like this are a useful idea in general, but I
wonder if
something like the command line isn't deserving of higher billing,
e.g. via a setting in /etc/defaults/flash-kernel:COMMAND_LINE?

It looks like Ubuntu is carrying a patch that does this today:

http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/utopic/flash-kernel/utopic/revision/443.2.7

There the the variable is called UBOOT_DEFAULTS. I think
KERNEL_CMDLINE would be a more obvious name, but it would also be
nice to be reducing their diff.

Looking at grub as an example, I think we'll want to make the cmdline
paramaters a debconf setting, giving the user the option to modify the
proposed cmdline in expert mode.

1) f-k-i would use user-params to generate a reasonable default set
cmdline args and set flash-kernel/linux_cmdline.
2) f-k/configure would prompt the user (priority=high) for changes to
this default during configuration.
3) f-k/postinst would generate /etc/default/flash-kernel, and
presumably using ucf to manage it from there on

Sound reasonable?

It does.

I'm travelling right now but I took a brief look through the patches, I
think you should go ahead and push them.

My target platform is actually an arm64 system, which I can't easily
test it with Debian's d-i (yet). But I did manage to find an armhf
system to test on this week. There were a few issues with my changes
that I found/fixed (multiline support for ubootenv stubs,
brokendebconf-set-selections call, etc), but it seems to be working as
expected now. I went ahead and also added support for the armhf test
system I used (Calxeda Highbank) and my target platform (APM Mustang),
which also required turning on arm64 support.

Reading the diffs in my mail
client suggested there was some mixing of hard and soft tabs, butthat's
only a minor thing.

Should be fixed in the merged version.

I didn't see any boot.scr using this stuff, I suppose that is to
come?

Yeah - added this for both new platforms I've introduced.

I'll probably make the sunxi/cubietruck stuff use it at some point.

Cool. In the meantime, I'll plan to do an f-k upload tomorrow, in case
anyone wants to take some time to review the merged changes.

Mostly looks good too me.

The xgene script is missing the extra bootenv marker.

Oh, good catch - obviously I haven't tested a Debian install on that
system yet :) Fix pushed.

Bootloader-Sets-Incorrect-Root is marked required in the README but is
omitted from X-gene. I think since 850c8fc3 the behaviour when missing
is now to treat it as no which is the sane default, so perhaps the fix
is to make the README reflect that rather than fiddle with the Xgene db
entry.

Either works for me.

flash-kernel upgrade rather than on install via di is a worry. Bootargs
gets overridden to the default from /etc

Re: [RFC] flash-kernel hook to prepend to boot script

2014-06-05 Thread dann frazier

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.

Sound reasonable?

It does.

I'm travelling right now but I took a brief look through the patches, I
think you should go ahead and push them.

Reading the diffs in my mail
client suggested there was some mixing of hard and soft tabs, butthat's
only a minor thing.

Should be fixed in the merged version.

I didn't see any boot.scr using this stuff, I suppose that is to
come?

Yeah - added this for both new platforms I've introduced.

I'll probably make the sunxi/cubietruck stuff use it at some point.

Cool. In the meantime, I'll plan to do an f-k upload tomorrow, in case
anyone wants to take some time to review the merged changes.

Mostly looks good too me.

The xgene script is missing the extra bootenv marker.

Oh, good catch - obviously I haven't tested a Debian install on that
system yet :) Fix pushed.

Re: [RFC] flash-kernel hook to prepend to boot script

2014-06-04 Thread dann frazier

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.

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.

Sound reasonable?

It does.

I'm travelling right now but I took a brief look through the patches, I
think you should go ahead and push them.

Reading the diffs in my mail
client suggested there was some mixing of hard and soft tabs, butthat's
only a minor thing.

Should be fixed in the merged version.

I didn't see any boot.scr using this stuff, I suppose that is to
come?

Yeah - added this for both new platforms I've introduced.

I'll probably make the sunxi/cubietruck stuff use it at some point.

Cool. In the meantime, I'll plan to do an f-k upload tomorrow, in case
anyone wants to take some time to review the merged changes.

-dann

Ian.

-dann

FWIW latest Debian flash-kernel supports substituting @@KERNEL_VERSION@@
in the boot.scr with the actual kernel version in use. We could follow a
similar path for command line args (e.g. if you agree /e/d/flash-kernel
is a good place for this setting).

Yeah, that makes sense. For non-cmdline options, should we make that a
substitution as well (e.g. @@UBOOT_ENV_EXTRA@@), or automatically prepend
the snippets for every boot.scr? The former might be nice if we want
to transition platforms over individually as we can test them. But,
the downside is inconsistency until then.

+user_params=$(echo $(user-params))

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

[PATCH 3/3] Add support for prepending arbitrary u-boot commands to a bootscript

2014-05-29 Thread dann frazier

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

2014-05-29 Thread dann frazier

/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-kernel
 db

[PATCH 0/3] flash-kernel u-boot command/console support

2014-05-29 Thread dann frazier

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 1/3] Generate flash-kernel-installer.postinst based on a template

2014-05-29 Thread dann frazier

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-kernel-installer/prepare
+
+# Stop fsck from prompting the user for

Re: [RFC] flash-kernel hook to prepend to boot script

2014-05-28 Thread dann frazier

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.

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.

Sound reasonable?

-dann

+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

2014-05-27 Thread dann frazier

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.

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.

+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.

[RFC] flash-kernel hook to prepend to boot script

2014-05-21 Thread dann frazier

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

getty and hw flow control

2014-05-12 Thread dann frazier

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: getty and hw flow control

2014-05-12 Thread dann frazier

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

Re: netcfg_1.114_amd64.changes ACCEPTED into unstable

2014-02-13 Thread dann frazier

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 ftpmas...@ftp-master.debian.org (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 debian-boot@lists.debian.org
  Changed-By: dann frazier da...@debian.org
  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

2014-01-03 Thread dann frazier

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://lists.debian.org/debian-boot/2010/09/msg00118.html
 [2]

Re: 6.0.7 planning

2013-02-17 Thread dann frazier

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

2013-02-17 Thread dann frazier

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

2013-02-14 Thread dann frazier

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

2013-02-13 Thread dann frazier

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

2013-02-11 Thread dann frazier

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

2012-10-09 Thread dann frazier

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)

2012-09-24 Thread dann frazier

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)

2012-09-23 Thread dann frazier

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)

2012-09-18 Thread dann frazier

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

2012-05-07 Thread dann frazier

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 da...@debian.org
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 da...@debian.org  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 21  \
type grub-probe /dev/null 21  \
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 21  \
type grub-probe /dev/null 21  \
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

2012-03-28 Thread dann frazier

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 da...@debian.org
---
 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)

2012-03-05 Thread dann frazier

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 
 (URL: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=markuppathrev=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)

2012-02-29 Thread dann frazier

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)

2012-02-27 Thread dann frazier

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

2011-07-05 Thread dann frazier

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

2011-05-24 Thread dann frazier

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

2011-04-11 Thread dann frazier

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#622187: [ia64] CDROM drive not detected

2011-04-10 Thread dann frazier

 
2000-2fff
/proc/iomem: 3fcc0-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 dannf@zx6000.dannf
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

Bug#599417: also affects ia64

2011-04-10 Thread dann frazier

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

Re: Debian installer build: failed or old builds

2011-03-07 Thread dann frazier

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

2011-03-04 Thread dann frazier

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

2010-12-20 Thread dann frazier

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

2010-12-17 Thread dann frazier

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

2010-11-19 Thread dann frazier

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

2010-11-10 Thread dann frazier

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

2010-11-01 Thread dann frazier

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

2010-06-14 Thread dann frazier

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

2010-03-02 Thread dann frazier

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

2010-02-24 Thread dann frazier

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

2010-01-19 Thread dann frazier

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

2010-01-11 Thread dann frazier

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

2009-12-29 Thread dann frazier

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: [(old)stable] D-I kernel updates

2009-12-17 Thread dann frazier

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: [OSRM] D-I kernel updates

2009-12-17 Thread dann frazier

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: Problems with kernel 2.6.26-2-686-bigmem

2009-08-30 Thread dann frazier

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

2009-08-09 Thread dann frazier

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

2009-08-08 Thread dann frazier

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 frazierda...@debian.org 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

2009-07-26 Thread dann frazier

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

2009-06-23 Thread dann frazier

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

2009-06-20 Thread dann frazier

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

2009-06-08 Thread dann frazier

On Sun, Jun 07, 2009 at 03:35:16PM -0300, Otavio Salvador wrote:
 Hello,
 
 On Sat, Jun 6, 2009 at 6:01 AM, Holger Levsenhol...@layer-acht.org 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

2009-05-24 Thread dann frazier

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

2009-03-22 Thread dann frazier

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

linux-2.6 upload planned

2009-01-09 Thread dann frazier

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: linux-2.6 upload planned

2009-01-09 Thread dann frazier

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

Re: linux-2.6 upload planned

2009-01-09 Thread dann frazier

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: Call for testing of RC1 images

2008-11-05 Thread dann frazier

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)

2008-08-26 Thread dann frazier

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

2008-08-25 Thread dann frazier

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

2008-07-30 Thread dann frazier

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: screenshot

2008-07-29 Thread dann frazier

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]

Bug#492899: partman-crypto: cancel button unusable on Erasing data screen

2008-07-29 Thread dann frazier

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: partman-crypto: cancel button unusable on Erasing data screen

2008-07-29 Thread dann frazier

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 some no-op args
  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]

Re: Please review announcement of upcoming release of Debian 4.0r4 etch-and-a-half

2008-07-26 Thread dann frazier

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 @@
 define-tag srcpkga 
href=http://packages.debian.org/src:%0;%0/a/define-tag
 
 pThe Debian project is pleased to announce the fourth update of its
-stable distribution Debian GNU/Linux 4.0 (codename 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 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./p
 
-pPlease 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./p
-
-pThose 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./p
+pExisting 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./p
+
+pThose 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./p
 
 pNew 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./p
+installation media accompanied with the package archive respectively
+will be available soon at the regular locations./p
 
 pUpgrading 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 @@
 
 h2Debian-Installer Update/h2
 
-pThe 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./p
+pThe 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./p
 
 
 h2Miscellaneous Bugfixes/h2
 
-pThis stable update adds several binary updates for various architectures
-to packages whose version was not synchronised across all architectures.
+pThis 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:/p
 
 table border=0


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#490542: k7 transitition

2008-07-16 Thread dann frazier

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=5119933postcount=32

--
dann frazier

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

2.6.24 upload for d-i

2008-05-07 Thread dann frazier

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]

Re: 2.6.24 upload for d-i

2008-05-07 Thread dann frazier

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]

Re: 2.6.24 upload for d-i

2008-05-07 Thread dann frazier

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]

Bug#470707: rx2200?

2008-03-19 Thread dann frazier

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)

2008-02-07 Thread dann frazier

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: Beta1 missing decisions and possible timeline

2008-02-05 Thread dann frazier

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: D-I Etch+1/2 kernel selection (was: Beta1 missing decisions and possible timeline)

2008-02-05 Thread dann frazier

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

2008-01-31 Thread dann frazier

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

2007-12-31 Thread dann frazier

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

2007-12-31 Thread dann frazier

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

2007-12-27 Thread dann frazier

(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]

Bug#454493: Display PCI slot for nics, if available

2007-12-27 Thread dann frazier

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]

Re: etch+1/2 D-I options (was: Meeting for etch and a half)

2007-12-13 Thread dann frazier

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' the user would even still be prompted at lower 
 priorities).

Which would solve the complexity issue I see w/ 3)

 The disadvantages listed for 3) do _not_ apply to CD images as they are 
 self-contained and thus are not affected by changes in the Lenny archive.

Thanks a lot for the analysis.

-- 
dann frazier


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact

Bug#454493: Display PCI slot for nics, if available

2007-12-06 Thread dann frazier

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

2007-12-05 Thread dann frazier

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 21; 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

attachment: nic-slot-info.png

Bug#454493: Display PCI slot for nics, if available

2007-12-05 Thread dann frazier

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:
  dannf willy: is it the case that pci bridges described by ACPI never
  (or not always) appear as pci devices themselves?
  willy 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#453749: Fix serial console detection on ia64

2007-12-03 Thread dann frazier

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: simpler solution

2007-12-03 Thread dann frazier

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: patches

2007-11-30 Thread dann frazier


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 stdio.h
+#include fcntl.h
+#include unistd.h
+#include sys/ioctl.h
+#include linux/serial.h
+
+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

2007-11-30 Thread dann frazier

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/di-pid/fd/0. If a system was booted w/ console=ttyS0,
/proc/di-pid/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/di-pid/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

2007-11-27 Thread dann frazier

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

2007-11-06 Thread dann frazier

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

2007-11-02 Thread dann frazier

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]

Bug#389430: Updated patch; make mirror/udeb/suite support multiple suites

2007-11-02 Thread dann frazier

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]

Re: Meeting for etch and a half

2007-10-31 Thread dann frazier

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]

1 2 3 >

1 - 100 of 227 matches

Mail list logo