Bug#510271: installation-report: Lenny on a Slug - eventual success after a few tries and some fixups

2009-01-20 Thread Rod Whitby
Martin Michlmayr wrote:
> * Rick Thomas  [2009-01-13 10:05]:
>>> Sorry, I was wrong here.  Yeah, this sounds like an interesting
>>> approach.
>> I don't think regenerating the image should be necessary.  If "--payload" 
> 
> Yes, as I said, I was wrong.  You can just specify --payload with an
> existing image when uploading to the NSLU2.
> 
>> can be used along with the image you provide, then there could be code in 
>> the image that looks to see if the "payload" area has something that looks 
>> like a preseed (maybe a "magic number" or checksum or timestamp or 
>> something else to be reasonably sure we're not being fooled by random data 
>> or by stuff left-over from the last d-i.) If there is, it can use it, if 
>> not, it can ignore it.
>>
>> Or am I missing something?  I don't know much about the internals of the 
>> upslug2 process, so I'm sure there's plenty I could be missing.  Is there 
>> documentation beyond the upslug2 man page I could look at?  In particular, 
>> I gather that the program on the slug end of the upslug2 process is called 
>> "redboot" -- is that correct?  Is there a Linksys manual or technical 
>> paper describing redboot?
> 
> The boot loader on the NSLU2 is RedBoot, but I don't think this
> payload has anything to do with RedBoot per se.  I think the payload
> features simply writes the data to a location in flash that isn't used
> for anything.
> 
> But I don't know any details myself about this feature.  I've copied
> Rod Whitby who should be able to point to more documentation (if it
> exists) or give us more information.

Source code for the upgrade protocol in the Linksys (written by SerComm)
 version of RedBoot is available.

The --payload switch to upslug2 is probably not used by anyone in the
world at the moment (we certainly haven't used it in the nslu2-linux
project, nor in the NSLU2 Debian work).

All it does is overwrite an area in the FIS directory partition when
uploading an image.  It's exactly equivalent to overwriting the bytes in
the image before calling upslug2 - there is no special upgrade protocol
support used or required.

So nothing uses that area today (we were considering using it for IXP
microcode storage, but decided to put it in the rootfs instead), and no
Linksys software touches that area (which is why we originally thought
of using it, and added support for that in the tools).  However, it will
be overwritten by each flash of the NSLU2, so is different from the
SysConf area (which is currently used for preseeding network settings)
in that respect.

-- Rod



-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: installation errors

2007-08-16 Thread Rod Whitby
Martin Michlmayr wrote:
> * Dan Burt <[EMAIL PROTECTED]> [2007-08-09 08:05]:
>> so now i am trying to reinstall this, but obviously i no longer have
>> the web interface. using the redboot loader, i assumed it would use
>> the 192.168.1.77 ip address so set up my laptop in the same range.
>> using the sercomm windows utility, it finds a device and i try to
>> upload the firmware (di-nslu2.bin from the debian-4.0r0.zip
>> installer release) but recieve the following errors:
>>
>> H/W Types Mismatch!
> 
> Rod, have you heard of such a problem before?

No, I haven't.

Dan, have you tried using upslug2 ?

You don't have any other devices on the same LAN which might be made by
SerComm (like the NSLU2 is) ?

-- Rod


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



Re: armel debian-installer using gnuab repo

2007-08-06 Thread Rod Whitby
> Joey Hess wrote:
>>> I've prepared a build of d-i that uses the gnuab.org armel repository,
>>> which currently holds the armel debs that the armel porters hope will
>>> eventually get into Debian proper.
>>>
>>> I made some minor modifications to d-i for this build, but it's
>>> basically the same quality image as other daily d-i builds.

So I gave it a try on an NSLU2, and the install failed when trying to
install initramfs-tools in the target chroot, with the following syslog
contents:

> Aug  7 12:45:14 root: register-modules
> Aug  7 12:45:16 apt-install: Reading package lists...
> Aug  7 12:45:16 apt-install:
> Aug  7 12:45:16 apt-install: Building dependency tree...
> Aug  7 12:45:25 apt-install:
> Aug  7 12:45:28 apt-install: You might want to run `apt-get -f install' to 
> correct these:
> Aug  7 12:45:28 apt-install: The following packages have unmet dependencies:
> Aug  7 12:45:28 apt-install:   libpam-modules: Depends: libdb4.3 (>= 
> 4.3.28-1) but it is not installable
> Aug  7 12:45:28 apt-install:   module-init-tools: Conflicts: modutils but 
> 2.4.27.0-6 is to be installed
> Aug  7 12:45:29 apt-install: E:
> Aug  7 12:45:29 apt-install: Unmet dependencies. Try 'apt-get -f install' 
> with no packages (or specify a solution).
> Aug  7 12:45:29 apt-install:
> Aug  7 12:45:41 base-installer: info: kernel linux-image-versatile not usable 
> on ixp4xx
> Aug  7 12:45:41 base-installer: info: kernel linux-image-ixp4xx usable on 
> ixp4xx
> Aug  7 12:45:41 base-installer: info: kernel linux-image-iop32x not usable on 
> ixp4xx
> Aug  7 12:45:41 base-installer: info: kernel linux-image-2.6.22-1-versatile 
> not usable on ixp4xx
> Aug  7 12:45:41 base-installer: info: kernel linux-image-2.6.22-1-ixp4xx 
> usable on ixp4xx
> Aug  7 12:45:41 base-installer: info: kernel linux-image-2.6.22-1-iop32x not 
> usable on ixp4xx
> Aug  7 12:45:41 base-installer: info: kernel linux-image-2.6-versatile not 
> usable on ixp4xx
> Aug  7 12:45:41 base-installer: info: kernel linux-image-2.6-ixp4xx usable on 
> ixp4xx
> Aug  7 12:45:41 base-installer: info: kernel linux-image-2.6-iop32x not 
> usable on ixp4xx
> Aug  7 12:45:41 base-installer: info: Found kernels 
> 'linux-image-2.6-ixp4xx,linux-image-2.6.22-1-ixp4xx,linux-image-ixp4xx'
> Aug  7 12:45:42 base-installer: info: arch_kernel candidates: 
> linux-image-2.6-ixp4xx
> Aug  7 12:45:42 base-installer: info: arch_kernel: linux-image-2.6-ixp4xx 
> (present)
> Aug  7 12:45:42 base-installer: info: Using kernel 'linux-image-2.6-ixp4xx'
> Aug  7 12:45:42 base-installer: info: Setting do_initrd='yes'.
> Aug  7 12:45:42 base-installer: info: Setting link_in_boot='yes'.
> Aug  7 12:45:43 base-installer: info: Available initramfs generator(s): 
> 'initramfs-tools yaird'
> Aug  7 12:45:44 apt-install: Reading package lists...
> Aug  7 12:45:44 apt-install:
> Aug  7 12:45:44 apt-install: Building dependency tree...
> Aug  7 12:45:51 apt-install:
> Aug  7 12:45:53 apt-install: You might want to run `apt-get -f install' to 
> correct these:
> Aug  7 12:45:53 apt-install: The following packages have unmet dependencies:
> Aug  7 12:45:53 apt-install:   initramfs-tools: Depends: klibc-utils (>= 
> 1.4.19-2) but it is not going to be installed
> Aug  7 12:45:53 apt-install:Depends: busybox (>= 
> 1:1.01-3) but it is not going to be installed or
> Aug  7 12:45:53 apt-install: busybox-initramfs 
> but it is not installable
> Aug  7 12:45:53 apt-install:Depends: udev (>= 0.086-1) 
> but it is not going to be installed
> Aug  7 12:45:53 apt-install:   libpam-modules: Depends: libdb4.3 (>= 
> 4.3.28-1) but it is not installable
> Aug  7 12:45:53 apt-install:   module-init-tools: Conflicts: modutils but 
> 2.4.27.0-6 is to be installed
> Aug  7 12:45:54 apt-install: E:
> Aug  7 12:45:54 apt-install: Unmet dependencies. Try 'apt-get -f install' 
> with no packages (or specify a solution).
> Aug  7 12:45:54 apt-install:
> Aug  7 12:45:54 base-installer: error: exiting on error 
> base-installer/kernel/failed-package-install

And here is what happens when I run apt-get install initramfs-tools from
the target chroot:

> ~ # chroot target apt-get install initramfs-tools
> Reading package lists... Done
> Building dependency tree... Done
> You might want to run `apt-get -f install' to correct these:
> The following packages have unmet dependencies:
>   initramfs-tools: Depends: klibc-utils (>= 1.4.19-2) but it is not going to 
> be installed
>Depends: busybox (>= 1:1.01-3) but it is not going to be 
> installed or
> busybox-initramfs but it is not installable
>Depends: udev (>= 0.086-1) but it is not going to be 
> installed
>   libpam-modules: Depends: libdb4.3 (>= 4.3.28-1) but it is not installable
>   module-init-tools: Conflicts: modutils but 2.4.27.0-6 is to be installed

-- Rod


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "u

Re: armel debian-installer using gnuab repo

2007-08-06 Thread Rod Whitby
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Joey Hess wrote:
> I've prepared a build of d-i that uses the gnuab.org armel repository,
> which currently holds the armel debs that the armel porters hope will
> eventually get into Debian proper.
> 
> I made some minor modifications to d-i for this build, but it's
> basically the same quality image as other daily d-i builds. (Though it's
> not yet built daily.) Like the daily arm builds of the installer, it
> lacks a version of the nslu2 image that includes non-free firmware.

I've added the non-free ethernet driver firmware (/lib/firmware/NPE-B),
and put the resulting image up on http://www.slug-firmware.net (look
right at the bottom of the page, after a whole lot of whitespace, under
"Experimental Unstable Unsupported Alpha Releases").  So you should be
able to use that on an unmodified NSLU2 to test this release.

FYI, there were 92 downloads of the previous version (2007-02-27) of
this non-free NLSU2 image.

- -- Rod Whitby
- -- NSLU2-Linux Project Lead
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.4 (MingW32)

iD8DBQFGt8jZ5DZEEWQDKUYRAka6AJ4pMd62Q3MswrtR80jgArIg13nq/gCdGlDA
LwqIIrMEkscXqXvnrm3OqJE=
=kvcc
-END PGP SIGNATURE-


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



Bug#403017: Ramdisk and ramdisk

2006-12-17 Thread Rod Whitby
Geert Stappers wrote:
> Is there really both 'Ramdisk' and 'ramdisk' in /proc/mtd ?

Yes, "Ramdisk" on NSLU2 and "ramdisk" on Thecus N2100.  Those fragments
are applying to two separate cases of $machines.

On the third case (Iomega NAS100d), it's called "filesystem", just to be
different :-)

-- Rod


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



Bug#403016: Please add pata_artop module for Iomega NAS100d

2006-12-13 Thread Rod Whitby
Package: kernel-wedge
Version: 2.29
Severity: wishlist
X-Debbugs-CC: [EMAIL PROTECTED]

Porting the debian installer to the ixp4xx/nas100d requires the
pata_artop module (which depends on libata) be added to the installer image.

The question is whether it is simply added to sata-modules (it uses the
new SATA/PATA libata subsystem, but is not actually a SATA controller),
or whether a new pata-modules udeb is created, with libata being split
out into an ata-common-modules udeb.

I'm going to continue testing by simply adding it to sata-modules, but
will be happy to migrate to comply with whatever you decide.

This is not etch-critical :-)

-- Rod




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



Bug#403017: Patch to flash-kernel for nas100d support

2006-12-13 Thread Rod Whitby
Package: flash-kernel
Version: 0.9
Tags: patch

Could you please apply the attached patch to flash-kernel?

It tightens up the grep match patterns (I got stung because I had both
"filesystem" and "filesystem2" partitions), and adds support for
flashing the Iomega NAS 100d.

With this patch, and the kernel patches I sent Martin previously, Debian
kernel 2.6.19 runs nicely on the NAS100d.  Next, I'll be looking at what
else needs to be done to support it in the installer.

This is not etch-critical, but would save me having to hand-edit this
file each time I do a test debian-installer installation.

Thanks,

-- Rod

Index: flash-kernel
===
--- flash-kernel(revision 43316)
+++ flash-kernel(working copy)
@@ -19,7 +19,7 @@
 }
 
 mtdblock() {
-   grep "$1" /proc/mtd | cut -d: -f 1 | sed 's/mtd/\/dev\/mtdblock/'
+   grep "\"$1\"" /proc/mtd | cut -d: -f 1 | sed 's/mtd/\/dev\/mtdblock/'
 }
 
 # See http://www.nslu2-linux.org/wiki/Info/BootFlash -- the NSLU2 uses a
@@ -128,7 +128,7 @@
) > "$mtdkernel" || error "failed."
echo "done." >&2
printf "Flashing initramfs: " >&2
-   size=$(grep "Ramdisk" /proc/mtd | cut -d " " -f 2)
+   size=$(grep "\"Ramdisk\"" /proc/mtd | cut -d " " -f 2)
size=$(printf "%d" 0x$size)
isize=$(wc -c $ifile | awk '{print $1}')
cat $ifile > $tmp
@@ -143,6 +143,30 @@
) > $mtdramdisk || error "failed."
echo "done." >&2
;;
+   "Iomega NAS 100d")
+   check_mtd
+   mtdramdisk=$(mtdblock filesystem)
+   if [ -z "$mtdramdisk" ]; then
+   error "Cannot find mtd partition 'filesystem'"
+   fi
+   mtdkernel=$(mtdblock kernel)
+   if [ -z "$mtdkernel" ]; then
+   error "Cannot find mtd partition 'kernel'"
+   fi
+   printf "Flashing kernel: " >&2
+   cat $kfile > "$mtdkernel" || error "failed."
+   echo "done." >&2
+   printf "Flashing initramfs: " >&2
+   size=$(grep "\"filesystem\"" /proc/mtd | cut -d " " -f 2)
+   size=$(printf "%d" 0x$size)
+   isize=$(wc -c $ifile | awk '{print $1}')
+   pad=$(expr $size - $isize)
+   (
+   cat $ifile
+   dd if=/dev/zero bs=$pad count=1 2>/dev/null
+   ) > $mtdramdisk || error "failed."
+   echo "done." >&2
+   ;;
"Thecus N2100")
check_mtd
mtdramdisk=$(mtdblock ramdisk)
@@ -160,7 +184,7 @@
) > $mtdkernel || error "failed."
echo "done." >&2
printf "Flashing initramfs... " >&2
-   size=$(grep "ramdisk" /proc/mtd | cut -d " " -f 2)
+   size=$(grep "\"ramdisk\"" /proc/mtd | cut -d " " -f 2)
size=$(printf "%d" 0x$size)
isize=$(wc -c $ifile | awk '{print $1}')
pad=$(expr $size - $isize)