Re: Debian installer for Buffalo LS Live (LS-CHL) and Mini (LS-WSGL)
Hi,
Le jeudi 04 août 2011 à 11:02 +0100, Martin Michlmayr a écrit :
> * Benjamin Cama <benoar@free.fr> [2011-07-31 22:54]:
> > 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).
>
> I think it would be better to have one file to avoid code duplication.
> Is there an easy way to detect which device the script is run on? If
> so, that would be best way to do it. If not, then it's okay to have
> two scripts.
Well, I was simply speaking of somethink like that:
diff --git a/build/boot/arm/lspro-config-debian b/build/boot/arm/lspro-config-debian
index 05e979e..644f363 100644
--- a/build/boot/arm/lspro-config-debian
+++ b/build/boot/arm/lspro-config-debian
@@ -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 '/sda1\|md0/ {s/\/dev\/\(sda1\|md0\) on \(.*\) type.*/\2/; p}')
if [ -z "$path" ]; then
echo "You have to create an ext2 filesystem on /dev/sda1"
exit 1
fi
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 Pro/Live or Mini, and put it in $path"
exit 1
fi
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 Pro/Live or Mini, and put it in $path"
exit 1
fi
diff --git a/build/config/armel/orion5x/network-console.cfg b/build/config/armel/orion5x/network-console.cfg
index 61efb6e..7e86100 100644
--- a/build/config/armel/orion5x/network-console.cfg
+++ b/build/config/armel/orion5x/network-console.cfg
@@ -60,6 +60,8 @@ lsmini:
cp $(TEMP)/ls-wsgl/kernel.uboot $(SOME_DEST)/$(EXTRANAME)/buffalo/ls-wsgl/uImage.buffalo
mkimage -A arm -O linux -T ramdisk -C gzip -a 0x02000000 -e 0x02000000 -n "debian-installer ramdisk" -d $(TEMP_INITRD) $(TEMP)/ls-wsgl/initrd.uboot
cp $(TEMP)/ls-wsgl/initrd.uboot $(SOME_DEST)/$(EXTRANAME)/buffalo/ls-wsgl/initrd.buffalo
+ install -m 744 boot/arm/lspro-config-debian $(SOME_DEST)/$(EXTRANAME)/buffalo/ls-wsgl/config-debian
+ update-manifest $(SOME_DEST)/$(EXTRANAME)/buffalo/ls-wsgl/config-debian "Script to run debian-installer"
update-manifest $(SOME_DEST)/$(EXTRANAME)/buffalo/ls-wsgl/uImage.buffalo "Linux kernel for Linkstation Mini"
update-manifest $(SOME_DEST)/$(EXTRANAME)/buffalo/ls-wsgl/initrd.buffalo "initrd for Linkstation Mini"
From what I read here: http://buffalo.nas-central.org/wiki/LS_Mini:_Serial_Port_Output_-_Boot-Log
the /proc/cpuinfo is not of much help.
It may seem a but goofy to talk about /dev/sda1 on the Mini, but it will
work, and anyway this case with such a broken partition should not
happen very often (or maybe when the partition is not mounted?…)
Well, even if it's not perfect, this patch looks right enough to me.
> > Tell me if I should fill a bug report against some package: I didn't
> > find where it comes from.
>
> It's in the debian-installer package.
Thanks. I will submit this patch if you think it's ok.
> > 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
> > dumb.
>
> It's mentioned in the install guide for the Kurobox Pro:
> http://www.cyrius.com/debian/orion/buffalo/kuroboxpro/install.html
> I'm not aware of an install guide for the Linkstation since I don't
> support these devices. If there's documentation on the Linkstation
> wiki, you can make the edit there.
OK, thanks. I'm not at all related with nas-central.org, but I may point
them to these changes.
> > 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
>
> This should work just fine.
Mmhh… You made me look more precisely at mdadm, and actually, by
default, RAID arrays do not behave like that. You have to either use a
“raw” array with --build, or use an older metadata version (0.9). I
chose the second version, and it works!
But still, I don't know how to do that in partman (md arrays I created
in it use 1.2 metadata version).
BTW, I made a mistake in the UUID of /boot in /etc/fstab, and after a
reboot my Mini didn't come up on the network… Had to hook up to the
serial port to find out that a partition could “not be checked”, as I
had put the wrong UUID. It made me realize how fragile are systems that
may only be accessed by the network. Someone without a serial port would
really be f*cked.
> > 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.
>
> No, this is not a problem (see #504397). In any case, the partition
> check is currently only done on LS Pro/Live and Kurobox. You have to
> modify partman-ext3/check.d/ext2_or_ext3_boot and add the other LS
> devices.
Like that?:
diff --git a/check.d/ext2_or_ext3_boot b/check.d/ext2_or_ext3_boot
index cde0de0..e32d795 100755
--- a/check.d/ext2_or_ext3_boot
+++ b/check.d/ext2_or_ext3_boot
@@ -8,7 +8,8 @@ case $ARCH in
arm*)
machine=$(grep "^Hardware" /proc/cpuinfo | sed 's/Hardware\s*:\s*//') || true
case "$machine" in
- "Buffalo Linkstation Pro/Live" | "Buffalo/Revogear Kurobox Pro")
+ "Buffalo Linkstation Pro/Live" | "Buffalo/Revogear Kurobox Pro" \
+ | "Buffalo Linkstation Mini")
;;
"GLAN Tank")
;;
> > 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
>
> No idea. Maybe you can send a report with /var/log/syslog to the
> debian-boot list.
Thanks for the suggestion.
> > 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?
>
> It shouldn't be difficult but I have no time and absolutely no
> interest in Linkstation devices. I spent way more time on them
> already than I wanted.
OK, thanks for your work anyway. I don't think I'll have time nor
motivation to do that either.
Regards,
benjamin
Reply to: