On Wed, Nov 03, 2010 at 08:58:35PM -0700, Jose Solorio wrote:
> I've installed debian on my ss4000-e about 4 times now and I can not
> figure out how to get it to boot.
Did you follow these instructions ?
http://d-i.alioth.debian.org/manual/en.armel/ch05s01.html#boot-firmware-ss4000e
If you reached the end of installation without errors, your NAS should
boot automatically from the flash, as a result of the installation
process.
> I also am not sure how to setup the disks. Do I set up the software
> raid first or do I install on a single partition w/ the boot flag. I
> have tried both ways with no progress.
Disk(s) are useless to boot. The SS4000-E boots from a flash memory on
the board. After installing the system the normal way, D-I "copies"
the kernel and the initrd to this flash memory.
You should see "Flashing kernel/initrd..." at the end of the
installation process, don't you ?
If yes, the Nas should boot automagically from flash after next
powercycling.
> Here's what I would like to do: Install debian on the ss4000-e so
> that I can install webmin and even maybe some iscsi targets. I would
> also like to know if anyone knows how to restore the Ipstor distro
> that came with it. I have done numerous searches and can't come up
> with anything. Can someone please help out. Thank you in advance for
> any replies.
Isn't it with the so called "console" : a program, available on the
supplied CD, which must be running on another computer to "detect" the
SS4000-E on the LAN and upload it Ipstor by some means (I suppose,
never tried) ?
However, for your own good, you should better throw away the crapy
Ipstor software...
Even if the somewhat limited hardware is also impacting performances,
you can't go wrong at all with a Debian install on that machine.
Hih,
--
JFS.
--
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/2010110513...@hohenhole.jfs.dt
On Sat, Nov 06, 2010 at 01:26:02AM -0700, Jose Solorio wrote:
> Yes, I think I followed the instructions pretty good. When
> installation is finishing up I do get "Flashing kernel/initrd...".
> In my latest attempt I was successful installing but after reboot I
> got the can't load ramdisk.gz and zImage because it couldn't via
> tftp.
Just to be sure I understand right : the nas should (re)boot alone and
you are not supposed to do anything, right ?
If it can't boot in these conditions, I suspect a wrong
boot_script_data content, but if the installer went correctly, you
should have the right file there...
> I didn't use tftp to load. Here's what I do to install.
> at boot
> i hit ctrl + c
> at Redboot> prompt I type fconfig boot_script_data
> then type in:
> Load ramdisk.gz
> Load zImage.gz
> exec and then hit enter and write to flash
> then I load teh files as directed via ymodem and then run the exec -c
> "console=ttyS0........."
Where do you see the need for writing boot_script_data yourself in the
instructions here
http://d-i.alioth.debian.org/manual/en.armel/ch05s01.html ?
Could you report what you have now in boot_script_data ?
A+
--
JFS.
--
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/2010110614...@hohenhole.jfs.dt
On Sat, Nov 06, 2010 at 09:07:37PM -0700, Jose Solorio wrote:
> At the end of the installation installation its ask's me if I want to reboot
> or if I want to go back. I guess its my fault for using two different
> instructions. I followed the instruction from this vid tutorial
> http://www.youtube.com/watch?v=eEgVSlLXw5g.
I don't see the need to touch the boot_script_data at 6:37, and I
believe that loading both .pkg and initrd + zImage is redundant.
In my understanding, .pkg is to flash the firmware from the Ipstor
interface and the two other files are to boot it by manualy loading
what is needed. You shouldn't need to do both (though doing it seems
harmless).
> After getting to a certain part I continued reading he instructions
> on the debian site. Initially what I had done when the nas was still
> working with Ipstor was 1. load the firmware ss4000e.pkg from the
> debian site. 2. load ramdisk.gz and zImage from debian site via
> ymodem.
Steps 1 and 2 are probably redundant (at least in my understanding. I
installed mine last year by only loading initrd/zimage by tftp.)
> After I reboot, this is what I get:
>
> +No network interfaces found
>
> EM-7210 ver.T04 2005-12-12 (For ver.AA)
> == Executing boot script in 1.000 seconds - enter ^C to abort
> RedBoot> load ramdisk.gz
> Using default protocol (TFTP)
> Can't load 'ramdisk.gz': invalid parameter
> RedBoot> load zImage
> Using default protocol (TFTP)
> Can't load 'zImage': invalid parameter
> RedBoot> exec
> Base address unknown - use "-b" option
> RedBoot>
Yes, the problem occurs at 9:36 in your vid : your exec is exec'ing
nothing...
Could you try to enter this line at the above RedBoot prompt :
exec -c "console=ttyS0,115200 rw root=/dev/md0 mem=256M@0xa0000000" -r 0x01800000
(or without the "-r ..." parameter.)
Warning : replace "/dev/md0" with your real root device if it's
different. (The vid takes the first raid array for the root fs,
so I assume it's md0, but not sure.)
If the nas boot normaly with one of these lines, we should figure a
way to get it back in the boot_script_data to boot automatically.
So, does it work ?
> When I ctrl+c into the nas and type fconfig boot_script_data this is what i
> get:
>
> +No network interfaces found
>
> EM-7210 ver.T04 2005-12-12 (For ver.AA)
> == Executing boot script in 1.000 seconds - enter ^C to abort
> ^C
> RedBoot> fconfig boot_script_data
> boot_script_data:
> .. load ramdisk.gz
> .. load zImage
> .. exec
> Enter script, terminate with empty line
> >>
I don't understand why do you do this at the begining of the vid ? You
type fconfig to edit boot_script_data, but you cancel it with "n".
Don't type fconfig at first ;)
Hih,
--
JFS.
--
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/20101107152...@hohenhole.jfs.dt
> Here is a vid on what I am doing exactly. Thanks for all your help so far.
> http://www.youtube.com/watch?v=7Op0AUJDpQQ
Tkx, it helps.
A+
--
JFS.
--
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/20101107153...@hohenhole.jfs.dt
On Mon, Nov 08, 2010 at 02:26:51PM -0800, Jose Solorio wrote:
> Ok so I tried what you had said and get the following
>
> RedBoot> exec -c "console=ttyS0,115200 rw root=/dev/md0 mem=256M@0xa0000000"
> -r 0x01800000
> Base address unknown - use "-b" option
Could you try this one :
exec -b 0x01008000 -c "console=ttyS0,115200 rw root=/dev/md0 mem=256M@0xa0000000" -r 0x01800000
But I'm not sure if it will work :/
RedBoot needs the kernel's address in memory (the "-b"), but I don't
know where your boot script loaded it (AFAIR from the vid, you haven't
any address specified, so according to redboot's manual "If not
specified, the address associated with the image in the FIS directory
will be used.")
If it doesn't work, perhaps could you try to force kernel and initrd
at these addresses beforce execing :
fis load -b 0x01800000 ramdisk.gz
fis load -b 0x01008000 zImage
+ exec like before once again.
Hih,
--
JFS.
--
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/1289288043....@fulci.jfs.dt
> (Please keep trafic on the list as I may be useful for others...)
^^^
Please read: "it"
A+
--
JFS.
--
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/20101109222...@hohenhole.jfs.dt
(Please keep trafic on the list as I may be useful for others...)
On Tue, Nov 09, 2010 at 01:25:49AM -0800, Jose Solorio wrote:
> I really think we are making progress here. This is what I get now:
Yes, I'm glad to see that we are a step further ! :-)
> RedBoot> fis load -b 0x0180000 ramdisk.gz
> RedBoot> fis load -b 0x0100800 zImage
> RedBoot> exec -c "console=ttyS0,115200 rw root=/dev/md0 mem=256M@0xa0000000"
> -r 0x01800000
So, we know this combination is working, good point.
[...]
> :( but then when I power off and back on I get the same OL...
> EM-7210 ver.T04 2005-12-12 (For ver.AA)
> == Executing boot script in 1.000 seconds - enter ^C to abort
> RedBoot> load ramdisk.gz
> Using default protocol (TFTP)
> Can't load 'ramdisk.gz': invalid parameter
> RedBoot> load zImage
> Using default protocol (TFTP)
> Can't load 'zImage': invalid parameter
> RedBoot> exec
> Base address unknown - use "-b" option
> RedBoot>
This was expected behaviour, don't worry ;-)
We are addressing one step at a time, and for now nothing of the
suitable boot commands is written permanently in the nas flash ; we
just entered them by hand.
> Please let me know what you think :)
Well, now we know how to boot from your setup and have to write
permanently the commands to boot in the boot script for the nas to
boot automatically at power up.
It's a matter of editing boot_script_data for real, with fconfig
command.
But I haven't (easily) access to my RedBoot at this time, so you're a
bit on your own to figure out exactly how to do this...
Could you run the fconfig command in RedBoot to show its help and
report it here ?
We will try to figure out how to write these command.
I believe it will be something like this :
RedBoot> fconfig boot_script_data
boot_script_data:
.. load ramdisk.gz
.. load zImage
.. exec
Enter script, terminate with empty line
>> fis load -b 0x0180000 ramdisk.gz
fis load -b 0x0100800 zImage
exec -c "console=ttyS0,115200 rw root=/dev/md0 mem=256M@0xa0000000" -r 0x01800000
(empty line)
and it will ask to save (I suppose, but note sure).
Could you/want you try this ?
(But please be carefull if/when writing something to the nas : better
safe than sorry, so it's worth reading the help before doing.)
If it works, we'll be another step further.
But I suspect in the same time that we'll be facing another problem :
the root device. I suspect it's not set properly because whithout root
device, you'll get at best a minimal BusyBox shell and at worse a
kernel panic, two things which you have had...
On this machine, the kernel doesn't rely on the supplied root device
in the command line (specifing /dev/md0 hasn't any effect as you can
see).
Instead, your kernel searchs it on /dev/sda2, so I suspect something
went wrong in the process of writing the root device to the system :
- it should be /dev/mdX, right ?
- and /dev/sda2, AFAIU, is a default hard coded fallback in the script
which do root setting, when it can't find the right root device...
This leads me to several questions :
- is the root device setup properly ? (I believe not) ;
(Here, booting with the D-I in rescue mode can help fix the problem,
by reinstalling the kernel.)
- but can one setup root on raid5 ? I'm not sure. AFAICT, you've
configured 3 raid5 array, but on i386/amd64 arch, root can't be
setup on raid5 for now (only 1,0 or 10).
I don't know if the boot from flash on ARM makes any difference.
Anyone on the list who knows ?
(If not possible, you should make a little /boot raid1 (or 10)
partition on the 4 disks and reshape the partitioning from that
point :-/ I'm afraid that means a reinstall...)
> and again thank you very very much for all your help thus far.
You're welcome, it's what mailing lists are for, and I was also happy
to find this one a year ago :-)
Hih,
--
JFS.
--
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/20101109222...@hohenhole.jfs.dt
Make sure that the system can be booted with the partitioning scheme
you are planning. In general it will be necessary to create a separate
file system for /boot
when using RAID for the root
(/
) file system.
Most boot loaders
do support mirrored (not striped!) RAID1, so using for example RAID5 for
/
and RAID1 for /boot
can be
an option.
On Tue, Nov 09, 2010 at 11:24:54PM +0100, JF Straeten wrote:^^^
> (Please keep trafic on the list as I may be useful for others...)
Please read: "it"
A+
--
JFS.
On Wed, Nov 10, 2010 at 12:20:58AM -0800, Jose Solorio wrote:
> Ok after countless hours (days/weeks) I am happy to say that we have
> success!! :)
Nice to read that :-)
> Again I thank you for all the help you gave JFS. I hope this helps someone
> else along the way, I think the key is that I messed with the
> boot_script_data and from what I understand now your not supposed to do
> THAT!! haha.
Yes, it was exactly the problem.
I wish you have a lot of fun with your Debian nas now ! :-)
A+
--
JFS.
--
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/20101110085...@hohenhole.jfs.dt