partman-efi

[dann frazier]

hey,
  Jim Lieb filed a patch for #257910 which adds the partman-efi package
and adds efi support to partman-auto.  I've tested an image he made
for us, and it worked fine on my system.

  I'd appreciate if someone more partman knowledgable than I could
take a look at the patch; if it looks reasonable to such a person,
I'll be happy to commit these changes and do an upload.

-- 
-------
dann frazier
Hewlett-Packard
Linux and Open Source Lab
[EMAIL PROTECTED]


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

Bug#250028: 2.4 ia64 kernels

[dann frazier]

2.4 ia64 kernels also have CONFIG_IP_PNP turned off.
-- 
---
dann frazier
Hewlett-Packard
Linux and Open Source Lab
[EMAIL PROTECTED]



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

Bug#266213: linux-kernel-di-ia64: udebs available differ between 2.4 & 2.6

[dann frazier]

Package: linux-kernel-di-ia64
Version: 0.54
Severity: important

  I did a d-i build today from svn and the build went fine.  However, when
testing the 2.6 kernel I noticed a couple udebs were missing.
nic-shared-modules-${kernel:Version} and scsi-core-modules-${kernel:Version}
are needed on a 2.6 build; but those udebs don't exist under 2.4.
Can you take a look at this for us?

Reason is, some scsi stuff is linked statically for 2.4, while its modular
under 2.6 - see #236699.

Now - a few possible fixes (in my order of preference)
  1) figure out the proper way to make initrd-tools choose the v2 driver
 and not the v1 driver.  That way, I can make these additional modules,
 and can document the procedure in README.Debian
 (jbailey is the initrd-tools maintainer, he'd make a good starting point)
  2) do two separate package list flavors for ia64
  3) figure out a way to make a single package list work for ia64 - i think
 there was some syntax - starting the line with a '-' or something - that
 let you specify a given udeb as optional

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: ia64
Kernel: Linux 2.6.7-1-mckinley
Locale: LANG=C, LC_CTYPE=C


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

Bug#259296: ia64 menus patch fixes 259296 and 267689

[dann frazier]

On Tue, Aug 24, 2004 at 04:27:50PM -0700, Jim Lieb wrote:
> This patch adds menu support to the CD install for ia64.  It supplies 
> the following:

This patch doesn't apply - it tries to modify build/boot/ia64/elilo-cd.conf,
which doesn't exist - can you double check & post another?




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

[PROPOSAL] 2.4.27 as default 2.4 kernel for sarge

[dann frazier]

  Based on discussions on the debian-kernel list[1], I'd like to propose
that we use 2.4.27 as the 2.4 kernel for all architectures with 2.4 kernels
in sarge.  The strongest arguments for 2.4.27, as opposed to 2.4.26 were noted
by tbm [3].

  All 2.4 architectures have 2.4.27 kernel images built.  alpha, mips
and s390 have 2.4.27 images already in sarge.  hppa, m68k, i386, ia64,
and mips have images available in sid.  arm, powerpc, and sparc have images
awaiting approval in the NEW queue.  

  linux-kernel-di is at 2.4.26 for alpha, sparc, s390, m68k, and i386.  These
packages will need to be updated, and will need to go through the NEW queue.
linux-kernel-di for arm, hppa and powerpc are on 2.4.25, so will also need to
be updated.  ia64, mips and mipsel already have 2.4.27 linux-kernel-di
packages.

  Various tasks are in a hold pattern until this decision is made (ensuring
that d-i uses the proper kernel, removal of other kernel packages from
sarge, rebuilding of some packages to fix build-dep issues[4]), so I'd
like to uncover any problems with this proposal quickly.

[1] http://lists.debian.org/debian-kernel/2004/08/msg00586.html
[2] http://people.debian.org/~dannf/kernel-stats/kernel-avail.html
[3] http://lists.debian.org/debian-kernel/2004/08/msg00632.html
[4] http://people.debian.org/~dannf/kernel-stats/kern-dep.html


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

Bug#259296: ia64 menus patch fixes 259296 and 267689

[dann frazier]

On Thu, Aug 26, 2004 at 09:53:44AM -0700, Jim Lieb wrote:
> Here is a corrected patch.  The CD menu patch was already uploaded so
> please close that bug (#259296) using the previous patch (already 
> committed).
> 
> This patch fixes the usb keyboard issue (#267689).

Committed.  A bug closure is in the changelog.
Thanks!


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

Re: USB support

[dann frazier]

On Sat, Oct 11, 2003 at 03:24:05AM +0200, Peter 'p2' De Schrijver wrote:
> On Fri, Oct 10, 2003 at 09:16:53PM -0400, Joey Hess wrote:
> > Peter 'p2' De Schrijver wrote:
> > > On Fri, Oct 10, 2003 at 09:05:34PM -0400, Joey Hess wrote:
> > > > I've been working on d-i usb support today. Current status is that it
> > > > works (boots) here, and it will work in the archive once we get a new
> > > > busybox and kernel-modules. 
> > > > 
> > > > I have only tested booting from a floppy, as none of the 6 or 10
> > > > computers I have tried can boot direct from a non-floppy usb device[1].
> > > 
> > > What do you exactly mean with a 'non-floppy usb device' ? I have a USB
> > > keychain of 256MB with partitions and 2 machines which boot just fine
> > > from it. They both recognize the keychain as a USB HD and boot from the
> > > active partition using grub.
> > 
> > I have a 128 mb usb keychain that I have never seen boot anywhere. Glad
> > to know someone has one that works, do you know where I can buy your
> > model from?
> 
> I bought mine at a trade show in belgium. So I can't really give you a
> good shop to buy it from. It's marked 'tiny disk'. usbview tells me 
> Manufacturer: Prolific Technology Inc. It came with a 12cm CD containing
> manuals in English and Chinese and some software for windows.
> I also tried a 64MB keychain from a friend which works as well on both
> machines. So I think it's more a question of proper USB support in the
> BIOS.

note that a usb floppy is not usb mass storage - your bios must have
support for usb mass storage to boot from the key chain, and this
is more rare than supporting usb floppy boot.


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

Re: USB support

[dann frazier]

On Fri, Oct 17, 2003 at 11:59:36AM +0200, Wouter Verhelst wrote:
> Op vr 17-10-2003, om 11:02 schreef Peter 'p2' De Schrijver:
> > > > note that a usb floppy is not usb mass storage - your bios must have
> > > > support for usb mass storage to boot from the key chain, and this
> > > > is more rare than supporting usb floppy boot.
> > > 
> > > Most usb floppy disks have support for a legacy mode, in which the USB
> > > and the floppy disk together emulate a 'normal' floppy disk. That
> > > doesn't mean a usb floppy disk isn't a USB mass storage device; at the
> > > very least, it's supported by the usb-storage module under Linux.
> > > 
> > 
> > How does that mode work then ? 
> 
> Dunno. I've had a laptop which came with a USB floppy drive and such
> support; it worked for the floppy drive, but not for a different USB
> mass storage device I borrowed from someone. Not sure what the details
> are.

USB floppies can use CBI mode:
http://www.usb.org/developers/devclass_docs/usb_msc_overview_1.2.pdf

I'd guess that some firmware supports booting w/ CBI, others support
booting with mass storage, and most USB floppies can support both modes
(and isn't mutually exclusive, as I said in my original reply).


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

Bug#218342: palo-installer: Debconf templates polishing

[dann frazier]

On Thu, Nov 13, 2003 at 07:06:01PM +0100, Christian Perrier wrote:
> (Adding Uploaders and last Uploader to CCTollef, I'll stop bugging
> you for other modules.. :-))
> 
> Quoting Christian Perrier ([EMAIL PROTECTED]):
> > Package: palo-installer
> > Severity: normal
> > Tags: patch d-i
> > 
> > See #218273 (lilo-installer) for details
> 
> Are there plans for fixing this bug (thus changing the templates
> accordingly to my  suggestions...ou reject these suggestions)?

is this just waiting for a build/upload?  i'm not working on the port,
but i do have a sid hppa box & can upload.



signature.asc
Description: Digital signature

Bug#224653: di-utils-shell: esc doesn't go back

[dann frazier]

Package: di-utils-shell
Version: 0.38

To reproduce:
  From the main menu, select "Execute a shell"
  Hit  to return to the main menu

This drops me at a shell, instead of returning me to the main menu.

Caveats:
I hit this testing a d-i TYPE=netboot image on ia64 over serial console.
I'm using ESC as my "go back" method, because selecting the ""
menu item doesn't work.


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

Bug#224656: bad tmpfs support detection

[dann frazier]

Package: rootskel
Version: 0.56

In /sbin/init, it attempts to determine whether or not the kernel supports
tmpfs by looking in /proc/filesystems:

#!/bin/sh -e
# Set up filesystem as root and pivot into it.
echo "Setting up filesystem, please wait ..."
umount initrd
mount -t proc proc proc
if grep -q tmpfs /proc/filesystems; then
mount -t tmpfs -o size=100M tmpfs mnt
else
mount -t shm shm mnt
fi

This is a valid way to detect support for most filesystems, but since tmpfs
is used internally by the kernel, it is always present in some form, and always
appears in /proc/filesystems.  This is true even if its configured off (and
therefore not mountable from userspace).

A better way may be to attempt the mount, and if it fails, try the shm mount.


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

Bug#224682: truncated elilo-installer menu entry

[dann frazier]

Package: cdebconf
Version: 0.50

The elilo installer main-menu entry is truncated when displayed.
The text appears as "Install elilo on a hard dis", when it should be
"Install elilo on a hard disk".

I downloaded the elilo-installer udeb, and verified that the text is correct.

[EMAIL PROTECTED]:/tmp$ dpkg -e elilo-installer_0.0.2_ia64.udeb
[EMAIL PROTECTED]:/tmp$ grep -r "Install elilo on a hard" DEBIAN/
DEBIAN/control:Description: Install elilo on a hard disk

I tried modifying the description string of languagechooser to be 28 characters
long to see if there's something magic about that string length, but that text
was displayed in full.

Petter noted on irc that he believed he'd seen this problem before:
 I believe I've seen it with the bokml translation.


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

Bug#148974: discover-data: nic needs old_tulip instead of tulip

[dann frazier]

On Sat, Dec 27, 2003 at 02:31:29PM +0100, Martin Michlmayr wrote:
> For the DECchip 21140 card, discover currently loads the lmc module,
> while the 79c970 card uses the pcnet32 driver.  Can you confirm that
> this works or should the DECchip 21140 use the tulip module?  (Hmm,
> looking at the kernel source tulip might make more sense.)

This was my x86 workstation at work, which I got rid of 6 or so months ago.
Sorry, I'm unable to confirm.

-- 
-------
dann frazier
Hewlett-Packard
Linux and Open Source Lab
[EMAIL PROTECTED]
(970) 898-0800


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

Bug#233295: discover-data: cmd64x device

[dann frazier]

Package: discover-data
Version: 1.2004.02.08-1
Severity: normal

this effects 2.4 & 2.6 kernels.
cmd64x is the module that should be loaded.

[EMAIL PROTECTED]:~$ lspci
00:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 
7000/VE]
80:04.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1010 66MHz  Ultra3 SCSI 
Adapter (rev 01)
a0:01.0 USB Controller: NEC Corporation USB (rev 41)
a0:01.1 USB Controller: NEC Corporation USB (rev 41)
a0:01.2 USB Controller: NEC Corporation USB 2.0 (rev 02)
a0:02.0 IDE interface: CMD Technology Inc PCI0649 (rev 02)  <--- this one
a0:03.0 Ethernet controller: Intel Corp. 82540EM Gigabit Ethernet Controller (rev 02)
a0:04.0 Multimedia audio controller: Fortemedia, Inc Xwave QS3000A [FM801] (rev b2)
a0:04.1 Input device controller: Fortemedia, Inc Xwave QS3000A [FM801 game port] (rev 
b2)
[EMAIL PROTECTED]:~$ lspci -n
00:00.0 Class 0300: 1002:5159
80:04.0 Class 0100: 1000:0021 (rev 01)
a0:01.0 Class 0c03: 1033:0035 (rev 41)
a0:01.1 Class 0c03: 1033:0035 (rev 41)
a0:01.2 Class 0c03: 1033:00e0 (rev 02)
a0:02.0 Class 0101: 1095:0649 (rev 02)  <--- this one
a0:03.0 Class 0200: 8086:100e (rev 02)
a0:04.0 Class 0401: 1319:0801 (rev b2)
a0:04.1 Class 0980: 1319:0802 (rev b2)

--- discover-data-1.2004.02.08/pci.lst~ 2004-02-17 14:42:17.211054882 -0700
+++ discover-data-1.2004.02.08/pci.lst  2004-02-17 14:50:30.771595710 -0700
@@ -1388,7 +1388,7 @@
10950646unknown unknown PCI0646
10950647unknown unknown PCI0647
10950648unknown unknown PCI0648
-   10950649unknown unknown PCI0649
+   10950649ide cmd64x  CMD Technology Inc PCI0649 (rev 02)
10950650unknown unknown PBC0650A
10950670usb usb-ohciUSB0670
10950673usb usb-ohciUSB0673


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: ia64
Kernel: Linux 2.6.2-mckinley
Locale: LANG=C, LC_CTYPE=C

-- no debconf information



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

Bug#259292: debian-installer: IA64 ISOs should behave like EFI boot media

[dann frazier]

Package: debian-installer
Severity: normal

ia64 isos should be bootable via this path from the EFI Boot Manager:
  Boot Option Maintenace Menu
  -> Boot from a File
  -> Debian Inst [Acpi(HWP0002,0)/Pci(2|0)/Ata(Primary,Master)/CDROM(

I believe the magic for this is the bootia64.efi file, which is just a renamed
elilo.efi.  Here's what the boot image on a working CD looks like.

[ You can download a copy of this ISO here (the HP Enablement Kit):
  http://www.hp.com/hps/linux/lx_debian_download.html ]

/efi
/efi/boot
/efi/boot/linux.bin
/efi/boot/root.bin
/efi/boot/elilo.conf
/efi/boot/main.msg
/efi/boot/general.msg
/efi/boot/factory.msg
/efi/boot/golden.msg
/efi/boot/install.msg
/efi/boot/shell.msg
/efi/boot/debian.msg
/efi/boot/bootia64.efi
/elilo.conf
/elilo.efi

>From looking at a SuSE CD, I believe the top level elilo.conf & elilo.efi
files are redundant.  In this example, the linux.bin file and the root.bin
file are the kernel & initrd, respectively.  The elilo.conf looks like this:

# elilo config file for Linux Install & Recovery Kit CD
#
# Copyright (c) 2003 Hewlett-Packard Company
#

chooser=textmenu
delay=20
prompt

message=/efi/boot/main.msg
f1=/efi/boot/general.msg
f2=/efi/boot/factory.msg
f3=/efi/boot/install.msg
f4=/efi/boot/golden.msg
f5=/efi/boot/shell.msg
f6=/efi/boot/debian.msg

image=/efi/boot/linux.bin
label=factory
description="Recover factory pre-configured image"
initrd=/efi/boot/root.bin
root=/dev/ram
append="installtype=FactoryImage raid=noautodetect"

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: ia64
Kernel: Linux 2.6.7-1-itanium-smp
Locale: LANG=C, LC_CTYPE=C


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

Bug#259296: debian-installer: bootmenu screens for ia64

[dann frazier]

Package: debian-installer
Severity: wishlist

elilo, the bootloader for ia64, supports boot menus similar to those
of its isolinux/syslinux counterparts.  it would be nice if we had a
d-i boot screen and help menus similar to those on x86.

for an example implementation, you can checkout the Enablement Kit
iso available here:

  http://www.hp.com/hps/linux/lx_debian_download.html

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: ia64
Kernel: Linux 2.6.7-1-itanium-smp
Locale: LANG=C, LC_CTYPE=C


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

Re: Status of boot-floppies for Debian 3.0r2

[dann frazier]

I have a sparcstation 4 running straight woody that i'd be willing to build
stuff on - i'm afraid i missed some context though - is this 
for a boot-floppies update for woody?

On Thu, Jan 23, 2003 at 06:19:05PM -0600, Adam DiCarlo wrote:
> Eduard Bloch <[EMAIL PROTECTED]> writes:
> 
> >  - help Ben Collins <[EMAIL PROTECTED]> to test the Sparc
> >  boot-floppies
> 
> Hmmm, no SPARC build eh?
> 
> Are there any sparc developers on this list who have access to a SPARC
> box running stable and can help us out by building this?  Please
> follow-up to debian-boot.
> 
> -- 
> ...Adam Di Carlo..<[EMAIL PROTECTED]>...http://www.onshored.com/>
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

-- 

[EMAIL PROTECTED] 


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

Re: Status of boot-floppies for Debian 3.0r2

[dann frazier]

done.
http://people.debian.org/~dannf/boot-floppies/sparc/
let me know if i missed anything.

On Thu, Jan 23, 2003 at 10:37:43PM -0600, Adam DiCarlo wrote:
> dann frazier <[EMAIL PROTECTED]> writes:
> 
> > I have a sparcstation 4 running straight woody that i'd be willing to build
> > stuff on - i'm afraid i missed some context though - is this 
> > for a boot-floppies update for woody?
> 
> Yes, we're trying to get boot-floppies 3.0.24 for Debian 3.0r2.  See 
> http://people.debian.org/~blade/bf3024/ .
> 
> -- 
> ...Adam Di Carlo..<[EMAIL PROTECTED]>...http://www.onshored.com/>
> 

-- 

[EMAIL PROTECTED] 


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

Re: debian-installer - using devfs in the installed system

[dann frazier]

On Fri, Feb 07, 2003 at 01:30:04PM -0700, Bdale Garbee wrote:
> 
> While opinions may vary, I wonder if we're really smart to depend on devfs as
> a kernel feature for the limited use we need to make of it in the install
> process?  Or is there some big win from devfs that I haven't understood yet?

if it is decided to go to devfs, be aware that some devices will require 
special care - specifically, some hardware raid devices.

the cciss & cpqarray drivers (and likely the mylex controllers) have a 
namespace issue that prevents both the devfs name and the standard /dev
entry names to exist simultaneously.

(for example, /dev/cciss/c0d0 vs. /dev/cciss/c0d0/)

d-i can of course work around this, but it would require knowing which type
of /dev the user wants to use in the end.


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

Re: Need any d-i testing on Sparc or oldworld PPC Macs?

[dann frazier]

On Sun, Feb 09, 2003 at 10:51:51PM -0800, [EMAIL PROTECTED] wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> I have an old PowerMac 7500 and a Sparcstation 5 (*sigh* relics from the mid-1990's).
> 
> Is anyone interested in d-i build or install test results on these platforms?
> If so, I'll spend some time on it. Both are currently NetBSD boxes but I need
> to wipe and Debian-ize them soon anyway.

would you be interested in testing the next release of boot-floppies for sparc?
nobody's tested them yet, as far as i know:
  see: http://people.debian.org/~blade/bf3024/


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

Re: Need any d-i testing on Sparc or oldworld PPC Macs?

[dann frazier]

On Mon, Feb 10, 2003 at 08:47:51PM -0800, [EMAIL PROTECTED] wrote:
> Please do!
> 
> The stuff at http://people.debian.org/~blade/bf3024/ looked pretty ready to me, but 
>I'd be glad to wait.
> 
> Thanks.

that's boot-floppies (woody and earlier), and is ready for testing.
Matt is talking about debian-installer (post-woody).  sorry for the confusion.


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

Re: Image file too large for low memory

[dann frazier]

On Tue, Feb 18, 2003 at 08:43:47AM +0100, Emile van Bergen wrote:
> Hi,
> 
> On Tue, Feb 18, 2003 at 02:20:54AM -0500, Owen B. Mehegan wrote:
> 
> > Thanks for the tip. This is what I was afraid of. So where can I GET a
> > bare bones kernel image? I'm poking around on the Debian ftp site but
> > not seeing anything. Do I have to create my own bin file?
> 
> You'd have to compile it yourself, yes.
> 
> I don't know if the PXE standard allows bigger images. I couldn't make
> it out from http://syslinux.zytor.com/pxe.php (PXE boot loader for
> Linux), but with a bit of googling, it should be possible to find out.

pxelinux does let you boot larger images.  i've used it to load the
boot-floppies kernel/initrd before.


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

Re: "No hard drives found" on HP-UX 712/60 (debian_3.0_r0_hppa)

[dann frazier]

On Wed, Mar 19, 2003 at 02:31:35PM -0500, bill hendrickson wrote:
> I'm a regular redhat/ix86 user, and i'm vaguely aware of HP-UX, but i'd 
> like to give debian i try (i hear good things!).
> 
> i have an HP-UX 712/60 that i want to install debian on, b/c linux rox and 
> deb seems to be the best way to get linux on it. I have a Seagate ST345X 
> (4GB) SCSI hard drive and a SCSI Plextor 2x CD-ROM attached to the HP's 
> on-board SCSI controller. The HP originally had a 2GB SCSI hard drive, but 
> i removed it to preserve the HP-UX 10.0 OS. The new 4GB drive is detected, 
> b/c i can see it at boot time from the admin menu, with 'sea'. This command 
> lists both the hard drive and the cdrom. So i 'boot scsi.2.0' to boot off 
> cdrom, and debian install starts cranking. w00t! i get to the point after 
> keyboard config, and it says "no hard drives were detected blah blah blah". 
> wtf? i scoured some debian boards on the net and found a few similar 
> messages. the solutions were to try booting with "vanilla" (no idea what 
> this would do) or "bf24" (which i guess boots the 2.4 kernel which i guess 
> might support my 4GB drive? and why would 2.2 be the default kernel, and 
> not 2.4?). is one of these right for my situation? i'd just try one of 
> these to see if they would work, but i don't know how - how do i call the 
> install w/these parameters? after i do 'boot scsi2.0', the install takes 
> right off.
> 
> can anyone help?

you might try the debian-hppa list.

-- 

[EMAIL PROTECTED] 


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

Re: "No hard drives found" on HP-UX 712/60 (debian_3.0_r0_hppa)

[dann frazier]

On Wed, Mar 19, 2003 at 11:58:44PM -0500, bill hendrickson wrote:
> Thanks for the reply, Thorsten.  your success is encouraging, but i'm still 
> confused about how to boot the bf24 kernel.  is it on the woody cd already?

bf24 isn't relevant for hppa.  the default install kernel for woody/hppa
is a 2.4 kernel.

> is it actually a floppy, b/c i thought debian for hppa did not support 
> booting from floppy.

correct - parisc-linux doesn't support the floppy controller.

-- 

[EMAIL PROTECTED] 


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

Re: elilo & initrd

[dann frazier]

On Mon, Jun 02, 2003 at 01:10:41PM -0700, Usman S. Ansari wrote:
> I have Debian 3.0 installed on IA64 system. I am experimenting with initrd and 
> trying to configure
> elilo to use initrd for booting. So far, I am not not successfull.
> 
> elilo prints a message
> 
> "initrd.c (56) Open file initrd file not found"

is this output from /usr/sbin/elilo, or elilo.efi?
in other words, do you see this at the time of running elilo from within
linux, or before it boots the kernel?

> I have tried various combinations. Still cannot get elilo to find initrd.img
> 
> What is the syntax and other considerations to configure initrd loading.
> 
> I have used initrd with lilo many times and also on this system, I used mkinitrd to 
> create
> initrd.img

mkinitrd on woody is unlikely to do the right thing for ia64.  mkcramfs will
create an initrd that is not mountable by the kernel, because it is using
a page size based on x86.  cramfsprogs in unstable (and probably testing)
does the right thing, though that doesn't mean everything else in mkinitrd
will function correctly.

the debian ia64 kernel packages have most required-to-boot drivers built in
statically - are you sure you need an initrd?

in the future, please consider the debian-ia64 list when asking ia64 specific
questions - the subscribers to that list are more likely to be able to answer
your question.

-- 

[EMAIL PROTECTED] 


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

Re: Repeatable Custom Installation

[dann frazier]

On Tue, Jun 03, 2003 at 07:43:23PM -0700, Chris Tillman wrote:
> 
> Have you looked at fai, replicator, systemimager, and autoinstall?

you can find a tool called mkrecoverycd (or similar) on systemimager.org.
it makes an automated recovery cd from a systemimager image.
should work well w/ 2.0.x, but will need some tweaking for 3.0.x.


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

Re: VIA EPIA C3 install setting?

[dann frazier]

On Tue, Jun 17, 2003 at 08:59:32PM +0800, [EMAIL PROTECTED] wrote:
> Hi,
>   I am having trouble installing from both CD-ROM and DVD-ROM
> using a VIA EPIA motherboard with a C3 CPU. Does anyone have any hints
> as to what the BIOS settings might be needed? I have two different
> install media and two different CD readers. All combinations give
> intermittent results that stop near the format hard drive section. 

i have a via epia, and i recall needing the CONFIG_BLK_DEV_VIA82CXXX option
turned on in my kernel.  i also recall that this option wasn't available until
late in the 2.4 kernel stream.  you might confirm that this is turned on in
your boot kernel.  the config for a debian boot kernel is usually easy to find
on the boot media.


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

Re: Visualize EG card on HP PA-RISC C360

[dann frazier]

On Tue, Jun 17, 2003 at 04:22:19PM +0200, Zlatan Jukic wrote:
>  
> 
> Hello all,
> 
>  
> 
> I installed recently Debian Linux 3,0 on our machine HP PA-RISC for C360.  
> 
> I could not start unfortunately the X-Windows system, because it is not
> supported by Fx-4 video card.?!
> 
>  
> 
> My question is here:  Must I insert another card (and which??),  in order to
> start X-Windows-system?
> 
>  
> 
> According to Debian HPPA, the Visualize EG should correct to function.  
> 
> This card is a 24-bit-video-card, which is recognized in the best way under
> Linux as "Coral" with HP 715-64, 
> 
> in the C360 it is not recognized (problems with the GSC bus!?).
> 
>  
> 
> The question is whether this card can be supported from the HP Visualize
> PA-RISC C360 hardware and from Linux Debian 3,0?
> 
>  
> 
> On the other hand, I have experienced that it is a problem of the Linux-
> (Debian) operating-system!?  
> 
>  
> 
> If can me help a Visualize EG-card i would order it gladly! 
> 
>  
> 
> Thanks for all your assistance,
> 
> kind regards, Zlatan

a better forum for your questions would be either the
debian-hppa list, or [EMAIL PROTECTED] (the latter is
probably the best).


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

Re: modprobe: Can't locate module char-major-60 (server hangs!)

[dann frazier]

On Sun, Jun 29, 2003 at 10:26:38PM +0300, Dub wrote:
> Sorry if you got this for the second time. I neither  received it back nor it
> appeared in archive. :-(
> 
> Dub

you should probably try either the [EMAIL PROTECTED] list
or the [EMAIL PROTECTED] list.


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

Re: sarge and sid issues with VFS: Cannot open root device - catch 22

[dann frazier]

On Wed, Jul 09, 2003 at 01:26:38PM +0200, Kurt Bernhard Pruenner wrote:
> How about building your own 2.4.21 kernel? It ships with Intel's e1000
> driver included, so you could even compile the driver right into the
> kernel.

so did 2.4.20, i believe.


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

Re: Persistant issue with 2.4.20 kernel - VFS: Cannot open root device

[dann frazier]

On Sat, Jul 12, 2003 at 11:02:25PM +0200, Eric Smith wrote:
> fs is ext2.
> Now why does the newer kernel not see the root fs?
> Has it to with the proc fs not being mounted or
> some required modules not being loaded.  I am not sure if the modules
> in /etc/modules get loaded before the panic seen below.
> Wish there was more debug info.

the first root fs it will look for, w/ a debian 2.4 kernel, is the initrd.
are you sure you're loading one?  when you install a 2.4 kernel, it gives
you instructions on how to do this.

modules from /etc/modules aren't loaded until later - the root filesystem
has to be mounted before this file can be accessed.


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

Bug#201161: busybox-cvs: FTBFS on ia64

[dann frazier]

Package: busybox-cvs
Version: 0.60.99.cvs20030426-9
Severity: serious
Justification: no longer builds from source

busybox-cvs no longer builds from source on ia64.
a full buildd log of the failure can be found here:
  
http://buildd.debian.org/fetch.php?&pkg=busybox-cvs&ver=0.60.99.cvs20030426-9&arch=ia64&stamp=1058072990&file=log&as=raw

here's a snippet from the log at the time of the failure:

gcc -I./include -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Wall 
-Wstrict-prototypes -Wshadow -Os -fomit-frame-pointer -D_BSD_SOURCE -DNDEBUG
-D_GNU_SOURCE -I./modutils/obj/  -c -o networking/libiproute/ll_map.o 
networking/libiproute/ll_map.c
gcc -I./include -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Wall 
-Wstrict-prototypes -Wshadow -Os -fomit-frame-pointer -D_BSD_SOURCE -DNDEBUG
-D_GNU_SOURCE -I./modutils/obj/  -c -o networking/libiproute/ll_proto.o 
networking/libiproute/ll_proto.c
In file included from /usr/include/asm/system.h:19,
 from /usr/include/asm/atomic.h:17,
 from /usr/include/linux/netdevice.h:32,
 from /usr/include/linux/if_arp.h:26,
 from networking/libiproute/ll_proto.c:16:
/usr/include/asm/pal.h:89: error: syntax error before "pal_status_t"
/usr/include/asm/pal.h:102: error: syntax error before "pal_cache_level_t"
/usr/include/asm/pal.h:110: error: syntax error before "pal_cache_type_t"
/usr/include/asm/pal.h:123: error: syntax error before "pal_cache_line_state_t"
/usr/include/asm/pal.h:130: error: syntax error before "u64"
...

-- System Information:
Debian Release: testing/unstable
Architecture: ia64
Kernel: Linux krebs 2.4.20-mckinley #1 Tue Jun 10 14:22:56 MDT 2003 ia64
Locale: LANG=C, LC_CTYPE=C

Versions of packages busybox-cvs depends on:
ii  libc6.1   2.3.1-17   GNU C Library: Shared libraries an

-- no debconf information



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

Bug#201161: busybox-cvs: FTBFS on ia64

[dann frazier]

On Mon, Jul 14, 2003 at 04:49:20PM +0200, Matt Kraai wrote:
> This is caused by bug #191114.  busybox-cvs will build once
> libc6-dev is rebuilt for ia64 with kernel-headers-2.4.20-ia64
> 021210.em18.3 or later.

i rebuilt glibc on my system w/ kernel-headers-2.4.20-ia64 installed and
my busybox-cvs build did continue passed this point.  however, it hit another
problem before completing:


gcc -I./include -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Wall 
-Wstrict-prototypes -Wshadow -Os -fomit-frame-pointer -D_BSD_SOURCE -DNDEBUG
-D_GNU_SOURCE -I./modutils/obj/  -c -o util-linux/fdflush.o util-linux/fdflush.c
gcc -I./include -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Wall 
-Wstrict-prototypes -Wshadow -Os -fomit-frame-pointer -D_BSD_SOURCE -DNDEBUG
-D_GNU_SOURCE -I./modutils/obj/  -c -o util-linux/fdisk.o util-linux/fdisk.c
util-linux/fdisk.c:860: warning: declaration of `fd' shadows a global declaration
util-linux/fdisk.c:214: warning: shadowed declaration is here
util-linux/fdisk.c: In function `_llseek':
util-linux/fdisk.c:862: error: `__NR__llseek' undeclared (first use in this function)
util-linux/fdisk.c:862: error: (Each undeclared identifier is reported only 
onceutil-linux/fdisk.c:862: error: for each function it appears in.)
make[1]: *** [util-linux/fdisk.o] Error 1
make[1]: Leaving directory `/tmp/busybox-cvs-0.60.99.cvs20030426'
make: *** [build-arch-static-stamp] Error 2

-- 
-------
dann frazier
Hewlett-Packard
Linux and Open Source Lab
[EMAIL PROTECTED]
(970) 898-0800


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

Bug#201161: busybox-cvs: FTBFS on ia64

[dann frazier]

On Mon, Jul 14, 2003 at 10:28:54PM +0200, Matt Kraai wrote:
> This has been fixed upstream with the following patch.
> 
> Would you care to test it?

thanks Matt.  the patch didn't apply cleanly, and what needed to be changed
wasn't obvious.  however, i did a co of the busybox module & built a deb
from it using the packaging goo from the package in unstable.  i interactively
took the defaults for new config options, and can report that the deb built
fine on ia64 w/ the rebuilt libc6.1-dev.  

i'm guessing this is a more relevant test than just the patch anyway, since i'd
guess that the next functional release of busybox-cvs will likely be a new
snapshot, not a patched version of the old snapshot.  if that's not the case,
i'll happily test another version of the patch.

-- 
---
dann frazier
Hewlett-Packard
Linux and Open Source Lab
[EMAIL PROTECTED]
(970) 898-0800


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

Bug#201161: busybox-cvs: FTBFS on ia64

[dann frazier]

On Wed, Jul 16, 2003 at 10:29:26AM +0200, Matt Kraai wrote:
> Thanks for testing.  In case the maintainer doesn't want to use a
> new snapshot, would you please test the following, backported
> patch?

it built to completion - thanks!

-- 
-------
dann frazier
Hewlett-Packard
Linux and Open Source Lab
[EMAIL PROTECTED]
(970) 898-0800


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

Re: Bug#186331: raising severity; was: busybox FTBTS problems

[dann frazier]

On Sun, Aug 03, 2003 at 10:44:23AM +0100, Alastair McKinstry wrote:
> The adjtimex bug has been assigned to libc6 already, with a note that
> its now severity serious as it breaks d-i.  I'm proposing to do binary
> NMUs for alpha, ia64 busybox-cvs : hence I'm CC'ing all the uploaders
> for busybox CVS (its maintainer is set to debian-boot). 
> Any objections?

getting ia64 building needs more than just a rebuild against the newer
libc6.1-dev - it needs source changes too.

see #201161.


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

Re: Boot failure after install (continuous 01 01 01...)

[dann frazier]

On Thu, Aug 28, 2003 at 08:01:55AM -0700, Matt Kraai wrote:
> [Please preserve the list CC.]
> 
> On Thu, Aug 28, 2003 at 04:45:06PM +0200, Ferry van Genderen wrote:
> > thank you for your quick response! I suspect that grub is also a 'boot 
> > manager', is it included on the Debian cd? if so, do you know how I can 
> > install it?
> 
> Yes, grub is an alternative boot loader for i386.
> 
> > Can it be done in the installer, or do I have to make a boot floppy and 
> > than reboot and perform some action?
> 
> You'll need to boot from the floppy you created during
> installation or the rescue disk and install the grub package.

fyi, someone posted a good grub on debian howto on debianplanet a while back:
  http://debianplanet.org/node.php?id=840


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

Re: ia64 testers wanted for sarge cds

[dann frazier]

On Mon, Oct 06, 2003 at 03:31:44PM -0600, Khalid Aziz wrote:
> 2. "Detect CDROM" results in 
> 
> Unable to load module 'ide-probe-mod' for 'Linux IDE probe
> Driver'.

see:
  http://www.debian.org/devel/debian-installer/ports-status

This is one of the things for which Richard has a local fix.


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

Re: initrd, herbert xu's cramfs patch, custom debian kernel packages

[dann frazier]

On Wed, Oct 08, 2003 at 06:30:16PM +0200, Martin List-Petersen wrote:
> Hi,
> 
> Is Herbert Xu's cramfs patch still needed today, to get make-kpkg
> --initrd to work with a plain vanilla kernel ?
> 
> If yes, where to obtain the patch, w/o the need of using a Debian
> supplied kernel-source package ?

i extracted the relevant patch once upon a time for systemimager (based
on 2.4.20).  sf's cvs web interface appears to be down, but you can look
in the systemimager/patches directory of the cvs tree at
http://sf.net/projects/systemimager, or apt-get source it from sid.


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

Re: [PROPOSAL] 2.4.27 as default 2.4 kernel for sarge

[dann frazier]

On Fri, Aug 27, 2004 at 10:58:06PM +0200, Norbert Tretkowski wrote:
> There was no final decision if we ship 2.4.27 with sarge.

I wonder what needs to happen to have a formal d-k decision.
Do other subgroups of Debian have a mechanism for this?  Maybe we
need a designated person or persons who can speak for each arch.
(Please only reply to debian-kernel on this topic).

> If you now build and upload linux-kernel-di-alpha 0.62 with 2.4.27,
> you have to build 0.63 that downgrades linux-kernel-di-alpha back to
> 2.4.26 if we don't use 2.4.27 for sarge. 0.61 can't be used for sarge
> because it was built with kernel-source-2.4.26 2.4.26-2.1 which has
> some security problems which were fixed later.

The only thing questionable about it, afaict, is the ide dma issue[1], which
appears to have been a problem with our patch set[2], so should be resolvable.

[1] http://lists.debian.org/debian-kernel/2004/08/msg00790.html
[2] http://lists.debian.org/debian-kernel/2004/08/msg00880.html


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

Bug#270934: elilo-installer: fails to create efi boot manager entry

[dann frazier]

Package: elilo-installer
Version: 0.0.6
Severity: important

To reproduce:
1) use 20040901 netboot w/ append='debconf/priority=medium'
2) remove any Debian entries from the efi boot menu
3) start install using 2.6 flavor
4) choose sid as the distribution
5) after downloading installer components & before installing base,
   drop to a shell and run:
   # cd /usr/lib/debootstrap/scripts
   # sed 's/efibootmgr/pciutils efibootmgr/' < sid > sid.tmp
   # mv sid.tmp sid
   this works around #268490 & #270135 (which should be unrelated)
6) complete the install
7) reboot

you should see no efi boot manager entry for Debian


-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: ia64
Kernel: Linux 2.6.7-1-mckinley
Locale: LANG=C, LC_CTYPE=C


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

Bug#270934: works w/ 2.4

[dann frazier]

w/ a 2.4.27 based d-i, a boot manager entry is properly created.
efibootmgr uses /proc/efivars in 2.4 but uses /sys in 2.6, so this
could be the relevant difference.

-- 
---
dann frazier
Hewlett-Packard
Linux and Open Source Lab
[EMAIL PROTECTED]



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

Bug#270936: [ia64][20040901][netinst] various issues

[dann frazier]

Package: installation-reports
Severity: normal

Forwarding on an installation report from a coworker.

> netboot package built 20040901
> selected "Install with Linux 2.6", add'l argument debconf/priority=medium
> 
> * Incorrect default keymap:
> 
> Selected "English"
> Selected "United States"
> Default keymap is "European"; should be "American English"
> 
> * No error message for incorrect manual http mirror specification
> 
> Choose a Debian mirror, enter "http://foo"; as the mirror hostname
> No error message; you're just asked again for the mirror information
> 
> * base-config error
> 
> Need to manually add "pciutils" to /usr/lib/debootstrap/sid
this is #268490

> * No EFI Boot Manager entry installed
this is #270934

> * After reboot, select "Desktop environment" to install, doesn't work
> 

-- 
---
dann frazier
Hewlett-Packard
Linux and Open Source Lab
[EMAIL PROTECTED]



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

Bug#270936: update

[dann frazier]

I reproduced the "Desktop enviornment" failure - this quickly flashed across
my screen:

The following packages have unmet dependencies:
  kde: Depends: kdemultimedia but it is not installable
tasksel: aptitude failed

I believe this is due to #270502.

-- 
---
dann frazier
Hewlett-Packard
Linux and Open Source Lab
[EMAIL PROTECTED]



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

Re: archdetect guessing on arm* != armel

[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:/

Re: netcfg_1.114_amd64.changes ACCEPTED into unstable

[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  (2013-12-12):
> > 
> > 
> > Accepted:
> > 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> > 
> > Format: 1.8
> > Date: Thu, 12 Dec 2013 15:02:28 -0700
> > Source: netcfg
> > Binary: netcfg netcfg-static
> > Architecture: source amd64
> > Version: 1.114
> > Distribution: unstable
> > Urgency: low
> > Maintainer: Debian Install System Team 
> > Changed-By: dann frazier 
> > Description: 
> >  netcfg - Configure the network (udeb)
> >  netcfg-static - Configure a static network (udeb)
> > Changes: 
> >  netcfg (1.114) unstable; urgency=low
> >  .
> >* Make netcfg Arch: any again. This reverts a change made in version
> >  0.23 over a decade ago, intended to omit s390, which apparently
> >  is no longer needed.
> > Checksums-Sha1: 
> >  04ee740d9d9a0590f250f6a4255cac8eace6fcf4 1876 netcfg_1.114.dsc
> >  4cac0a8105bc51f2922756fe6fb4e9aa6c5f4cb5 770397 netcfg_1.114.tar.gz
> >  72a9ed1717f1b06a6d26a1c1d56b5403930b1e7f 433326 netcfg_1.114_amd64.udeb
> >  b5433b21e0be5af92d3da654d8e55498347c3db5 339388 
> > netcfg-static_1.114_amd64.udeb
> > Checksums-Sha256: 
> >  7b75798bdad8434b6694b5ddd246409864e47c52e6e3c3ec53043d45570feea9 1876 
> > netcfg_1.114.dsc
> >  8e65876f98031f2432d6127cfa6d7b4075fe99901b7a321da3ca7361ce43caca 770397 
> > netcfg_1.114.tar.gz
> >  b8e4984f3e6f4a4afe044d4919f5d01e566445428ad062638751be5b7ba7d676 433326 
> > netcfg_1.114_amd64.udeb
> >  b238967fabf854f23734e8022ab710bb31b38766d0346d9696fe7a22f93ec91d 339388 
> > netcfg-static_1.114_amd64.udeb
> > Files: 
> >  87b0e3a505b5cac73a9b6711f25e8c09 1876 debian-installer optional 
> > netcfg_1.114.dsc
> >  67da485846e7e48005b218aa2ca8e0a0 770397 debian-installer optional 
> > netcfg_1.114.tar.gz
> >  577badb83154aee0f575a015605694be 433326 debian-installer optional 
> > netcfg_1.114_amd64.udeb
> >  2252448a52864e6f1cdd28cee5616264 339388 debian-installer optional 
> > netcfg-static_1.114_amd64.udeb
> > 
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v1.4.15 (GNU/Linux)
> > 
> > iQIcBAEBAgAGBQJSqjMkAAoJEBv4PF5U/IZAFLIP/16FccHr1fOTue/n6I3P/das
> > yj+dRfoZHCVPGAQc3r2/qApJLi2oOCqYQdYL8E++J/ct3Vz1jNRhIdG1DzX4gxc1
> > LAa/BuV3W4YUlPRJ873T8dCXBFwpmBznsUlX1hFetrZE9GoXtXDXmi+5IMYNSQmL
> > Z62ASyFAh267AzAlx7VgVrVgzBkvmoPIXMcftD+NGyntxAuTwThaTqv4ebtPStaK
> > j0mq85UHQeJARr+Wzj+uxh0VZV1u9+KVGSR2ybCq2h70qK14qV/39NrLJKNbvE+u
> > c6c15C0XPkb5d3TI/nIYScWne0zfSqUjr+fJQ7LGj5ltxkUx1ycXTehreylgU1hi
> > 2aAA0HV2QE3qr1sFkM6WQSJ3sL9ZBcbxZ4c8oEW3biEa6F8ag4Zdd5HHfBuOZjXF
> > R+8f4KhFEO2V+YLbcE5OE3LECCeLCIKr/lyz/ZOrBOC9fqHC7dwzQNJuYQ6x0k6L
> > jBF+lC2vOyXtuBZqEAUOdv9K6Eiv/dDlUKPttREpxDDDkBzEeLc2E9XC93nrdQGm
> > cgB9kkU9STJMzCZdm2zKcISPxim7I3nKhzJ6N2nfSV1iJCUdnRSA9uBZJZOEB5KF
> > /uktmUCvMxUQ4aYzubCbgu80aEbHV2GH3SH3mxmlVSegRlzvphWl6YGkFgCI8vF7
> > QuZcEeOHuMPOKve7nqAS
> > =1XpT
> > -END PGP SIGNATURE-
> > 
> > 
> > Thank you for your contribution to Debian.
> > 
> > 
> Mraw,
> KiBi.



-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140213194027.GB11384@fluid.dannf

getty and hw flow control

[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

[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

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

[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

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

[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. 
> > 
> >  B) The ability to let a package change settings in the u-boot
> > environment. We have a case where a u-boot envvar setting
> > needs to differ depending on whether or not certain software
> > will be used (their u-boot has special code that reconfigures
> > the hardware depending on the setting of this variable).
> > 
> > The systems we're dealing with use a boot.scr script generated by
> > flash-kernel. So, we figure we could solve both by letting packages
> > drop in u-boot code snippets that will be prepended to the
> > boot.scr. To do this, we propose a scheme similar to initramfs-tools
> > where packages can drop snippets in a path under /usr/share (solving
> > B), and users can add their own new setings or override the /usr/share
> > versions by dropping snippets under /etc. With this scheme in place,
> > flash-kernel-installer could be extended to drop in a file in /etc
> > that does a 'setenv bootargs $userargs' to solve (A). Comments?
> 
> I think snippets like this are a useful idea in general, but I wonder if
> something like the command line isn't deserving of "higher billing",
> e.g. via a setting in /etc/defaults/flash-kernel:COMMAND_LINE?

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

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

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

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

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

> > +user_params="$(echo $(user-params))"
> 
> What does this contain in practice? Just the post "--" stuff given to
> the installer or also the generated root= stuff etc?

Just the post "--" stuff. It also works with preseeding
(debian-installer/add-kernel-opts).

> How does this interact with the Bootloader-Sets-Incorrect-Root setting?
> Should it consume the same settings somehow (assuming root= is involved
> here at all)?

It looks like that logic is all in an initramfs hook, so there should
be no interaction there.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140527163518.GA4756@fluid.dannf

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

[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. 
> > > 
> > >  B) The ability to let a package change settings in the u-boot
> > > environment. We have a case where a u-boot envvar setting
> > > needs to differ depending on whether or not certain software
> > > will be used (their u-boot has special code that reconfigures
> > > the hardware depending on the setting of this variable).
> > > 
> > > The systems we're dealing with use a boot.scr script generated by
> > > flash-kernel. So, we figure we could solve both by letting packages
> > > drop in u-boot code snippets that will be prepended to the
> > > boot.scr. To do this, we propose a scheme similar to initramfs-tools
> > > where packages can drop snippets in a path under /usr/share (solving
> > > B), and users can add their own new setings or override the /usr/share
> > > versions by dropping snippets under /etc. With this scheme in place,
> > > flash-kernel-installer could be extended to drop in a file in /etc
> > > that does a 'setenv bootargs $userargs' to solve (A). Comments?
> > 
> > I think snippets like this are a useful idea in general, but I wonder if
> > something like the command line isn't deserving of "higher billing",
> > e.g. via a setting in /etc/defaults/flash-kernel:COMMAND_LINE?
> 
> It looks like Ubuntu is carrying a patch that does this today:
> 
>   
> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/utopic/flash-kernel/utopic/revision/443.2.7
> 
> There the the variable is called "UBOOT_DEFAULTS". I think
> "KERNEL_CMDLINE" would be a more obvious name, but it would also be
> nice to be reducing their diff.

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

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

Sound reasonable?

  -dann

> > FWIW latest Debian flash-kernel supports substituting @@KERNEL_VERSION@@
> > in the boot.scr with the actual kernel version in use. We could follow a
> > similar path for command line args (e.g. if you agree /e/d/flash-kernel
> > is a good place for this setting).
> 
> Yeah, that makes sense. For non-cmdline options, should we make that a
> substitution as well (e.g. @@UBOOT_ENV_EXTRA@@), or automatically prepend
> the snippets for every boot.scr? The former might be nice if we want
> to transition platforms over individually as we can test them. But,
> the downside is inconsistency until then.
>
> > > +user_params="$(echo $(user-params))"
> > 
> > What does this contain in practice? Just the post "--" stuff given to
> > the installer or also the generated root= stuff etc?
> 
> Just the post "--" stuff. It also works with preseeding
> (debian-installer/add-kernel-opts).
> 
> > How does this interact with the Bootloader-Sets-Incorrect-Root setting?
> > Should it consume the same settings somehow (assuming root= is involved
> > here at all)?
> 
> It looks like that logic is all in an initramfs hook, so there should
> be no interaction there.
> 
> 


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140528223053.GC5663@fluid.dannf

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

[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

[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-k

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

[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

[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-k

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

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

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

[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 arm

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

[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.
> > > > > 
> > > > >  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
> > &

Bug#831003: support gzip'd kernel image

[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   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#776488: regression: arm map_hardware[] not NULL terminated

[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

Bug#776488: regression: arm map_hardware[] not NULL terminated

[dann frazier]

On Wed, Jan 28, 2015 at 06:10:49PM +0100, Cyril Brulebois wrote:
> dann frazier  (2015-01-28):
> > Package: libdebian-installer4
> > Version: 0.98
> > Severity: serious
> > Tags: d-i patch
> > 
> > The map_hardware[] table in src/system/subarch-arm-linux.c is no longer NULL
> > terminated. I believe this could lead to a segfault on armel/armhf 
> > platforms,
> > resulting in a failed install.
> > 
> > This bug was introduced back in version 0.92. The end of the table was 
> > trimmed,
> > and accidentally took the NULL terminator with it:
> >   
> > http://anonscm.debian.org/cgit/d-i/libdebian-installer.git/commit/?id=3a7209e49fa5cfe8c4e4122325405022031a8afc
> >   
> > DISCLAIMER: I haven't actually observed a crash, I just discovered this 
> > while
> > reviewing source. But it does seem like a potential time-bomb we should fix
> > pre-release. Here's the obvious patch:
> > 
> > diff --git a/src/system/subarch-arm-linux.c b/src/system/subarch-arm-linux.c
> > index 590576a..3fc5e2a 100644
> > --- a/src/system/subarch-arm-linux.c
> > +++ b/src/system/subarch-arm-linux.c
> > @@ -103,6 +103,7 @@ static struct map map_hardware[] = {
> >  { "OMAP3 Beagle Board", "omap" },
> >  { "OMAP4 Panda Board", "omap" },
> >  { "ARM-Versatile Express", "vexpress" },
> > +{ NULL, NULL }
> >  };
> 
> I was about to push it but you apparently already did; adjusting tags
> accordingly.

Cool, thanks :) Do you +1 me uploading this? If so, should I request an
unblock or does that need to come from you?


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150128171615.GD15696@fluid.dannf

Re: libdebian-installer_0.99_source.changes ACCEPTED into unstable

[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

Re: libdebian-installer_0.99_source.changes ACCEPTED into unstable

[dann frazier]

On Fri, Jan 30, 2015 at 07:15:32AM +0100, Cyril Brulebois wrote:
> Christian PERRIER  (2015-01-30):
> > Quoting dann frazier (da...@dannf.org):
> > > On Thu, Jan 29, 2015 at 07:01:32AM +0100, Christian PERRIER wrote:
> > > > Unless I'm wrong, the released changelog hasn't been pushed in git nor
> > > > has the 0.99 released been tagged.
> > > 
> > > I did push it - and I do see the tag:
> > >   http://anonscm.debian.org/cgit/d-i/libdebian-installer.git/
> > > 
> > > But perhaps I did something incorrectly? Did you expect to see it on
> > > the jessie branch? That branch looked pretty out of date, so I just
> > > pushed to master.
> > 
> > ...which is fine...but I don't see anything on my local copies, even
> > after a "git pull".
> > 
> > May anyone else confirm (KiBi?) so that I know if that's a problem
> > only on my side?
> 
> master wasn't pushed to the repository, meaning that the (pushed) 0.99
> tag isn't reachable by any of the branches you're fetching from the
> repository. That explains why you're not seeing an updated master *and*
> the (pushed) 0.99 tag. dann's pushing his local master branch should fix
> both issues.

Ah, I see. Pushed now - thanks for explaining!


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150130161455.GA32435@fluid.dannf

Bug#776782: x86/mac: false warning about being in EFI mode

[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 2>&1 || true
 
-if [ -d /proc/efi ] || [ -d /sys/firmware/efi ]; then
+in_efi_mode() {
+[ -d /proc/efi ] || [ -d /sys/firmware/efi ]
+}
+
+if in_efi_mode; then
> /var/lib/partman/efi
 else
case $ARCH in
@@ -86,7 +90,7 @@ done
 
 log "Found $NUM_ESP ESPs, $NUM_NO non-ESPs"
 
-if [ $NUM_ESP = 0 ] && [ $NUM_NO -gt 0 ]; then
+if in_efi_mode && [ $NUM_ESP = 0 ] && [ $NUM_NO -gt 0 ]; then
case $ARCH in
i386/*|amd64/*)
db_input critical partman-efi/non_efi_system || true




-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150201171327.24292.29007.reportbug@fluid.dannf

Re: Default disk partition table type?

[dann frazier]

On Tue, Dec 17, 2002 at 09:21:55AM -0500, Michael Stone wrote:
> On Wed, Dec 11, 2002 at 04:59:24PM -0700, Bdale Garbee wrote:
> >No.  Any new ia64 installation should use GPT, not FAT-style MSDOS labels.
> 
> Are those the ones that put stuff at the end of the disk and break on
> linux with odd number of sectors?

you speak of the same.
the ia64 debian kernel has a patch that adds an ioctl for accessing this
last sector.

> Mike Stone



-- 

[EMAIL PROTECTED] 


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

2.6.24 upload for d-i

[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

[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

[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#490542: k7 transitition

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


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

[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 @@
 http://packages.debian.org/src:%0";>%0
 
 The Debian project is pleased to announce the fourth update of its
-stable distribution Debian GNU/Linux 4.0 (codename ).  This update
-not only adds corrections for security problems and a few adjustment to serious
-problems to a stable release, it also adds support for newer hardware by giving
+stable distribution Debian GNU/Linux 4.0 (codename ).  In addition
+to correcting several security problems and a few serious defects in the
+stable release, this update also adds support for newer hardware by giving
 users the option to install newer drivers.
 
-Please note that this update does not constitute a new version of Debian
-GNU/Linux 4.0 but only updates some of the packages included.  Even if you need
-new drivers during installation time there is no need to throw away 4.0 CDs or
-DVDs. If you do not need newer drivers you will only need to update against a
-Debian mirror after an installation in order to incorporate these late
-changes.
-
-Those who frequently install updates from security.debian.org will not have
-to update many packages as most updates from security.debian.org are included
-in this update.
+Existing Debian GNU/Linux 4.0 installation CDs and DVDs can continue to be
+used to install this update. After installation, upgrading via an up-to-date
+Debian mirror will cause any out of date packages to be updated. However, users
+of the network-console installation method are strongly encouraged to update
+their media, see the "Debian Installer" portion of this announcment for
+more information.
+
+Those who frequently install updates from security.debian.org won't have
+to update many packages and most updates from security.debian.org are
+included in this update.
 
 New CD and DVD images containing updated packages and the regular
-installation media accompanied with the package archive will be available
-soon at the regular locations.
+installation media accompanied with the package archive respectively
+will be available soon at the regular locations.
 
 Upgrading to this revision online is usually done by pointing the
 aptitude (or apt) package tool (see the sources.list(5) manual page) to
@@ -91,16 +91,17 @@
 
 Debian-Installer Update
 
-The Debian-Installer was also updated due to changes regarding the creation
-of SSL certificates used during installation via the network-console. Two other
-issues regarding installation on existing RAID setups and recognizing PowerPC64
-systems have also been fixed.
+The Debian-Installer was updated to repair an issue with the network-console
+installation option. Due to a lack of entropy in how the host key is generated,
+earlier Debian GNU/Linux 4.0 installers are vulnerable to a man-in-the-middle
+attack. Two other issues regarding installation on already existing RAID
+setups and recognizing PowerPC64 system have been fixed as well.
 
 
 Miscellaneous Bugfixes
 
-This stable update adds several binary updates for various architectures
-to packages whose version was not synchronised across all architectures.
+This stable update adds several updates to packages for various
+architectures whose version was not synchronised across all architectures.
 It also adds a few important corrections to the following packages:
 
 


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

Bug#492899: screenshot

[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

[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

[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 
  if [ $? -eq 30 ]; then
 kill $pid
 echo somestring-to-advance-progress > $fifo
  fi
  } &
  watcherpid=$!

  [existing while loop that reads fifo]
  kill $watcherpid
  [...]
}

  

-- 
dann frazier




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

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

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

Re: Newest powerpc install disks not booting

[dann frazier]

On Thu, Dec 14, 2006 at 10:06:52PM +0100, Holger Levsen wrote:
> Hi Dann,
> 
> we used to have miboot-floppies for sarge/powerpc somewhere on 
> people.debian.org/~luther/ but it seems they are gone. Since these floppies 
> in etch are also sometimes not working and older hardware might not be 
> supported by newer kernels, too - it would be very good to have them again.
> 
> Did you do the sarge 3.1r4 rebuild of d-i for powerpc? Or do you know who did?

It looks like this was autobuilt:
  
http://buildd.debian.org/fetch.cgi?&pkg=debian-installer&ver=20050317sarge1&arch=powerpc&stamp=1154814507&file=log

> I'm asking you to do this, because I guess you have everything set up and 
> just 
> need to install miboot and repeat the build. (To use the same chroot again 
> for official builds, you obviously need to remove the miboot package again.)

Frans: can we update debian-installer on a single arch, perhaps via
binNMU, like this?

-- 
dann frazier


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

Re: Scheduling linux-2.6 2.6.18-9

[dann frazier]

On Fri, Dec 15, 2006 at 06:19:13PM +0100, maximilian attems wrote:
> On Fri, Dec 15, 2006 at 06:08:08PM +0100, Frederik Schueler wrote:
> > 
> > If you have any last minute changes which are that important they cannot 
> > wait for the first point release kernel, please list them here so we can
> > discuss them.
>  
> - 2.6.16.X backports that are missing in 2.6.18.
> - latest 2.6.18 breaks swsusp on x41 (not critical but bad)
> - there are lots of unreviewed/unresponded bug reports against 2.6.18
>   might need more team engangement on that front

And I'm expecting a patch to fix cciss for external devices in the
next couple days (maintainer is testing it now).

-- 
dann frazier


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

RFC: warn user about first accounts privs

[dann frazier]

I'm not sure what changes are considered acceptable at this point in
d-i, but I wanted to float this one. I discovered while researching
#404927 that the first user added at install time is also added to
various system groups. Though I think its reasonable, I personally did
not expect it and thought a warning was in order.

Please let me know if this is a reasonable thing to commit.

Index: debian/user-setup-udeb.templates
===
--- debian/user-setup-udeb.templates(revision 44108)
+++ debian/user-setup-udeb.templates(working copy)
@@ -52,7 +52,11 @@
  result in disaster. You should create a normal user account to use for
  those day-to-day tasks.
  .
- Note that you may create it later (as well as any additional account) by
+ Note that this user will automatically be added to various system groups.
+ These groups provide access to devices often used in a desktop environment
+ (removeable media, sound cards, etc).
+ .
+ You may create it later (as well as any additional account) by
  typing 'adduser ' as root, where  is an username,
  like 'imurdock' or 'rms'.
 
Index: debian/changelog
===
--- debian/changelog(revision 44108)
+++ debian/changelog(working copy)
@@ -1,10 +1,16 @@
 user-setup (1.9) UNRELEASED; urgency=low
 
+  [ Colin Watson ]
   * Refuse to apply an empty root password. I don't think this can happen,
 but it's a useful sanity check.
 
- -- Colin Watson <[EMAIL PROTECTED]>  Tue, 19 Dec 2006 17:29:38 +
+  [ dann frazier ]
+  * Explicitly note that the first user gets added to a number of system
+groups by default. This should help reduce the severity of bugs like
+#404927.
 
+ -- dann frazier <[EMAIL PROTECTED]>  Wed, 10 Jan 2007 17:58:04 -0700
+
 user-setup (1.8) unstable; urgency=low
 
   [ Joey Hess ]


-- 
dann frazier


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

Re: RFC: warn user about first accounts privs

[dann frazier]

(btw, I don't subscribe to -boot, so a CC's are appreciated)

Frans Pop said:
> It certainly cannot be committed anymore before the release of Etch as
> we have a string freeze (except in exceptional cases).

k

> TBH, I don't see how a clear kernel/udev issue can be mitigated by 
> something as trivial as this. As if random users will understand what
> the implications are of being a member of certain groups. IMO this is just 
> papering over the issue. Professional sysadmins can be expected to
> check what groups an automatically created account is a member of
> (and will probably not create the first account to be given out to
> any random user anyway).

I completely agree that this is no fix for #404927, never meant to
imply that. In that report you'll see that we plan to deal with this
issue by overriding groups for specific devices in udev while
hopefully getting the kernel fixed upstream in the meantime.

I personally was surprised to see that the first user was added to
additional groups and, had I known that, there are times I would've
elected not to create that user at that time. (Most of my installs are
servers, where these default groups don't make sense). I'm curious if
I'm the only experienced admin who didn't notice and is surprised.
I do agree that its somewhat minor - the first user is usually going
to be a person w/ root privs, and the group privs should normally be
pretty safe - except when bugs like #404927 pop up.

Maybe after etch I'll propse a patch that adds an extra checkbox
(default to yes) that asks users (in expert mode) if they want to be
added to a set of typical desktop user groups.

-- 
dann frazier


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

Bug#407103: installation-report: Issues installing on Toshiba laptop (A105)

[dann frazier]

reassign 407103 installation-reports
thanks

On Mon, Jan 15, 2007 at 11:17:43PM -0800, David Shaver wrote:
> Subject: Issues installing on Toshiba laptop (A105)
> Package: linux-image-2.6.18-3-686 & other
> Version: 2.6.18-7
> Severity: normal (!?)
> 
> Not necessarily 'bugs', but...

This is really an installation-report (multiple issues, multiple
packages), reassigning.

David: for future reference, its better to file installation reports
using this template:
  http://d-i.alioth.debian.org/manual/en.i386/ch05s03.html#submit-bug

-- 
dann frazier



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

Re: Bug#408588: Debian on SGI Altix IA-64

[dann frazier]

On Mon, Jan 29, 2007 at 09:39:08AM -0500, St?phane Larose wrote:
> On Saturday 27 January 2007 23:21, Joey Hess wrote:
> > I'm not 100% sure, but I think that this is happening before udev gets a
> > chance to make it, since it's prior to init starting.
> 
> This is correct. And after init, udev create the /dev/ttySG0 device correctly.
> 
> > Seems like we could fix it by making init-udev-devices skip creation of
> > /dev/tts/0, if running on the altix. What would be a good way to detect
> > that machine?
> 
> I don't know if this is a good way but if the /proc/sgi_sn/ directory exist, 
> it means that the 'sn' driver is loaded which is SGI architecture.

Is /proc mounted at this point? If so, then that's probably the best
detection method available for etch. We could do something like [1]
and not create the serial devices - but that feels like a hack to
me. What if someone put a serial pci card in one of these machines and
wanted to use that as a console?

Is there a way we can support both? What if we create a ttySG0 file in
init-udev-devices and pass console=ttySG0 to the kernel[2]?
If that works, I don't think its a big deal to ask altix users to pass
console=ttySG0 to the installer - we could even put it in the elilo
help menu (which isn't localized).

St?phane: can you test these two patches and report back what works?
If /proc isn't mounted at this point, you might remove the if
statement around [2].

[1]
Index: src/lib/debian-installer/init-udev-devices
===
--- src/lib/debian-installer/init-udev-devices  (revision 44839)
+++ src/lib/debian-installer/init-udev-devices  (working copy)
@@ -22,7 +22,7 @@
makedev 600 /dev/tty"$i" c 4 "$i"
 done
 makedir 755 /dev/tts
-for i in 0 1; do
+[ -d /proc/sgi_sn ] || for i in 0 1; do
makedev 600 /dev/tts/"$i" c 4 "$(($i + 64))"
makedev 600 /dev/ttyS"$i" c 4 "$(($i + 64))"
 done


[2]
Index: src/lib/debian-installer/init-udev-devices
===
--- src/lib/debian-installer/init-udev-devices  (revision 44839)
+++ src/lib/debian-installer/init-udev-devices  (working copy)
@@ -26,3 +26,7 @@
makedev 600 /dev/tts/"$i" c 4 "$(($i + 64))"
makedev 600 /dev/ttyS"$i" c 4 "$(($i + 64))"
 done
+# SGI Altix consoles
+if [ -d /proc/sgi_sn ]; then
+   makedev 600 /dev/ttySG0 c 204 40
+fi

-- 
dann frazier


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

Bug#408588: Debian on SGI Altix IA-64

[dann frazier]

On Fri, Feb 02, 2007 at 01:25:39PM -0500, St?phane Larose wrote:
> I agree - not creating the serial device would be a problem for a pci serial 
> card.

Ok, let's drop this option then

> > Is there a way we can support both? What if we create a ttySG0 file in
> > init-udev-devices and pass console=ttySG0 to the kernel[2]?
> > If that works, I don't think its a big deal to ask altix users to pass
> > console=ttySG0 to the installer - we could even put it in the elilo
> > help menu (which isn't localized).
> >
> > St?phane: can you test these two patches and report back what works?
> > If /proc isn't mounted at this point, you might remove the if
> > statement around [2].
> 
> The first patch works. When testing the second one, I realized that passing 
> console=xx or CONSOLE=xx is not the same (sorry about that). console in 
> lowercase is used by the kernel as the console and not keep as an environment 
> variable. Using CONSOLE in uppercase is not used by the kernel but passed as 
> an environment variable.

The way I read the busybox source, it looks for CONSOLE= first then
console=:

static void console_init(void)
{
...
if ((s = getenv("CONSOLE")) != NULL || (s = getenv("console")) != NULL) 
{
safe_strncpy(console, s, sizeof(console));
...

I don't really understand how kernel command line options become env
vars though - is something preventing console= from being an env var
at this point?

-- 
dann frazier



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

Bug#412624: partman-auto: all files in one partition fails on 1.2TB disk

[dann frazier]

Package: partman-auto
Version: 66
Severity: important

I tested today's daily netinst build of i386 on a machine w/ a 1.2TB
logical disk and found that it silently fails to calculate partition
sizes.

I selected "Partion Disks"->"Guided Partitioning"->"Guided - use entire disk"

Selected my one option:
  SCSI.CCISS (-,0,0) (cciss/c0d0) - 1.2 TB Compaq Smart Array 

And "All files in one partition".

It then presents the overview menu[1], but apparently nothing was
done.

If I let it use the whole disk but split up the partitions, it comes
up with some reasonable-looking calculations.

I'll look into this more later this week - I've not yet debugged any
of the partitioning code so helpful suggestions are welcome :) fyi,
this also exists in sarge installers.

[1]
  ??? This is an overview of your currently configured partitions and mount   
???
  ??? points. Select a partition to modify its settings (file system, mount   
???
  ??? point, etc.), a free space to create partitions, or a device to 
???
  ??? initialise its partition table. 
???
  ???  S  
???
  ??? Guided partitioning 
???
  ??? Help on partitioning
???
  ??? 
???
  ??? SCSI.CCISS (-,0,0) (cciss/c0d0) - 1.2 TB Compaq Smart Array 
???
  ??? > pri/log1.2 TB FREE SPACE  
???
  ??? 
???
  ??? Undo changes to partitions  
???
  ??? Finish partitioning and write changes to disk   
???
  ??? 
???
  ???        
???

-- 
dann frazier | HP Open Source and Linux Organization

Bug#412624: partman-auto: all files in one partition fails on 1.2TB disk

[dann frazier]

On Tue, Feb 27, 2007 at 12:59:47PM +0100, Frans Pop wrote:
> On Tuesday 27 February 2007 04:45, dann frazier wrote:
> > I tested today's daily netinst build of i386 on a machine w/ a 1.2TB
> > logical disk and found that it silently fails to calculate partition
> > sizes.
> 
> I suspect this is because the maximum partition sizes in the recipe don't 
> add up to something that is larger than 1.2TB. Can you try raising the 
> upper limit for / before starting partman?
> 
> 128 512 256 ext3
>   [...]
> mountpoint{ /boot } .
> 
> 500 1 100 ext3
>   [...]
> mountpoint{ / } .
> 
> 96 512 300% linux-swap
>   [...]

Thanks for the suggestion Frans. I added a 0 to the 100, and it
gave me:

SCSI.CCISS (-,0,0) (cciss/c0d0) - 1.2 TB Compaq Smart Array
   #1 primary1.2 TB B f ext3   /
   #5 logical2.7 GB   f swap   swap

So, bumping the limit clearly worked - but if Gordon Moore has
anything to say about it, I'll just need to up it again in 2014 :)

Perhaps we should set it to 16384 GB[1]?

According to Documentation/filesystems/ext2.txt, this is the
filesystem size limit for architectures with a 4kB PAGE SIZE
Architectures that use larger pages (alpha, ia64, etc) can go
up to 32768 GB.
-- 
dann frazier



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

Addition of Newer Kernel @ etch & 1/2

[dann frazier]

hey,
  I've had discussions with a number of folks at DebConf this week
about how we might add new hardware support to a stable release after
its first release.  The most well-received suggestion has been to add
an additional updated kernel in a stable point release - perhaps near
the middle of the release's scheduled lifespan, or when some milestone
in upstream kernel development occurs.  Members of the stable release,
stable security and d-i teams all appeared to be quite open to this
discussion.

For example, if we shipped etch with 2.6.15 today, we could later add
*optional* 2.6.20 package backports into official stable.  d-i would
need to be updated with this kernel of course, and we wouldn't want to
change the default behavior for current stable users by making the new
kernel the default.  Instead, it could be a new boot-time selection
(like 2.6 currently is for sarge/i386).

Of course, this means maintaining security support for an additional
kernel; however, doing so in etch would still be an improvement over
sarge & woody.  Instead of shipping both a recent and an old kernel
on day 0, we would ship a recent kernel on day 0 and an even more
recent kernel a number of months later.

If we want to prepare for this possibility, the one issue that the d-i
folks pointed out is that we'd probably want to refactor our meta
packages such that we could have both metapackages for the latest
2.6.N and additional packages for the latest 2.6.N+, so users can
track whichever they prefer.  One suggestion was to use
linux-image-etch-foo for tracking 2.6.N and something like
linux-image-etch+-foo for tracking the 2.6.N+ update.

Note that this is in the context of etch instead of sarge because
there are a number of transitions that make such an update quite
difficult in sarge (devfs removal, udev, initramfs transition,
linux-2.6 transition, etc).

-- 
dann frazier


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

kernel/d-i/security/release meeting at DebConf6

[dann frazier]

hey,
  Frans Pop assembled an informal BoF at DebConf to discuss cross-team
issues related to the kernel[1].  Attendees included:

  Micah Anderson (micah)
  Andreas Barth (aba)
  dann frazier (dannf)
  Joey Hess (joeyh)
  Moritz Muehlenhoff (jmm)
  Frans Pop (fjp)
  Manoj Srivastava (manoj)
  ...and a few other folks whose names I don't recall

We discussed the following topics:
 * Which kernel to release with Etch (2.6.16 from AB or "current"
   upstream)
 * Kernel Updates during Etch Lifetime
 * Dropping 2.4 from Etch
 * Non-free modules + firmware
 * External module packages
 * Divergence Between linux-2.6 packaging and kernel-package behavior
 * Kernel udeb creation process (possibly using k-p?)

This report is based upon notes I took during the meeting, and my
recollection.  Neither will be completely accurate; and no statements
attributed to an individual should be taken as a direct quote.

Which kernel to release with Etch
-
This discussion is related to a thread[2] on debian-kernel about which
kernel we will choose for etch.

Attendees expressed concern over choosing to move to a new 2.6.x
release shortly before etch releases - a kernel that has has a few
2.6.x.y releases would be preferred.

With respect to using the Adrian Bunk tree, attendees expressed
concern that this tree is unproven.  It is possible that Adrian has
underestimated the amount of energy it will take to maintain such a branch.
Success of this tree may depend upon the assistance of its consumers
(such as Debian).

It was noted that even if we stick with 2.6.16.x, the kernel team will
still need to limit ourselves to cherry picking patches once we
freeze, otherwise we may pull in new features/ABI breakages after the
freeze.

The current release schedule[3] has us freezing the kernel by July
30th.  However, aba noted that the kernel freeze is really just a
dependency of the d-i schedule.  According to Frans, a kernel freeze
of October 1 is necessary for d-i's final release candidate to remain
on schedule.

Andi noted that if we change the kernel later than mid/end July we'll
need to do more extensive testing of the sarge->etch upgrade than usual.

Kernel Updates During Etch Lifetime
---
This discussion is based upon the idea of providing an updated kernel
with new hardware support during the etch *stable* release.  We've
been referring to this update as "etch and a half".

Would we keep both the etch and etch 1/2 kernels?  Yes - we would not
drop support for a stable kernel in a stable release.

2 months was suggested for user testing of a kernel prior to including
it in a point release.

To enable this possibility, d-i will require some work.
fjp said that, for d-i, the critical udeb is base-install which builds
a list of available kernels and selects a default from that.  If a
good default can be found, it will be installed.  If no default is
found, it will just show the list of kernels it did find. (With
medium priority it will always show the list, but with the default selected).
base-install selects this default by taking the stem name of the
kernel and the major version (kernel-image-2.4, linux-image-2.6).
How the kernel is named will be very important.  What will also be important
is what we expect to run after the kernel has been released.

We want to use the same install kernel as the target, to avoid hitting bugs
late in the install.  We would want to add the etch 1/2 kernel to the
installer, and not drop the etch kernel from the installer.

A blocker for d-i would be 2.6.12 -> 2.6.14 style changes (devfs drop).
Frans suggested talking with Marco D'itri (or perhaps GregKH) about planned
udev stability.  Moritz is fairly sure that GregKH is planning to keep
a stable interface.  Frans says Linus has also mentioned that he
doesn't plan to accept breakages to this interface.

Perhaps we disable new kernel features for etch 1/2?  e.g., limit new
feature to new hardware support.  For example, we wouldn't want to
turn on something as drastic as preempt in a stable update.

We wouldn't want an etch 1/2 kernel that requires a large number of
changes to userspace packages.

Questions about X update issues were brought up; but Frans doesn't
think that will affect d-i.  What about alsa?

We should have a formal agreement about how we *would* do an etch & a
half ahead of time so we can make sure d-i has any features it should need. 
This should probably be discussed on -devel to get project-wide buyoff.

Frans thinks d-i can make necessary changes in a max of 2 months, but it
depends upon what other things may be going on at the time (etch+1
betas, etc)

We could make test d-i images available for "stable" like we currently do for
"testing".  We probably don't need the extreme testing as for the first
release.

jmm, dannf & frans all seem to agree that we should use t

Re: kernel/d-i/security/release meeting at DebConf6

[dann frazier]

On Sun, May 21, 2006 at 10:46:44PM +0200, Sven Luther wrote:
> On Sun, May 21, 2006 at 01:09:45PM -0500, dann frazier wrote:
> > Kernel udeb creation process (possibly using k-p?)
> > -
> > If we build all of the *existing* udebs from a single source, we outgrow
> > the limit of the Binary: field in the control file.
> 
> Huh ? This problem is known since over 2 years now, and i thought it was one
> of the things that where fixed earlier this year or late last year ?

Immediately after I sent out the notes from this meeting, aba said
he'd followed up with an ftp master (neuro, iirc).  From what he was
told, it sounds like the information we had during this meeting was
stale/inaccurate.  Hopefully someone will update this thread with the
accurate information so that we can revisit this discussion.  Many of
the attendees are still travelling (in fact, I'm replying to this
without a net connection, so it may be moot once it actually goes
out).  It'll probably be a few days before everyone makes it home, but
then we can continue with a more well-informed discussion.

> > buildd issue - it'd be nice if we could be from an unpacked kernel, but you
> > can't build-dep on that so its a FTBFS.
> 
> Which is why it makes the most sense to build them from linux-2.6, but i won't
> argue this point here.

I think that the decision of whether or not to build them from
linux-2.6 is a separate issue.  If doing so is the right thing, let's
do it, if its not, let's fix the build issue.

> 
> > dannf suggested that maybe k-p can be configured to allow simple unapcking 
> > of
> > debs vs. all the postinst configuratin to allow autobuilders to deal with 
> > udebs
> > better; manoj thinks that this will be possible but further out in the 
> > current
> > k-p transition that allows for users to do more "overriding" of
> > postinstallations by default.
> 
> Mmm. But i don't see how this will play nice with the auto-builders. There is
> no way we can get this behaviour into the current set of deps/build-deps.
> Should we add another new kind (Source-dep: ?) ?

Well, the only problem (aiui) is that kernel installs want to do bad
things like run bootloaders, etc.  If we had a chroot parameter we
could tweak to turn this off, then wouldn't that solve this problem?

> > manoj> new kernel package will have some new features the kernel team might 
> > like
> >  - versioning is messed up, manoj is integrating abi number, etc, into k-p
> > 
> > dannf> what if we split up centralized udeb source packages to manage a 
> > certain
> >set of archs
> > 
> > The consensus was that the current udeb approach is suboptimal, but
> > solving it cleanly won't be possible until etch+1.  None of the
> > attendees considered this issue to be critical for etch, so the
> > current plan is to status quo and wait till etch so that we can come
> > up with a good solution.
> 
> I strongly disagree with this. The non-solution of this issue means that we
> have a limited power to handle abi-breaking security and bug-fix patches, and
> impose unreasonable earliness on the kernel freeze for etch, as well as
> endangers security support during etch's lifetime after that. This was and is
> a problem with sarge, and we should not repeat that. We should have tackled
> this issue last fall though.

I sympathize with your concerns but, speaking as a person that does
security work and udeb maintenance for one architecture, I don't think
this is *that* big of a problem.  ABI changes are more painful, but
d-i work can be ignored when releasing a security update (in fact, we
did so last time) - its just point release that suffer, and those
schedules are more flexible (as far as our users are concerned).

Where this would help solve time critical issues is *before* the
release of etch, where a late change could cause us to miss a release
deadline.  However, the d-i team seemed to believe this was low-risk.

I do believe that our consensus was correct based on what we knew at
the time - however, it now sounds like this information may have been
incorrect so we should re-discuss.

-- 
dann frazier


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

Bug#370043: linux-kernel-di-sparc-2.6: please add qla2xxx drivers

[dann frazier]

Package: linux-kernel-di-sparc-2.6
Version: 1.09
Severity: normal

Please add the qla2xxx drivers - my sunblade needs the qla2200.ko driver :)

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: ia64
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-1-mckinley
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


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

sarge3 kernel build & r3

[dann frazier]

I saw some questions on irc about the sarge3 kernel build & r3...

 it's just, i actualy wanted to release sarge r3 with sarge2
kernels. now i get told sarge3-kernels are already prepared, which
disapoints me a bit, as noone told the stable release team there will
be another kernel update round for r3 :(
 ask dannf, he prepares the updates currently
 and actually sarge r3 is just waiting for a new d-i, which i
understand is currently waiting for kernel udebs...
 dannf: ^
 -boot is responsible for the udebs anyway

During the d-i bof at DebConf I pointed out that the sarge3 kernel
build is in progress and is not an ABI change - there was consensus to
wait for this build before doing the d-i build for r3.  I don't
remember the timeline we discussed for this build.  The current status
is that the build is complete and pending upload by the security team
(I think Moritz would be the one to do it, so I've cc'd him).

I believed aba, joeyh & fjp were all in on this decision, but apologies
if it didn't get communicated back to everyone involved.

 dannf, as long as u dont upload (before coordinating with
 zobel/srm-team) everybody is happy about your work :) 

Personally, I don't care which kernel gets used - that's a
stable-release/d-i decision in my opinion. However, I do not think we
should delay the release of the sarge3 kernel to security.debian.org -
I want to avoid any situation that would prevent us from doing timely
security updates.

If you decide to stick with sarge2 for r3, would an upload of sarge3 to
security.debian.org break this? As I understand it, sarge2 is already
in the queue archive for stable, so those bits would still be
available?

-- 
dann frazier


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

Re: sarge3 kernel build & r3

[dann frazier]

On Tue, Jun 06, 2006 at 06:56:33PM +0200, Martin Schulze wrote:
> However, if kernel udebs should be part of the security update, then
> we'll need proper source packages that build these udebs - or, if
> these already exist, a pointer which source package has been forgotton
> in the last kernel update rounds.

I've offered to perform these builds for all archs except mips, mipsel
& m68k (but I can help coordinate those as well - those arch
maintainers have always been very responsive to my build requests).

This offer is still open, just let me know if they should be against
sarge2 or sarge3.  I suspect I could turn this around in a day or two
(if its the right day or two).

> Oh.  Great.  Good to hear (err... sending such information to
> [EMAIL PROTECTED] would actually be a good idea as well...)

ok

-- 
dann frazier


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

Re: sarge3 kernel build & r3

[dann frazier]

On Tue, Jun 06, 2006 at 09:23:45PM +0200, Frans Pop wrote:
> The more arches are built by the same person, the easier coordination is. 
> So your offer is very welcome.
> 
> Note that you'll need to check out the kernel udeb package sources from 
> the *sarge branch* of the d-i SVN repo for the different arches as ABI 
> numbers have to be updated there.

yes, np.  I'll try to have these done by this weekend.

> I could do i386, sparc and S/390 myself if needed, but only next week.
> 
> I'm still not sure about the status of AMD64 in this update. It would be 
> nice if AMD64 could be brought back in line with the other arches with 
> r3. If the kernel updates cannot be released into the main archive for 
> AMD64, we'll have to skip that arch for d-i too.

I don't think its very likely that amd64/sarge will be added to
debian.org, but this is a good question for the amd64.debian.net
maintainers.

The next point release of sarge will have a kernel ABI change which
will break net install flavors of d-i.  We are preparing an updated
d-i to go along with this release - does the amd64.debian.net project
wish to follow suit?

I have an interest (job-related) in seeing amd64.debian.net track
sarge point releases, so if there is a desire but lack of resources,
please let me know.

-- 
dann frazier


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

Re: sarge3 kernel build & r3

[dann frazier]

On Tue, Jun 06, 2006 at 09:15:44PM +0200, Frans Pop wrote:
> I seem to remember though that the security update was planned for the end 
> of Debconf, so I was a bit surprised when reading my mail backlog this 
> week that it is not out yet.

That was the optimistic plan (I didn't mean to imply otherwise - at
the time I knew this was risky), but working from DebConf turned out
to be pretty painful (net-wise) - we only managed to actually
*release* the old woody updates.

However, we (Troy, Moritz and I) got 2.6.8 source mostly complete
there and I babysat builds off & on from a net cafe in Mexico in
between trips to the beach[1] :)  I finished up 2.4.27 source when I got
back from vacation, then went through the build cycle for them over
the next few days.  There was a lag waiting for porter builds,
although I've eliminated my external dependencies on porters for m68k
& sparc, so they should be faster next time.

... if only I had a working NIC in my SGI Octane :(

> What is the full status of the updates for Sarge for both 2.4 and 2.6?

I submitted them last weekend from bazcamp[2], Moritz said in this
thread that he plans to release them this weekend.

> A release using sarge2 kernels would have been logical if the kernel udebs 
> would have been available in t-p-u earlier than was the case. With all 
> the holidays planned after debconf the timing for the remaining work was 
> rather unfortunate. ATM waiting for sarge3 still seems more logical.
> Personally, I can only go full speed on this once I get back home next 
> week.

I hope to have all the bits you need waiting for you by then.

> As kernel udebs are built manually it is entirely up to the person doing 
> the build to make sure that the correct kernel version is installed on 
> the machine used for the builds.

I will plan to build with sarge3 unless someone tells me different in
the next couple days.  aba/zorbel?

> On Tuesday 06 June 2006 18:56, Martin Schulze wrote:
> > However, if kernel udebs should be part of the security update, then
> > we'll need proper source packages that build these udebs - or, if
> > these already exist, a pointer which source package has been forgotton
> > in the last kernel update rounds.
> 
> No, I don't think that really makes sense as just building the kernel 
> udebs would not get them to the users. You need to release the installer 
> as a whole for that.

Agreed.  Building them with each security update would have no
positive impact that I can see, unless of course the process was
completely automated.

[1] http://en.wikipedia.org/wiki/Zihuatanejo
[2] http://bazcamp.org/
I've had a tough few weeks :)
-- 
dann frazier


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

Re: sarge3 kernel build & r3

[dann frazier]

On Thu, Jun 08, 2006 at 12:59:42AM +0200, Goswin von Brederlow wrote:
> If using the testing images to install stable is not possible in the
> future then we should seriously consider releasing images with newer
> kernels in point releases or having D-I on backports.org.

This is being considered & was discussed a lot at debconf.  See the
debian-kernel archives from around that time for some discussion.

-- 
dann frazier


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

Re: sarge3 kernel build & r3

[dann frazier]

On Thu, Jun 08, 2006 at 01:33:57PM +0200, Goswin von Brederlow wrote:
> Frans Pop <[EMAIL PROTECTED]> writes:
> What changes are those? Is Debian finaly going to use LABEL= or UUID=
> in the generated fstab?

I hope not; /dev/disk/by-* names seem a lot less kludgy to me.

-- 
dann frazier


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

Re: sarge3 kernel build & r3

[dann frazier]

On Tue, Jun 06, 2006 at 01:32:42PM -0600, dann frazier wrote:
> On Tue, Jun 06, 2006 at 09:23:45PM +0200, Frans Pop wrote:
> > The more arches are built by the same person, the easier coordination is. 
> > So your offer is very welcome.
> > 
> > Note that you'll need to check out the kernel udeb package sources from 
> > the *sarge branch* of the d-i SVN repo for the different arches as ABI 
> > numbers have to be updated there.
> 
> yes, np.  I'll try to have these done by this weekend.

Here's the current status...
 DSA is pending for the security update; jmm thought he'd be able to
et those released tonight.  I haven't reconfirmed this with him today.

lkdi builds for most archs are complete, and at:
  people.debian.org:~dannf/3.1r3-lkdi-rebuilds

The exceptions are:
 * linux-kernel-di-powerpc appears to require a 2.4 build host - I've
   poked around looking for help here, but no volunteers yet.
 * linux-kernel-di-m68k-* - I've just e-mailed pokes to a couple m68k
   folks
 * linux-kernel-di-mips* - I've poked a few mips folks; one responded
   saying that he could probably get a build done tomorrow night.

The only "interesting" bit about these rebuilds is that the
jfs-modules udeb has been dropped from ia64. jfs is completely broken
on ia64, and I dropped the module build before sarge's release. This
probably requires a pkglist tweak in d-i.

-- 
dann frazier


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

Re: sarge3 kernel build & r3

[dann frazier]

On Mon, Jun 12, 2006 at 06:50:36PM -0600, dann frazier wrote:
> The exceptions are:
>  * linux-kernel-di-powerpc appears to require a 2.4 build host - I've
>poked around looking for help here, but no volunteers yet.

Still need help with this one...

>  * linux-kernel-di-m68k-* - I've just e-mailed pokes to a couple m68k
>folks

Done (thanks Stephen!)

>  * linux-kernel-di-mips* - I've poked a few mips folks; one responded
>saying that he could probably get a build done tomorrow night.

Done (thanks tbm/Sledge!)

-- 
dann frazier


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

Re: sarge3 kernel build & r3

[dann frazier]

On Tue, Jun 13, 2006 at 03:41:42PM -0600, dann frazier wrote:
> On Mon, Jun 12, 2006 at 06:50:36PM -0600, dann frazier wrote:
> > The exceptions are:
> >  * linux-kernel-di-powerpc appears to require a 2.4 build host - I've
> >poked around looking for help here, but no volunteers yet.
> 
> Still need help with this one...

Sledge saw this & did a build for us, so now all builds are complete
and available at:
 people.debian.org:~dannf/3.1r3-lkdi-rebuilds

Let me know if/when I should upload them.

-- 
dann frazier


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

Bug#375036: discover1-data: missing 8086:1060 e1000 mapping

[dann frazier]

Package: discover1-data
Version: 1.2006.01.14
Severity: normal
Tags: patch

--- discover1-data-1.2006.01.14/pci.lst.orig2006-01-14 11:57:48.0 
-0700
+++ discover1-data-1.2006.01.14/pci.lst 2006-06-22 14:32:59.0 -0600
@@ -6205,6 +6205,7 @@
80861059ethernete10082551QM Ethernet Controller
8086105eethernete1000   82571EB Gigabit Ethernet 
Controller
8086105fethernete1000   82571EB Gigabit Ethernet 
Controller
+   80861060ethernete1000   82571EB Gigabit Ethernet 
Controller
80861064ethernete10082562ET/EZ/GT/GZ - PRO/100 VE 
(LOM) Ethernet Controller
80861065ethernete10082562ET/EZ/GT/GZ - PRO/100 VE 
Ethernet Controller
80861066ethernete10082562 EM/EX/GX - PRO/100 VM 
(LOM) Ethernet Controller


-- Package-specific info:
lspci:
00:00.0 0300: 10de:0258 (rev a3)
00:00.0 VGA compatible controller: nVidia Corporation NV25GL [Quadro4 900 XGL] 
(rev a3)
80:04.0 0100: 1000:0021 (rev 01)
80:04.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1010 66MHz  
Ultra3 SCSI Adapter (rev 01)
a0:01.0 0c03: 1033:0035 (rev 41)
a0:01.0 USB Controller: NEC Corporation USB (rev 41)
a0:01.1 0c03: 1033:0035 (rev 41)
a0:01.1 USB Controller: NEC Corporation USB (rev 41)
a0:01.2 0c03: 1033:00e0 (rev 02)
a0:01.2 USB Controller: NEC Corporation USB 2.0 (rev 02)
a0:02.0 0101: 1095:0649 (rev 02)
a0:02.0 IDE interface: Silicon Image, Inc. SiI 0649 Ultra ATA/100 PCI to ATA 
Host Controller (rev 02)
a0:03.0 0200: 8086:100e (rev 02)
a0:03.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet 
Controller (rev 02)
a0:04.0 0401: 1319:0801 (rev b2)
a0:04.0 Multimedia audio controller: Fortemedia, Inc Xwave QS3000A [FM801] (rev 
b2)
a0:04.1 0980: 1319:0802 (rev b2)
a0:04.1 Input device controller: Fortemedia, Inc Xwave QS3000A [FM801 game 
port] (rev b2)

discover:

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: ia64
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-2-mckinley
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

-- no debconf information


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

Bug#283214: root cause

[dann frazier]

I root caused this issue a while back; details here:
  http://dannf.org/bloggf/tech/cciss-grub-real-fix.html

-- 
dann frazier



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

Re: Urgent : megaraid and qla2300 modules not found

[dann frazier]

On Thu, Aug 17, 2006 at 03:05:35PM +0200, De Leeuw Guy wrote:
> Hello,
> 
> I have 2 days to install debian etch on our production server.
> I download the last daily build of the cdrom (release
> debian-testing-ia64-netinstall.iso 20060815).
> But missing the driver megaraid legacy and qla2300 on the cdrom
> 
> It's my last chance to migrate our redhat to debian
> 
> could you help me by building a new daily build iso with these 2 modules
> or minimum with the megaraid_legacy ?

I'll fix this for the next build - thanks for reporting it.
In the meantime it might be easiest for you to:

 * grab
 
http://mirrors.kernel.org/debian/pool/main/l/linux-2.6.16/linux-image-2.6.16-2-itanium-smp_2.6.16-17_ia64.deb
 * extract the contents somewhere:
dpkg-deb -x linux-image-2.6.16-2-itanium-smp_2.6.16-17_ia64.deb /tmp/dir
 * Post the modules you need on an http server somewhere
 * Once your network is up, drop to a shell and wget the drivers from
   your server
 * Use insmod/modprobe to load these modules
 * return to the installer

If you have problems, like you don't have access to an http server,
etc, hop on #debian-ia64 & i'll try to help you out.

-- 
dann frazier


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

Bug#383540: installation-report: vague question - "Use installation logs from another location?"

[dann frazier]

Package: installation-report
Version: 2.17

"Use installation logs from another location?"

Should I answer this question with a yes/no? Should I give it a path?
It might be good to give an example answer in brackets:
  [yes/no]
  [/path/to/log]
  etc

-- 
dann frazier | HP Open Source and Linux Organization


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