Re: ss4000-e Install how to set up so it boots
Hi José,
(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.
Reply to: