Replacing drives with larger drives - 5Big Network 2

[ChrilleCrull]

This is what I got from the command.

Marvell>> printenv
printenv
baudrate=115200
loads_echo=0
rootpath=/mnt/ARM_FS/
netmask=255.255.255.0
stderr=serial
console=console=ttyS0,115200 mtdparts=spi_flash:0x80000@0(uboot)ro,0x300000@0x100000(root)
mainlineLinux=no
CASset=min
enaMonExt=no
enaCpuStream=no
enaWrAllo=no
pexMode=RC
disL2Cache=no
setL2CacheWT=yes
disL2Prefetch=yes
enaICPref=yes
enaDCPref=yes
sata_dma_mode=yes
MALLOC_len=1
ethprime=egiga0
netbsd_en=no
vxworks_en=no
bootargs_root=root=/dev/nfs rw
bootargs_end=:::DB88FXX81:eth0:none
image_name=uImage
standalone=fsload 0x2000000 $(image_name);setenv bootargs $(console) root=/dev/mtdblock0 rw ip=$(ipaddr):$(serverip)$(bootargs_end) $(mvPhoneConfig); bootm 0x2000000;
disaMvPnp=no
ethmtu=1500
eth1mtu=1500
mvPhoneConfig=mv_phone_config=dev0:fxs,dev1:fxs
mvNetConfig=mv_net_config=(00:11:88:0f:62:81,0:1:2:3),mtu=1500
usb0Mode=host
yuk_ethaddr=00:00:00:EE:51:81
netretry=no
rcvrip=169.254.100.100
loadaddr=0x02000000
autoload=no
enaAutoRecovery=yes
start_lump=lump 3
pre_lump=lump 1
resetdisk=ide reset
bootdelay=0
boot_fail=lump
kernel_addr=0x800000
productType_env=BIG5_KW
primaryPart=6
secondaryPart=A
boot_usb=usb start;usbboot 0x800000 0:1;bootm;
resetFlag_env=0
bootargs=console=ttyS0,115200 root=/dev/sda7 ro reset=0 productType=PRO_KW
bootcmd=run disk_disk
boot_disk10=disk ${kernel_addr} 5:${primaryPart}; setenv rootfs /dev/sde7;
boot_disk9=if disk ${kernel_addr} 6:${primaryPart}; then setenv rootfs /dev/sdd7; else run boot_disk10; fi
boot_disk8=if disk ${kernel_addr} 1:${primaryPart}; then setenv rootfs /dev/sdc7; else run boot_disk9; fi
boot_disk7=if disk ${kernel_addr} 2:${primaryPart}; then setenv rootfs /dev/sdb7; else run boot_disk8; fi
boot_disk6=if disk ${kernel_addr} 3:${primaryPart}; then setenv rootfs /dev/sda7; else run boot_disk7; fi
boot_disk5=if disk ${kernel_addr} 5:${secondaryPart}; then setenv rootfs /dev/sde7; else run boot_disk6; fi
boot_disk4=if disk ${kernel_addr} 6:${secondaryPart}; then setenv rootfs /dev/sdd7; else run boot_disk5; fi
boot_disk3=if disk ${kernel_addr} 1:${secondaryPart}; then setenv rootfs /dev/sdc7; else run boot_disk4; fi
boot_disk2=if disk ${kernel_addr} 2:${secondaryPart}; then setenv rootfs /dev/sdb7; else run boot_disk3; fi
boot_disk1=if disk ${kernel_addr} 3:${secondaryPart}; then setenv rootfs /dev/sda7; else run boot_disk2; fi
boot_disk=if test ${resetFlag_env} -eq 0; then run boot_disk1; else run boot_disk6; fi
disk_disk=run boot_disk; setenv bootargs console=ttyS0,115200 root=${rootfs} ro reset=${resetFlag_env} productType=${productType_env}; bootm ${kernel_addr};
ethaddr=00:D0:4B:8B:9C:B1
eth1addr=00:D0:4B:8B:A1:22
ethact=egiga0
ipaddr=192.168.0.252
ncip=192.168.0.85
serverip=192.168.0.85
stdin=nc
stdout=nc

Environment size: 2689/4092 bytes
Marvell>>

[fvdw]

oke, your uboot doesn't support gpt, there should be a line with this

Code: Select all

uboot_capabilities=gpt,lba64

and you have an spi flash, do you already think over the options mentioned ?

[ChrilleCrull]

Can I use the nr 1 option with a 1TB disk ?

[fvdw]

Can I use the nr 1 option with a 1TB disk ?

yes, you can

ps On this moment I do not have a uboot version for 5big2. My 5big2 has a nand flash
I could compile an spi version but it will be untested...so risk

[fvdw]

research my archive and I found the spi version.

you can find it here

https://plugout.net/viewtopic.php?f=26&t=1402&p=23774&hilit=u+boot+5big2#p23774

Read the post there carefully
unpack the zip archive, the uboot image is the file u-boot-5big2-spi-3416-1517.bin
The archive contains also a md5sum of the file so you can check if it hasn't gone corrupt in transfer

You can use fvdw-sl console to flash you uboot. However if you do that it is fully at your own risk !!
If it fails and your nas no longer boots don't blame me.

[ChrilleCrull]

Great i'll try option one to begin with.

I have two of these 5big2 but booth of them does not support GPT I tested the other one just a few minutes ago in U-boot console and got the same result.
The other one is running with 5x1TB in raid 0.

So my hopes was to get this one to work with 5x4TB in raid5.

Both my 5big2 is from 2010.

I will test out option 1 to begin with just to play it safe, I have a big windows 2008 fileserver that is in critical condition so i need the NAS to store the files temporaly till I sort things out. After that i'm not a stranger to test that spi version on one of my 5big2 it can be exiting or a nice blue bedlight in worst case :-)

[ChrilleCrull]

I would never blame you for my actions, I don´t like limitations so when you offer a chance to break the limits then i'm willing to take the risk, My belief is that everything thats old can be uppgraded and perform a little better to prolong the lifespan.
If it doesnt work then we at least tried :-D

Better to fail hard than never try to win. :beer:

But first option one and rescue my files on fileserver. :-)

[fvdw]

:thumbup oke good approach

[naspa]

Good luck with your 2010 5big2 experiments. Option 1 (first disk is an MBR disk less than or equal to 2TB and boots the fvdw-sl firmware, and other disks are GPT disks used for data with, for example, 4TB each) will probably get you enough space. Option 2 (trying to upgrade Uboot in one of your 2010 5big2's) sounds exciting - risky but exciting.
For your consideration, Option 3 is to use Hybrid MBR-GPT partitioning on the first disk. That way Uboot can boot (using an MBR view of the disk to access the subset of partitions it needs), and the fvdw-sl firmware (which supports GPT) can see all partitions on the first disk, including a larger-than-2TB data partition.

Owners of 5big1 and 2big1 face the same problem as your early version of the 5big2, but they don't have an Option 2 - only Option 1 and (I would claim) Option 3. I intend to demonstrate Option 3 when I get time (late 2018 or early 2019?), but I am sure it can be made to work.

Option 1 should be fine for most 5big1 and 2010 5big2 owners because there can still be 4 GPT disks, but 2big1 owners would be severely limited by Option 1, so Option 3 Hybrid MBR-GPT partitioning offers them real hope.

Mac users with Macs whose (Apple 'Bootcamp') Windows-drivers and older Apple hardware require MBR booting when booting into Windows, are very familiar with Hybrid partitioning. We live by it every day! (Recent Macs supports GPT Windows booting, but all of my Macs require Hybrid partitioning.)

For anyone interested in the subject, Rod Smith's GPT fdisk tool "gdisk" - and the web pages that describe it - are pure gold.
http://rodsbooks.com/gdisk/
http://rodsbooks.com/gdisk/hybrid.html

And if you think that the partitions needed by Uboot can't be kept within the first 2TB of a large disk with a large (> 2TB) data partition, then remember that the partitions do not have to be physically laid out on the disk in the same order as their entries appear in the partition table, so there is more flexibility to make this work than many people realise.

Anyway - just an idea to consider. I hope your own experiences with Option 1 (MBR disk 1, GPT disks 2-5) and possibly Option 2 (upgrade Uboot in your 2010 5big2) are positive.
-- David (naspa)

[Jocko]

Hi naspa,

There is an old topic about hybrid disk

See : https://plugout.net/viewtopic.php?f=4&t=1109&hilit=hybrid