[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian installer for Buffalo LS Live (LS-CHL) and Mini (LS-WSGL)

Hi Martin,

First, sorry for /very/ long delay on testing this image, and thank you
for persisting on supporting such devices.

Le mercredi 11 mai 2011 à 10:08 +0200, Martin Michlmayr a écrit :
> This is an update regarding Debian support for the Linkstation Live
> (LS-CHL) and the Linkstation Mini (LS-WSGL): all of the changes have
> been integrated into Debian unstable and Debian installer should work
> on these devices now.  However, a script will be needed to install Debian
> installer from the original firmware.  This script for the regular
> Linkstation Pro/Live needs to be adapted for LS-CHL/LS-WSGL; see
> http://d-i.debian.org/daily-images/armel/daily/orion5x/network-console/buffalo/lspro/config-debian
> for the Pro/Live script.  Hopefully you can test this script and tell
> me of any changes that are needed.

Here is my “naive” patch for Linkstation Mini (I already wiped the
original system away), which basically change the /boot device to md0
instead of sda1. As I understood, this file is here specifically for the
Mini; no need to do a multiple-target script, right? (I can do that if
it's better).

--- config-debian.lspro	2011-07-30 17:33:07.000000000 +0200
+++ config-debian	2011-07-30 17:46:33.000000000 +0200
@@ -5,19 +5,19 @@
 NVRAM=$(which nvram)
 FW_PRINTENV=$(which fw_printenv)
-path=$(mount | grep ext[23] | sed -n '/sda1/ {s/\/dev\/sda1 on \(.*\) type.*/\1/; p}')
+path=$(mount | grep ext[23] | sed -n '/md0/ {s/\/dev\/md0 on \(.*\) type.*/\1/; p}')
 if [ -z "$path" ]; then
-	echo "You have to create an ext2 filesystem on /dev/sda1"
+	echo "You have to create an ext2 filesystem on /dev/md0"
 	exit 1
 if [ ! -e $path/uImage.buffalo ]; then
-	echo "You have to download the uImage.buffalo file from the debian-installer for Linkstation Pro/Live, and put it in $path"
+	echo "You have to download the uImage.buffalo file from the debian-installer for Linkstation Mini, and put it in $path"
 	exit 1
 if [ ! -e $path/initrd.buffalo ]; then
-	echo "You have to download the initrd.buffalo file from the debian-installer for Linkstation Pro/Live, and put it in $path"
+	echo "You have to download the initrd.buffalo file from the debian-installer for Linkstation Mini, and put it in $path"
 	exit 1

Tell me if I should fill a bug report against some package: I didn't
find where it comes from.

> You can find the installer image here:
> http://d-i.debian.org/daily-images/armel/daily/orion5x/network-console/buffalo/ls-chl/
> http://d-i.debian.org/daily-images/armel/daily/orion5x/network-console/buffalo/ls-wsgl/
> Please only try this if you have a serial console.

So, I tried the images dated 2011/07/30 (the ones from 2011/07/23 caused
problem with missing dm and lvm modules) on my Linkstation Mini and the
install went /almost/ perfectly.

My first problem was… finding the password used by the network console.
I didn't remember from my last install months ago. Could this be written
(password is “install”) somewhere where it's quite visible, please ? As
it took me more than one hour of search to find it. Or maybe I'm too

Then, there is the fact that I'm still not able to create a RAID1 array
for /boot that could mimic the behavior of the original /dev/md0, that
is, that one partition (/dev/sda1) or the other (/dev/sdb1) can be
mounted as a standalone ext3 fs. I'm not good at all at md stuff, so I
don't know how realizable this is, but it could be nice to have this
same setup as the original firmware, as u-boot still handle both devices
as standalone partitions, and that having the data on both is more
reliable. (even if the included u-boot doesn't seem to be very happy
whenever an image is broken; I wasn't even able to TFTP boot my device
once when I had broken the uImage. I had to remove the drives and put
back a correct image on the disk…)

Furthermore, I think their would be some patching needed if this is
realized, as I think partman currently check for /dev/sda1 being mounted
on /boot, right? This would just be a matter of checking for /dev/md0,
or whatever (ext3-formatted) array is using /dev/sd[ab]1.

Anyway, I told partman to use /dev/sda1 for /boot and it went smoothly
with that.

Then, there was this very strange issue: the installer could not “make
the system bootable”. I spent quite a lot of time finding the problem:
it was not that your patches weren't correct (they actually are!) but
that the installer had disabled the wheezy/main repository for some
reason, and the installer subsequently could not find the flash-kernel
package! I remember now that it said during install that the mirror was
not reachable, then I asked it to check again, it did it, and it went on
without complaining (this mirror is working perfectly right now). This
is very disturbing, not to have any main repo configured (the one that
were still enabled were the source repo for main, and the security
updates) while the installation still tries to go on. I don't know if I
should fill a bug for that or not. Anyway, the error message was
useless, and I had to check /var/log/syslog to get an idea of what was
going on.

BTW, regarding your warning for people without serial console: this
image went right away through setting up the network console without

> For reference, the following changes were made.
>  kernel (#590105): LS-CHL/LS-WSGL supported in 2.6.32 in squeeze, 2.6.37
>                    in d-i and 2.6.38 in unstable.
>  libdebian-installer (#612168): LS-CHL/LS-WSGL supported in squeeze and
>                                 unstable.
>  flash-kernel (612167): LS-CHL/LS-WSGL supported in unstable but not in
>                         squeeze (stable).
>  oldsys-preseed (616326): same as flash-kernel.
>  debian-installer: generate images for LS-CHL/LS-WSGL; done in unstable

Thanks for all your work.

> Note: I'm not planning to backport the flash-kernel/oldsys-preseed changes
> to squeeze (stable).

A bit sad, but I can live with that. Some other less risky people might
find that disappointing. Do you think it's too difficult, or it's
because you don't have time for this?

> Finally, someone needs to update the documentation on various wikis to
> point to the correct images.  Please put in a big fat warning that people
> cannot just use the Pro/Live image when they don't have a Pro/Live.

I'll have to look at that maybe.


Reply to: