Debian installer for Buffalo LS Live (LS-CHL) and Mini (LS-WSGL)
Martin Michlmayr
(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.
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.
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
Note: I'm not planning to backport the flash-kernel/oldsys-preseed changes
to squeeze (stable).
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.
--
Martin Michlmayr
http://www.cyrius.com/
--
To UNSUBSCRIBE, email to debian-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2011051108...@jirafa.cyrius.com
Vanja Cvelbar
At last I managed to find some time to start testing the installation.
Our son was born on the 4th May and we are still recovering from this
little earthquake in our lives ;-)
Anyway... I took out the LS-CHL from the drawer and successfully
flashed the installer on it using an empty disk. Right now it is
booting correctly, and getting an IP address from the DHCP server. I
could connect to the installer through ssh and download all the needed
components for the installation. The SATA disk was correctly
recognised and the partitioning could be put forward. It seems, that
everything is mature to be used on replacement disks. In fact by
putting the LS-CHL in EM mode it should be usable also with the
original disks and it's not required to open the case.
Tomorrow I'll try to reflash an original firmware and check both the
script and the direct upgrade from the EM mode.
Good night
Vanja
--
Vanja Cvelbar
Work: +39 040 3756456
FAX: +39 040 9890668
GSM: +39 348 2241352
Follow your Euro notes in their tracks
http://www.eurobilltracker.eu/?referer=63885
--
To UNSUBSCRIBE, email to debian-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/BANLkTikAmV4UCc3U...@mail.gmail.com
Benjamin Cama
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
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 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 Mini, and put it in $path"
exit 1
fi
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
dumb.
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
problem.
> 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.
Thanks,
benjamin
--
To UNSUBSCRIBE, email to debian-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1312145676.3...@localhost.localdomain
Benjamin Cama
Le dimanche 31 juillet 2011 à 22:54 +0200, Benjamin Cama a écrit :
> 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…)
One remark about that: we should definitely get that working, as I ran
into an issue upon reboot; for some reason, /dev/sdb1 was not seen as a
good ext3 partition by U-boot for some time, and it didn't bother me. I
somehow fsck'd it, and upon reboot, the bootloader took my shiny new
kernel from sda1 (that I told the installer is for /boot) but with an
old initrd from sdb1. It seems to kind of “load-balance” the loading of
kernel and initrd… (it always at least check both for valid u-boot
images on both drives) Of course, this didn't work. As I'm no good at
fiddling with U-boot, I used d-i to get a shell, mount my partitions and
copy the good kernel+initrd to /dev/sdb1 and all went fine. But this
problem will reappear on the next kernel upgrade. So, I'm interested in
any advices on this md setup. The workaround for now may be to simply
scramble /dev/sdb1 so that U-boot doesn't use it at all.
One more thing, about the drives: by default, their power management is
set to a crazy spin-down time of 5 seconds. I installed hdparm and added
the following to /etc/default/hdparm:
harddisks="/dev/sda /dev/sdb"
hdparm_opts="-B254 -S60"
# we use software raid, so set it
RAID_WORKAROUND=yes
Which sets the timeout to 5 minutes. Much better.
Regards,
benjamin
PS: Cc me, I'm not subscribed.
--
To UNSUBSCRIBE, email to debian-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1312195200.3...@localhost.localdomain
Martin Michlmayr
> 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.
> 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.
> 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.
> 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.
> 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.
> 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.
> 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.
--
Martin Michlmayr
http://www.cyrius.com/
--
To UNSUBSCRIBE, email to debian-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110804100...@jirafa.cyrius.com
Benjamin Cama
Le jeudi 04 août 2011 à 11:02 +0100, Martin Michlmayr a écrit :
> * Benjamin Cama <ben...@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
--
To UNSUBSCRIBE, email to debian-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1312474848.3...@localhost.localdomain
Martin Michlmayr
> -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"
I'd update this to say "... on /dev/sda1 or /dev/md0".
> 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"
I'd probably just say "for Linkstation" here.
> + echo "You have to download the initrd.buffalo file from the debian-installer for Linkstation Pro/Live or Mini, and put it in $path"
Same.
> > It's in the debian-installer package.
>
> Thanks. I will submit this patch if you think it's ok.
Sure. Presumably Hector Oron will apply the patch for you when you
file a bug.
> > 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")
Yes, but "Buffalo Linkstation LiveV3 (LS-CHL)" should probably be
added too. (I don't think I received any feedback from LS-CHL/LiveV3
users.)
--
Martin Michlmayr
http://www.cyrius.com/
--
To UNSUBSCRIBE, email to debian-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2011081013...@jirafa.cyrius.com
Hector Oron
2011/8/10 Martin Michlmayr <t...@cyrius.com>:
> * Benjamin Cama <ben...@free.fr> [2011-08-04 18:20]:
>> Thanks. I will submit this patch if you think it's ok.
> Sure. Presumably Hector Oron will apply the patch for you when you
> file a bug.
Sure, but I'll need Benjamin to test it, as I do not own such device.
Cheers,
--
Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-.
--
To UNSUBSCRIBE, email to debian-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/CAODfWeE1kvqDz6Sb0tSR5Nhi...@mail.gmail.com
Benjamin Cama
Le mercredi 10 août 2011 à 16:27 +0100, Hector Oron a écrit :
> 2011/8/10 Martin Michlmayr <t...@cyrius.com>:
> > * Benjamin Cama <ben...@free.fr> [2011-08-04 18:20]:
>
> >> Thanks. I will submit this patch if you think it's ok.
>
> > Sure. Presumably Hector Oron will apply the patch for you when you
> > file a bug.
>
> Sure, but I'll need Benjamin to test it, as I do not own such device.
As I said some time ago in this thread, I don't have the original system
on my Mini anymore, and it's too much burden for me to install it back
just to test that, sorry.
Still, I “tested” this script by running it on my lsmini with Debian,
with busybox applets for mount/grep/sed, and it worked OK. I know this
isn't really a true /real/ conditions testing, but it looks “right
enough” to me.
Regards,
benjamin
--
To UNSUBSCRIBE, email to debian-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1312991486.1...@localhost.localdomain
Hector Oron
2011/8/10 Benjamin Cama <ben...@free.fr>:
>> >> Thanks. I will submit this patch if you think it's ok.
>>
>> > Sure. Presumably Hector Oron will apply the patch for you when you
>> > file a bug.
Patch applied on version control system. Thanks.
--
Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-.
<free spam>
-- Would you like to make a donation for Debian Conference?
** http://debconf11.debconf.org/payments.xhtml **
</free spam>
--
To UNSUBSCRIBE, email to debian-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/CAODfWeFAG-1qiaf0hpCpxL2C...@mail.gmail.com