Re: Debian kernel package for linkstation pro
Tim Small
> You may remember that a while back I tried to use your kernel package,
> but that my u-boot (from the original lspro firmware) didn't load the
> initrd properly when I removed the initrd= boot parameter. Today I
> updated the bootloader to 1.10 using the Buffalo updater, installed a
> fresh deboostrap of Sid, and installed your kernel package. This time
> it works fine. So, I'd suggest updating your README to mention that
> updating the bootloader is definitely a hard requirement for the Debian
> initramfs to be loaded properly.
>
Thanks Ryan. Just for the record, can you tell me what firmware version
you now have in flash?
Martin: Just to clarify, what I believe is going on here is:
. Early Buffalo uboots don't pass through the location of the initrd to
the kernel (via the in-memory boot info data structure). As a result,
Buffalo supplied an initrd=xyz argument to the kernel - this works OK
with initrds, but with initramfs, the current code chokes (because the
size they pass in is too big).
. Later Buffalo uboots do successfully pass-through the initrd location
and size correctly via the in-memory boot info data structure, and the
initrd= argument is not required (can be deleted from the nvram settings
safely).
So the situation is:
Buffalo kernels and initrds (uses old-style initrd):
. Work with older firmwares (with initrd=xyz parameter), and newer
firmwares (with, or without initrd=xyz parameter).
The kernel which I packaged (uses initramfs):
. Does not work with older firmwares, but works with newer firmwares
(with, or without initrd=xyz parameter), because I included a patch to
ignore buffalo's initrd= parameter.
Mainline kernel / stock Debian kernel when booting with initramfs:
. Does not work with older firmwares, but works with newer firmwares but
only if you remove the initrd=xyz parameter from nvram.
Moving forward, the possibilities are, as I see it:
. Patch the mainline initramfs code in a nice way, so that it'll work
with any lspro firmware version - and hope the kernel maintainers accept
the patch (which they might, as the current code is arguably a bit broken).
. Patch/shim Debian kernel to work with any lspro firmware version.
. Upgrade firmware + remove initrd= parameter before using a stock kernel.
Cheers,
Tim.
--
To UNSUBSCRIBE, email to debian-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ryan Tandy
> Just for the record, can you tell me what firmware version you now have in flash?
/proc/cmdline reports BOOTVER=1.10.
Thanks,
Ryan
Martin Michlmayr
> > Just for the record, can you tell me what firmware version you now have in flash?
>
> /proc/cmdline reports BOOTVER=1.10.
Do you remember the version that didn't work?
--
Martin Michlmayr
http://www.cyrius.com/
Martin Michlmayr
> . Patch the mainline initramfs code in a nice way, so that it'll
> work with any lspro firmware version - and hope the kernel
> maintainers accept the patch (which they might, as the current code
> is arguably a bit broken).
Are you going to go ahead and report this issue? If you don't have
the time, I can go ahead and do it.
--
Martin Michlmayr
http://www.cyrius.com/
Ryan Tandy
> Do you remember the version that didn't work?
I can't find it written down anywhere, but I believe it was 1.01. As
far as I can tell there were three versions released by Buffalo: 1.01 on
the first Linkstation hardware, 1.09 on the second revision of it, and
1.10 in the firmware update released for both hardware revisions.
Thanks,
Ryan
Tim Small
> * Tim Small <t...@buttersideup.com> [2008-07-27 15:01]:
>
>> . Patch the mainline initramfs code in a nice way, so that it'll
>> work with any lspro firmware version - and hope the kernel
>> maintainers accept the patch (which they might, as the current code
>> is arguably a bit broken).
>>
>
> Are you going to go ahead and report this issue? If you don't have
> the time, I can go ahead and do it.
>
Hmm, I think in order to stand a chance of getting it fixed, you'd
probably need to submit a patch - as this would require a reasonable
time investment, without a guarantee of it getting accepted, I wonder if
it might not be best just to fix the problem in user space? It would
probably be easier to create an initrd which deletes the faulty nvram
setting, (and upgrades the firmware to a known-good version if
necessary, whilst guaranteeing not to downgrade it).
You'd just need to document this as a necessary prerequisite for the
Debian install.... This would also have the side effect of creating an
easy way to upgrade the firmware without the use of Windows.
Cheers,
Tim.
Martin Michlmayr
> Hmm, I think in order to stand a chance of getting it fixed, you'd
> probably need to submit a patch
Not necessarily.
> investment, without a guarantee of it getting accepted, I wonder if
> it might not be best just to fix the problem in user space? It
> would probably be easier to create an initrd which deletes the
> faulty nvram setting,
I guess there are two possibilities:
- use the nvram utility to remove the 15M parameter before starting
d-i.
- put some shim in the initrd or kernel.
Given that the LS Pro software doesn't need the 15M parameter (since
it's an initrd), the first choice might be best.
Is the nvram utility included is the LS Pro software environment or is
that only on the Kurobox Pro?
> (and upgrades the firmware to a known-good version if necessary,
> whilst guaranteeing not to downgrade it).
I thought even the new firmware didn't work with the 15M parameter.
--
Martin Michlmayr
http://www.cyrius.com/
Ryan Tandy
> Is the nvram utility included is the LS Pro software environment or is
> that only on the Kurobox Pro?
The nvram utility is included with the LS Pro software as well. A free
alternative to it is fw_printenv and fw_setenv, which are included in
the U-boot distribution. A uboot-mkimage package already exists in
Debian; perhaps these tools could be packaged as well.
Thanks,
Ryan
Tim Small
> Given that the LS Pro software doesn't need the 15M parameter (since
> it's an initrd), the first choice might be best.
>
> Is the nvram utility included is the LS Pro software environment or is
> that only on the Kurobox Pro?
>
>
>> (and upgrades the firmware to a known-good version if necessary,
>> whilst guaranteeing not to downgrade it).
>>
>
> I thought even the new firmware didn't work with the 15M parameter.
>
1.01 firmware doesn't pass in the initr* location via the in memory
boot-info data structure
1.10 firmware (and also 1.09, I think) does pass in the initr* location
and also the *correct* size, via the in-memory boot-info data structures
so:
1.01 Firmware with initrd= parameter: initrds work, but initramfs
don't work (junk after initramfs causes rejection, but trailing junk is
ignored for initrd)
1.01 Firmware without initrd= paramter: Neither initrd, nor initramfs
work (kernel isn't given any initr* loc or size info)
1.10 Firmware with initrd= parameter: initrds work, but initramfs
don't work
1.10 Firmware without initrd= parameter: Both initrds and initramfs work
I'll have a look into automating the nvram change and flash update....
Cheers,
Tim.
Tim Small
I presume (but I'm not sure) that the only method for installing Debian
on the kuropro, and lspro will be to start the installer via TFTP.. I
suppose it might also be possible to write an installer image to the HD
of the linkstation (by connecting the drive directly to another machine
first), and use this to boot-strap the install.
Initially, I didn't think this was possible to do on the lspro, without
using a serial cable (since there is no method on the lspro V2s which I
have to force a tftpboot, without a serial cable, but some earlier hw/fw
versions apparently have a feature to do this by holding down the reset
key during power-on).
AFAIK, no one is making, or selling the lspro serial cables
commercially, and although the parts are cheap, they are time-consuming
and relatively difficult to make.
In the end, between myself, and the others on IRC (#linkstationwiki on
freenode), we came up with two methods:
A (keep stock firmware):
1. Update your firmware to the latest version from Buffalo (new
linkstations ship with this already).
2. Use a serial cable to trigger tftp install.
B (use non-standard firmware):
The linkstation firmware is a patched version of uboot. The Buffalo
changes have been forward-ported to a newer version of uboot 1.1.4,
which has been built with network console support - thus doing away with
the need for a serial cable:
http://buffalo.nas-central.org/download/Users/davy_gravy/uboot_materials/
Additionally, since the source code for the firmware is available, it
should be possible to restore the
hold-down-reset-during-power-on-to-trigger-tftpboot feature to the
current Buffalo firmware, in order to keep changes to a minimum -
however someone would have to be sufficiently motivated to do this....
We came up with some methods for getting the updated firmware onto the
Linkstations:
i. Use the Buffalo 'EM Mode' firmware updater (implemented via
Buffalo's kernel+initrd pair) to flash the newer firmware.
ii. Take the front-panel off the Linkstation, and disconnect/remove the
hard drive - the Buffalo uboot will then fall-back to booting from tftp,
and the new firmware could then be flashed via this way.
iii. Write the firmware updater directly to the HD of the linkstation
using another machine.
Whichever firmware is being used, you'll need to delete the faulty
initrd=... boot parameter from the uboot "nvram" variables (which are
actually also stored in flash - not nvram - in the linkstations), but
this should be possible by the same sort of methods which would be
necessary for updating the firmware (or could just be done manually
using the serial console).
Per Andersson
> I presume (but I'm not sure) that the only method for installing Debian on
> the kuropro, and lspro will be to start the installer via TFTP.. I suppose
> it might also be possible to write an installer image to the HD of the
> linkstation (by connecting the drive directly to another machine first), and
> use this to boot-strap the install.
The installation of Debian on the kuropro flashes the installer
image to disk, then alters the u-boot environment to boot
that. The change of the u-boot environment is later (re)used
by the installed system.
I don't know much about the lspro but does it not have an
original firmware or EM that you can boot into? On the
kuropro the "EM" is used until you press the init/reset
button with a harddrive in it and some files in /mnt/mtd to
install a new rootfs. So if pressing the init/reset button is
avoided accesing the disk from EM is possible, writing
installer images to it.
Can EM be used similarly on the lspro?
-- Per
Per Andersson
> the kuropro, and lspro will be to start the installer via TFTP.. I suppose
> it might also be possible to write an installer image to the HD of the
> linkstation (by connecting the drive directly to another machine first), and
> use this to boot-strap the install.
The installation of Debian on the kuropro flashes the installer
image to disk, then alters the u-boot environment to boot
that. The change of the u-boot environment is later (re)used
by the installed system.
I don't know much about the lspro but does it not have an
original firmware or EM that you can boot into? On the
kuropro the "EM" is used until you press the init/reset
button with a harddrive in it and some files in /mnt/mtd to
install a new rootfs. So if pressing the init/reset button is
avoided accesing the disk from EM is possible, writing
installer images to it.
Can EM be used similarly on the lspro?
-- Per
Tim Small
> Can EM be used similarly on the lspro?
>
The Buffalo software does indeed include an "emergency mode", but this
is entered as a special case from their kernel/initrd pair, both of
which are stored on the hard-disk. Once you install the Debian kernel
and initramfs (replacing the Buffalo kernel and initrd), this
functionality would be lost. The only thing in flash on the lspro is uboot.
Also, an unpatched Debian kernel and initramfs won't boot on the lspro
without deleting the initrd=... parameter (more accurately, the initrd=
parameter causes an initramfs to fail to load on all unpatched Linux
kernels, but does not affect an initrd).
Cheers,
Tim.
Per Andersson
> The Buffalo software does indeed include an "emergency mode", but this is
> entered as a special case from their kernel/initrd pair, both of which are
> stored on the hard-disk. Once you install the Debian kernel and initramfs
> (replacing the Buffalo kernel and initrd), this functionality would be lost.
> The only thing in flash on the lspro is uboot.
>
> Also, an unpatched Debian kernel and initramfs won't boot on the lspro
> without deleting the initrd=... parameter (more accurately, the initrd=
> parameter causes an initramfs to fail to load on all unpatched Linux
> kernels, but does not affect an initrd).
I see, it is no problem though if the u-boot environment needs
to be changed. The EM images can also be backed up. With
the help of uboot-envtools it's also possible to retreat to it
again by changin the u-boot environment (and placing kernel
and ramdisk on the drive again of course).
Do you think the current debian installer code and method
for installing Debian on the Kurobox Pro would work for
Linkstation Pro/Live as well? The method goes something
like this:
1) Create a ext2 filesystem on the first partition on the
attached harddrive. (Has to be ext2 because u-boot can only
load files from ext2.)
2) Download uImage.buffalo, initrd.buffalo and flash-debian
3) Put uImage.buffalo and initrd.buffalo on the created ext2
partition
4) Run flash-debian
5) Reboot
6) Install Debian over SSH
7) Reboot
8) ???
9) Success!
Regarding installer code, look for "Buffalo/Revogear Kurobox
Pro" in [0] and [1].
Is it possible to extract some information from EM, possibly
placing it on the harddrive alongside with the installer
images? I am thinking that this information could be used
for oldsys-preseed, but maybe I am stretching it...
-- Per
[0] http://svn.debian.org/wsvn/d-i/trunk/packages/oldsys-preseed/oldsys-preseed?op=file&rev=0&sc=0
[1] http://svn.debian.org/wsvn/d-i/trunk/packages/flash-kernel/flash-kernel?op=file&rev=0&sc=0
Tim Small
> Do you think the current debian installer code and method
> for installing Debian on the Kurobox Pro would work for
> Linkstation Pro/Live as well? The method goes something
> like this:
>
> 1) Create a ext2 filesystem on the first partition on the
> attached harddrive. (Has to be ext2 because u-boot can only
> load files from ext2.)
>
Well, the first partition should already be ext2 at this point, because
that's where the kernel+initrd which have got you into "emergency mode"
come from.
> 2) Download uImage.buffalo, initrd.buffalo and flash-debian
> 3) Put uImage.buffalo and initrd.buffalo on the created ext2
> partition
> 4) Run flash-debian
>
I don't know what "flash-debian" does....
> 5) Reboot
>
Before this point, you would need to check the firmware revision, and
then either delete the initrd= uboot "nvram" setting, or use a
non-standard debian kernel (or the initramfs won't load).
> 6) Install Debian over SSH
> 7) Reboot
> 8) ???
> 9) Success!
>
OK, but I cam see a few problems with this approach:
1. If the Buffalo software is not working, or not present on the HD, you
can't install Debian.
2. If you start with a blank hard drive (e.g. you have upgraded the hard
drive), you can't install Debian.
3. If you can't get into your Debian install for some reason (e.g.
filesystem corruption, or you've just forgotten the root password), you
would be unable to re-install Debian (or anything else).
For these reasons, I think I would recommend just relying on what's in
flash (i.e. uboot - default or otherwise) as a prerequisite for the
install....
Cheers,
Tim.
Per Andersson
On Fri, Aug 8, 2008 at 10:09 AM, Tim Small <t...@buttersideup.com> wrote:
> Per Andersson wrote:
>>
>> Do you think the current debian installer code and method
>> for installing Debian on the Kurobox Pro would work for
>> Linkstation Pro/Live as well? The method goes something
>> like this:
>>
>> 1) Create a ext2 filesystem on the first partition on the
>> attached harddrive. (Has to be ext2 because u-boot can only
>> load files from ext2.)
>>
>
> Well, the first partition should already be ext2 at this point, because
> that's where the kernel+initrd which have got you into "emergency mode" come
> from.
But this assumes no hard disk upgrade etc, right?!
>> 2) Download uImage.buffalo, initrd.buffalo and flash-debian
>> 3) Put uImage.buffalo and initrd.buffalo on the created ext2
>> partition
>> 4) Run flash-debian
>>
>
> I don't know what "flash-debian" does....
The script flash-debian apparently was renamed to
config-debian... Anyway the script [0] checks that the
installer images are present at the correct place, checks
that nvram tool exists and then changes the u-boot
environment.
>> 5) Reboot
>>
>
> Before this point, you would need to check the firmware revision, and then
> either delete the initrd= uboot "nvram" setting, or use a non-standard
> debian kernel (or the initramfs won't load).
It could be included in a flash-debian script specifically for
the Linkstation Pro.
>> 6) Install Debian over SSH
>> 7) Reboot
>> 8) ???
>> 9) Success!
>>
>
> OK, but I cam see a few problems with this approach:
>
> 1. If the Buffalo software is not working, or not present on the HD, you
> can't install Debian.
> 2. If you start with a blank hard drive (e.g. you have upgraded the hard
> drive), you can't install Debian.
But this would be the same for EM right? If you upgrade
the hard drive you don't have any EM either?
> 3. If you can't get into your Debian install for some reason (e.g.
> filesystem corruption, or you've just forgotten the root password), you
> would be unable to re-install Debian (or anything else).
This is solved by rescue-initramfs [1], which I have prepared
and tested patches that enables you to login via SSH if
the rootfs didn't come up. (Patches are not commited yet.)
> For these reasons, I think I would recommend just relying on what's in flash
> (i.e. uboot - default or otherwise) as a prerequisite for the install....
I don't follow you here...
-- Per
[0] http://svn.debian.org/wsvn/d-i/trunk/installer/build/boot/arm/kuroboxpro-config-debian?op=file&rev=0&sc=0
[1] http://git.debian.org/?p=collab-maint/rescue-initramfs.git;a=summary
Martin Michlmayr
> Initially, I didn't think this was possible to do on the lspro,
> without using a serial cable (since there is no method on the lspro
> V2s which I have to force a tftpboot, without a serial cable, but
> some earlier hw/fw versions apparently have a feature to do this by
> holding down the reset key during power-on).
Oh, I thought you said the current firmware version had the "press
reset, do TFTP" feature. Bugger.
> ii. Take the front-panel off the Linkstation, and disconnect/remove
> the hard drive - the Buffalo uboot will then fall-back to booting
> from tftp, and the new firmware could then be flashed via this way.
I think that's the best approach since it works in all situations
(i.e. no matter whether Debian or the Linkstation firmware or nothing
is installed on the disk). i.e. we can tell people to use the same
approach to a) install Debian b) load a rescue or backup image if
Debian on disk is busted, etc
> Whichever firmware is being used, you'll need to delete the faulty
> initrd=... boot parameter from the uboot "nvram" variables (which
> are actually also stored in flash - not nvram - in the
Yep.
So for the first installation of Debian the instructions would be:
- Run a script supplied by Debian that will use nvram to change
bootargs_root=root=/dev/sda2 rw initrd=0x00800040,15M panic=5
to
bootargs_root=root=/dev/sda2 rw initrd=0x00800040 panic=5
And then we tell users to install Debian by removing the disk and
installing some files on a TFTP server.
What we will need:
1) debian-installer images for TFTP. We need an uImage.buffalo and
initrd.buffalo file of debian-installer. This is easy.
2) flash-kernel support: flash-kernel (despite the name) now supports
both flash and disk based devices. It has to make a bootable image on
disk. I think the support we have for Kurobox should work out of the
box. We just need to recognize the LS Pro. I'll send a patch soon.
3) oldsys-preseed support: this script looks at flash or the disk for
an existing network configuration which will then be used in
debian-installer. I don't know what the firmware looks like. Where
is the network config stored? On the Kurobox Pro, there's some stuff
in /etc/netinfo as well as /etc/host.info Is this the same on the LS?
If not, Tim, can you take a look at oldsys-preseed and implement LS
support:
svn://svn.d-i.alioth.debian.org/svn/d-i/trunk/packages/oldsys-preseed
If you don't have the time, please put a tar ball of /etc from a LS
somewhere and I'll take a look.
And that's basically it.
Anything I forgot?
--
Martin Michlmayr
http://www.cyrius.com/
Martin Michlmayr
> 2) flash-kernel support: flash-kernel (despite the name) now supports
> both flash and disk based devices. It has to make a bootable image on
> disk. I think the support we have for Kurobox should work out of the
> box. We just need to recognize the LS Pro. I'll send a patch soon.
Tim, can please install flash-kernel from unstable, attach the patch
below, run 'flash-kernel' and see if your machine still boots?
BTW, what about the Terastation Pro II/Live and Linkstation Pro Duo?
Do they boot in the same way? If so, we could add support for them
too.
Index: flash-kernel
===================================================================
--- flash-kernel (revision 54608)
+++ flash-kernel (working copy)
@@ -111,12 +111,20 @@
machine=$(grep "^Hardware" /proc/cpuinfo | sed 's/Hardware\s*:\s*//')
case "$machine" in
- "Buffalo/Revogear Kurobox Pro")
+ "Buffalo/Revogear Kurobox Pro" | "Buffalo Linkstation Pro/Live")
check_subarch "orion5x"
tmp=$(tempfile)
printf "Generating kernel u-boot image... " >&2
- # Set machine id 1509 (0x05e5)
- devio > $tmp 'wl 0xe3a01c05,4' 'wl 0xe38110e5,4'
+ case "$machine" in
+ "Buffalo/Revogear Kurobox Pro")
+ # Set machine id 1509 (0x05e5)
+ devio > $tmp 'wl 0xe3a01c05,4' 'wl 0xe38110e5,4'
+ ;;
+ "Buffalo Linkstation Pro/Live")
+ # Set machine id 1585 (0x0631)
+ devio > $tmp 'wl 0xe3a01c06,4' 'wl 0xe3811031,4'
+ ;;
+ esac
cat $kfile >> $tmp
mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n "$desc" -d $tmp $tmp.uboot >&2 1>/dev/null
echo "done." >&2
Martin Michlmayr
> installing some files on a TFTP server.
I have one question about this. Does the LS use dhcp in this case to
obtain an IP address and the IP of the server, or will it always use
the hardcoded value (192.168.11.1)?
Tim Small
> Oh, I thought you said the current firmware version had the "press
> reset, do TFTP" feature. Bugger.
>
I was told it did by people on #linkstationwiki - I thought I had broken
this feature on my box by changing the default nvram settings, but after
further investigation, it appears that at least the current shipping
lspro-v2s, this feature no longer works.
> So for the first installation of Debian the instructions would be:
>
> - Run a script supplied by Debian that will use nvram to change
> bootargs_root=root=/dev/sda2 rw initrd=0x00800040,15M panic=5
> to
> bootargs_root=root=/dev/sda2 rw initrd=0x00800040 panic=5
>
Pretty much, but I think the best approach is to supply an initrd which
does this automatically (for those who are operating without a serial
console, you could use the built-in speaker or front-panel LEDs to
signal success). For the record, the change would be:
bootargs_root=root=/dev/sda2 rw initrd=0x00800040,15M panic=5
to
bootargs_root=root=/dev/sda2 rw panic=5
the kernel then falls-back to using the (correct position and size)
initrd info which uboot passes in via an in-memory information table.
This in-memory initrd information only created by newer firmwares, so
there needs to be a firmware rev check in there (can by done by taking a
checksum of a region of the flash memory...
> And then we tell users to install Debian by removing the disk and
> installing some files on a TFTP server.
>
> What we will need:
>
> 1) debian-installer images for TFTP. We need an uImage.buffalo and
> initrd.buffalo file of debian-installer. This is easy.
>
BTW, just as a test, I tried the installer images from:
http://people.debian.org/~kmuto/d-i/images/daily/orion5x/netboot/buffalo/kuroboxpro/
If I force tftpboot via serial console, they work (however the Ethernet
module loading fails with:
[ 3.830000] rtc-rs5c372 0-0032: setting system clock to 2008-08-08
07:51:09 UTC (1218181869)
[ 3.840000] Freeing init memory: 108K
[ 5.680000] mv643xx_eth: Unknown symbol mii_ethtool_sset
[ 5.690000] mv643xx_eth: Unknown symbol mii_link_ok
[ 5.700000] mv643xx_eth: Unknown symbol mii_check_gmii_support
[ 5.710000] mv643xx_eth: Unknown symbol mii_nway_restart
[ 5.720000] mv643xx_eth: Unknown symbol generic_mii_ioctl
[ 5.720000] mv643xx_eth: Unknown symbol mii_ethtool_gset
but I'm guessing that this is a problem with this particular build....
> 2) flash-kernel support: flash-kernel (despite the name) now supports
> both flash and disk based devices. It has to make a bootable image on
> disk. I think the support we have for Kurobox should work out of the
> box. We just need to recognize the LS Pro. I'll send a patch soon.
>
OK. I also did this:
http://buttersideup.com/files/lspro/kernel-img.conf
http://buttersideup.com/files/lspro/install-linkstation-kernel.stock
which is probably a duplication of the same thing, but might be a useful
cross reference.
> 3) oldsys-preseed support: this script looks at flash or the disk for
> an existing network configuration which will then be used in
> debian-installer. I don't know what the firmware looks like. Where
> is the network config stored?
I don't know, I've not done much with the stock Buffalo user-space or
Windows configuration tools - and I've just used DHCP for all my boxes.
I just mounted the fresh-out-of-the-box lsprov2's /dev/sda2 on another
box (BTW, the rootfs is xfs, so the installer image would need the xfs
fs module to be included). There is no netinfo file, and nothing
interesting in host.conf.
If I get time, I'll take a look at the Windows software to see if there
is any mechanism to set a non-DHCP IP address.
Cheers,
Tim.
Tim Small
> Tim, can please install flash-kernel from unstable, attach the patch
> below, run 'flash-kernel' and see if your machine still boots?
>
Yep, that works - that patch should be OK to commit, I think...
> BTW, what about the Terastation Pro II/Live and Linkstation Pro Duo?
> Do they boot in the same way? If so, we could add support for them
> too.
>
I don't know, sorry.
Cheers,
Tim.
Martin Michlmayr
* Tim Small <t...@buttersideup.com> [2008-08-10 12:34]:
>> - Run a script supplied by Debian that will use nvram to change
>> bootargs_root=root=/dev/sda2 rw initrd=0x00800040,15M panic=5
>> to
>> bootargs_root=root=/dev/sda2 rw initrd=0x00800040 panic=5
>
> Pretty much, but I think the best approach is to supply an initrd which
> does this automatically
I'm not sure we can do that. The installer will use an initramfs
rather than an initrd, so the u-boot environment has to be changed
before the installer can be started.
However, the LS firmware has telnet enabled, right? Is there wget
too? If so, we can simply tell people in the documentation to use
wget to download a script from Debian and this script will nvram to
change bootargs_root.
So the steps to start the installer would be;
- Upgrade to the latest Buffalo firmware
- Login via telnet, download a script, run it
- Set up TFTP
- Disconnect the disk
- Boot via TFTP...
- Login via SSH and perform the installation
> This in-memory initrd information only created by newer firmwares, so
> there needs to be a firmware rev check in there (can by done by taking a
> checksum of a region of the flash memory...
Isn't this information stored somewhere in /proc?
> [ 5.720000] mv643xx_eth: Unknown symbol generic_mii_ioctl
> [ 5.720000] mv643xx_eth: Unknown symbol mii_ethtool_gset
> but I'm guessing that this is a problem with this particular build....
Strange. Someone else reported this but I've no idea how this could
happen. Can you send me a full log in private? When did you download
the installer image?
> http://buttersideup.com/files/lspro/install-linkstation-kernel.stock
> which is probably a duplication of the same thing, but might be a useful
> cross reference.
Yeah, it's essentially the same. If you can test flash-kernel, I can
commit the change and upload it to the archive.
> BTW, the rootfs is xfs, so the installer image would need the xfs fs
> module to be included
Good point. I don't want to include the xfs module right now, so I
guess we should just force DHCP for now.
--
Martin Michlmayr
http://www.cyrius.com/
Tim Small
> Does the LS use dhcp in this case to
> obtain an IP address and the IP of the server, or will it always use
> the hardcoded value (192.168.11.1)?
>
>
The Buffalo uboot uses a hard-coded IP address of 192.168.11.150, with a
hard-coded tftp server IP of 192.168.11.1 . I believe that davygravy's
uboot does dhcp (I'll flash it later on, and check).
Cheers,
Tim.
Tim Small
> * Tim Small <t...@buttersideup.com> [2008-08-10 12:34]:
>
>>> - Run a script supplied by Debian that will use nvram to change
>>> bootargs_root
>>>
>> does this automatically
>>
>
> I'm not sure we can do that. The installer will use an initramfs
> rather than an initrd, so the u-boot environment has to be changed
> before the installer can be started.
>
I was thinking that a separate initrd image would be needed for the
purpose of changing the nvram parameters, and/or installing a
network-console-enabled uboot - either that, or the kernel used by the
installer could be patched (but that's more maintenance, I think).
Cheers,
Tim.
Martin Michlmayr
>> I'm not sure we can do that. The installer will use an initramfs
>> rather than an initrd, so the u-boot environment has to be changed
>> before the installer can be started.
> I was thinking that a separate initrd image would be needed for the
> purpose of changing the nvram parameters
I assumed we could do this with the Buffalo firmware? Can people not
telnet to the Buffalo firmware and then download a script with wget
and run it?
--
Martin Michlmayr
http://www.cyrius.com/
Lennert Buytenhek
> > [ 5.720000] mv643xx_eth: Unknown symbol generic_mii_ioctl
> > [ 5.720000] mv643xx_eth: Unknown symbol mii_ethtool_gset
> > but I'm guessing that this is a problem with this particular build....
>
> Strange. Someone else reported this but I've no idea how this could
> happen. Can you send me a full log in private? When did you download
> the installer image?
Maybe CONFIG_MII=m and the particular module loader being used isn't
resolving module dependencies? (Or mii.ko isn't included in the fs?)
Martin Michlmayr
> Maybe CONFIG_MII=m and the particular module loader being used isn't
> resolving module dependencies? (Or mii.ko isn't included in the fs?)
Yeah, I just checked and mii.ko is not included on the arm image. For
some reason, nic-modules doesn't depend on nic-shared-modules (which
contains mii) on arm whereas it does on armel. Fortunately, nobody is
supposed to use arm anymore but I'll look into fixing it anyway.
--
Martin Michlmayr
http://www.cyrius.com/
Tim Small
> For some reason, nic-modules doesn't depend on nic-shared-modules (which
> contains mii) on arm whereas it does on armel. Fortunately, nobody is
> supposed to use arm anymore but I'll look into fixing it anyway.
>
Hmm, yes, my bad, I accidentally clicked the arm, instead of the armel
link at the bottom of http://www.debian.org/devel/debian-installer/ -
that's what happens if you stay up until 2am swearing at a Solaris box,
I suppose....
I'll check out what happens with the armel d-i later on, if I get a chance.
Cheers,
Tim.