Please Help, 5Big Network 2 upgrade attempt gone wrong

[hvymetal86]

Ran through it again (swear I did all the same things!) and it works with the first disk. I didn't go through the first setup part of the web access https://drive.google.com/uc?export=view&id=0B5x7lw1_KgjVdDc4ZENFV2EzUW8
And just turned it off to repeat on the next drive.

Here's the full log of commands and output in case it is needed going forward or that it might help anyone else doing this:
https://drive.google.com/uc?export=view&id=0B5x7lw1_KgjVTGh3NmUxZ2hoMnc

[fvdw]

did you run udevstart to update the device nodes ?
The standalone kernel has a standard set of device nodes but those needs to be corrected per device as assignment of bus number is different.
I think you did not unless you have uploaded the static udevstart binary as udevstart is not standard included in the standalone kernel suplied with the fvdw-sl console.
As the 5big2 has a funny assignment of bus number for each disk the device nodes must be adapted otherwise you will not access the right disks as the device node is pointing to another disk. That may explain why you can set up only when having a disk in slot 1

Attached a new standalone kernel that you can try.
This kernel will activate the usb port on the device and also runs a check on the device nodes for the internal disk and correct them dependent on the number of disks installed. You can also do that when the kernel is running by using the command "/sbin/udevstart"

If you want to connect an usb disk connect it to the usb port and it should be detected by the kernel and the driver should be loaded automatic. However you must mount the partition on the usb disk manually.
Before being able to do that that you need to create a device node for the usb disk.
The udevstart command doesn't find and set it automatic on the 5big2 this device node, probably because we use in the kernel a device id starting with sei or sej (need to look how to solve this later).
For the moment you need to set it up manully.
First determine the major and minor block to use for the device node, give in the telnet this command

Code: Select all

cat /proc/partitions

This will list all partitions found on the installed disks including connected usb disks.
This is an example of what you will see, note that on this 5big2 system only 3 disks are installed

Code: Select all

root@fvdw-sta-kirkwood:/dev # cat /proc/partitions
major minor  #blocks  name

  31        0       1024 mtdblock0
  31        1      16384 mtdblock1
  31        2     244736 mtdblock2
   8        0  976762584 sdc
   8        1     524288 sdc1
   8        2     524288 sdc2
   8        3     524288 sdc3
   8        4       4096 sdc4
   8        5     786432 sdc5
   8        6       8192 sdc6
   8        7     524288 sdc7
   8        8  973865671 sdc8
   8       16  976762584 sdb
   8       17     524288 sdb1
   8       18     524288 sdb2
   8       19     524288 sdb3
   8       20       8192 sdb4
   8       21     786432 sdb5
   8       22       8192 sdb6
   8       23     524288 sdb7
   8       24  973860551 sdb8
   8       32 2930266584 sda
   8       33     524288 sda1
   8       34     524288 sda2
   8       35     524288 sda3
   8       36       8192 sda4
   8       37     786432 sda5
   8       38       8192 sda6
   8       39     524288 sda7
   8       40 2927364551 sda8
   8       48   39070079 sei
   8       49   39062016 sei1

In this example the usb disk has name sei
Now if you want to mount partition 1 of that disk (sei1) then create the device node accordingly using the major and minor number

Code: Select all

root@fvdw-sta-kirkwood:/dev # mknod -m 666 sei1 b 8 49

Now you will be able to mount it if that partition is formatted with a file system supported by the kernel.

Code: Select all

mkdir /sei1
mount /dev/sei1 /sei1

[hvymetal86]

I don't quite understand what I need to be doing here with udevstart. I've been trying to create the RAID5 array once I have access to the web interface, not via command line on the drives ahead of time, but that's what it seems like udevstart is for? Or am I misunderstanding that and taking parts of this thread Jocko linked, out of context? viewtopic.php?f=26&t=2209&start=20#p18671

As for larger files over tftp, I don't think I'll have an issue because the multiple times I've used that to copy over the image for partition 8 (114MB) I've never had a problem.

I've used linux command line before, but I'm not very good at it. Here's my best guess of the steps I need to take out of your newest post are:

• Put all 5 disks in the 5Big2 (they're all prepped the way my last post listed)
• Download and start the standalone kernel with the new file provided last post. (it contains udevstart)
• Run /sbin/udevstart

If I'm not using the USB part that's all that's necessary?

[hvymetal86]

Ran the new Standalone Kernel with all disks inserted. Here's the /proc/partitions and ls -l outputs:

Code: Select all

root@fvdw-sta-kirkwood:/ # cat /proc/partitions
major minor  #blocks  name

  31        0       1024 mtdblock0
  31        1      16384 mtdblock1
  31        2     244736 mtdblock2
   8        0 3907018584 sdc
   8        2 3904895815 sdc2
   8        5     262144 sdc5
   8        6      16384 sdc6
   8        7      16384 sdc7
   8        8     905216 sdc8
   8        9     905216 sdc9
   8       10      16384 sdc10
   8       16 3907018584 sdb
   8       18 3904895815 sdb2
   8       21     262144 sdb5
   8       22      16384 sdb6
   8       23      16384 sdb7
   8       24     905216 sdb8
   8       25     905216 sdb9
   8       26      16384 sdb10
   8       32 3907018584 sda
   8       34 3904895815 sda2
   8       37     262144 sda5
   8       38      16384 sda6
   8       39      16384 sda7
   8       40     905216 sda8
   8       41     905216 sda9
   8       42      16384 sda10
   8       48 3907018584 sde
   8       50 3904895815 sde2
   8       53     262144 sde5
   8       54      16384 sde6
   8       55      16384 sde7
   8       56     905216 sde8
   8       57     905216 sde9
   8       58      16384 sde10
   8       64 3907018584 sdd
   8       66 3904895815 sdd2
   8       69     262144 sdd5
   8       70      16384 sdd6
   8       71      16384 sdd7
   8       72     905216 sdd8
   8       73     905216 sdd9
   8       74      16384 sdd10
root@fvdw-sta-kirkwood:/ # ls -l /dev/sd[abcde]
brw-rw----    1 root     root        8,  32 May 21 03:42 /dev/sda
brw-rw----    1 root     root        8,  16 May 20 21:12 /dev/sdb
brw-rw----    1 root     root        8,   0 May 21 03:42 /dev/sdc
brw-rw----    1 root     root        8,  64 May 21 03:42 /dev/sdd
brw-rw----    1 root     root        8,  48 May 21 03:42 /dev/sde

My understanding started out that the ls -l output is showing the problem in that they don't go in the right order (Jocko specified sdc - sdb - sda -sde -sdd [from left to right]) even though they appear to be correct in the /proc/partitions file.

I then ran /sbin/udevstart, and here are the same outputs again:

Code: Select all

root@fvdw-sta-kirkwood:/ # cat /proc/partitions
major minor  #blocks  name

  31        0       1024 mtdblock0
  31        1      16384 mtdblock1
  31        2     244736 mtdblock2
   8        0 3907018584 sdc
   8        2 3904895815 sdc2
   8        5     262144 sdc5
   8        6      16384 sdc6
   8        7      16384 sdc7
   8        8     905216 sdc8
   8        9     905216 sdc9
   8       10      16384 sdc10
   8       16 3907018584 sdb
   8       18 3904895815 sdb2
   8       21     262144 sdb5
   8       22      16384 sdb6
   8       23      16384 sdb7
   8       24     905216 sdb8
   8       25     905216 sdb9
   8       26      16384 sdb10
   8       32 3907018584 sda
   8       34 3904895815 sda2
   8       37     262144 sda5
   8       38      16384 sda6
   8       39      16384 sda7
   8       40     905216 sda8
   8       41     905216 sda9
   8       42      16384 sda10
   8       48 3907018584 sde
   8       50 3904895815 sde2
   8       53     262144 sde5
   8       54      16384 sde6
   8       55      16384 sde7
   8       56     905216 sde8
   8       57     905216 sde9
   8       58      16384 sde10
   8       64 3907018584 sdd
   8       66 3904895815 sdd2
   8       69     262144 sdd5
   8       70      16384 sdd6
   8       71      16384 sdd7
   8       72     905216 sdd8
   8       73     905216 sdd9
   8       74      16384 sdd10
root@fvdw-sta-kirkwood:/ # ls -l /dev/sd[abcde]
brw-rw----    1 root     root        8,  32 May 21 03:42 /dev/sda
brw-rw----    1 root     root        8,  16 May 20 21:12 /dev/sdb
brw-rw----    1 root     root        8,   0 May 21 03:42 /dev/sdc
brw-rw----    1 root     root        8,  64 May 21 03:42 /dev/sdd
brw-rw----    1 root     root        8,  48 May 21 03:42 /dev/sde

There was no change (I confirmed this using the compare plugin in Notepad++). So does that mean they're set correctly already? I haven't tried booting it normally with all 5 drives in now after I went back and "prepped" each drive as listed earlier.

[Jocko]

Hi hvymetal86,

Indeed at the beginning of the topic, I warned you about the dev nodes issues and asked you to use udevstart.

I did not repeat it as I believed that you use fvdw-sl console with only one disk plugged and then the sda dev node in /dev is always in accordance with the reported settings from /proc/partitions (minor =0).

With your last post, there is an amazing thing : you got a right state without any dev nodes updating :scratch (see fvdw remark)

Anyhow the valid settings are in /proc/partitions and the dev nodes minor value must be the same. This is important when you use a dev node in a command line (to be sure that the command line runs on the right device!!!)

[fvdw]

:disapprove

read my post, the new standalone kernel runs udevstart when booting the kernel and set up the device nodes correctly for the internal disks. So the output that hvymetal get is as expected.
The only device node you have to make is for the usb disk.


PS. If you run the previous standalone kernel then you will see wrong dev nodes definitions

[fvdw]

...and remember the dev nodes definiton is dependent on number of disk installed. That is why it worked ok with only one disk in slot 1 with the previous kernel and not with more disks installed

[Jocko]

:whistle

Ok, I misread pour post. So with the last standalone kernel version, run again udevstart is only required after plugging an usb disk

[hvymetal86]

I did not repeat it as I believed that you use fvdw-sl console with only one disk plugged and then the sda dev node in /dev is always in accordance with the reported settings from /proc/partitions (minor =0).

I did use fvdw-sl console and old firmware with only one disk plugged in (at a time) until the newest firmware fvdw just provided. I repeated the process here 5 times. With only one disk in slot 1 each time with the older firmware.

After my last post and before any replies I tried starting the NAS normally into webaccess and setting it and the RAID up. I let the raid setup overnight and it still wasn't done this morning. Ended up turning it off and back on, back into webaccess, where it prompted for a firmware update from 2.2.3 (the version from the images) to the newest (2.2.10.1) which I accepted. It seems to have failed that and now shows as nas-rescue in the LaCie Network Assistant and won't load webaccess.

I'm ok with having to start this all over again to do it right. Either I failed to make my goals clear enough and or I'm failing to understand all of the instructions you guys are giving to me (probably from my own ignorance :hammerhead). Here's what I need to get to:
Newest LaCie Firmware/OS running (2.2.10.1) with 5 disks installed and those disks configured in a RAID5 array of 16TB of space, manageable through webaccess.
Ideally I want to configure the RAID5 array in the webaccess OS because it will have to be managed through that going forward and seeing how the images we have available are for 2.2.3 the only way to get to 2.2.10.1 is to update after the webaccess is working and I don't know if a RAID5 created outside the webaccess will survive that (and if it doesn't I'd have to re-make it then inside webaccess).
I seem to need to step by step commands (like here) to understand, sorry :corner

[fvdw]

:whistle

Ok, I misread pour post. So with the last standalone kernel version, run again udevstart is only required after plugging an usb disk

"There is no need to run udevstart again after plugging in the usb disk, seesm that udevstart doesn't find drives starting with "se" The standalonekernel runs udevstart during boot.