A detailed, reproducible recovery procedure for a LaCie 2big NAS that no longer boots normally after a failed firmware update, reset, or corrupted HDD-resident firmware.
This guide is based on a real recovery of a LaCie 2big NAS with:
- internal product ID:
2bignetwork2r - hardware ID:
nas2big - Marvell Kirkwood platform
- two HDDs in the original LaCie system layout
- original firmware around
3.1.4.x - both HDD firmware slots containing a corrupted
uImage - healthy U-Boot and healthy NAND rescue system
The recovery was completed without a serial cable, JTAG, NAND programming, or disk replacement. U-Boot was reached over Ethernet using CLUNC/LUMP, a known-good kernel and custom RAM rescue initramfs were booted over TFTP, and the HDD-resident firmware was repaired over SSH.
Warning
This procedure includes commands that can destroy filesystems if used on the wrong device. Read the entire relevant section before running commands.
If the data on the NAS is important, do not blindly reproduce the destructive steps in this guide. The system partitions and the user-data partition are separate, but a typo involving /dev/sda8, /dev/sdb8, or the wrong RAID device can destroy user data.
Important
Do not write to NAND unless you have independently established that NAND is actually damaged. The recovery documented here did not require nand erase, nand write, bubt, or replacement of U-Boot.
- Introduction
- Super-quick recovery guide
- How the LaCie 2big boots
- Repository layout and files
- Tools and utilities used
- Choose the recovery network topology
- Prepare the Windows recovery PC
- Provide DHCP when needed
- Start the CLUNC console
- Inspect U-Boot before writing anything
- Start the TFTP and HTTP servers
- Boot the custom RAM rescue system
- Connect to the RAM rescue system over SSH
- Inspect disks, partitions, and RAID
- Diagnose the firmware slots
- Repair
root_1 - First normal boot and persistent
/varrepair - Repair
root_2 - Verify the recovered system
- Restore DHCP, time, and normal networking
- Optional firmware upgrade
- Troubleshooting
- Commands you should not use casually
- Command cheat sheet
- Known-good reference values from the recovered unit
- Appendix: network ports
This guide is aimed at a LaCie 2big NAS that exhibits one or more of the following:
- front LED eventually becomes solid red;
- both disks appear physically healthy but the NAS does not boot;
- the NAS no longer gets a DHCP address;
- the web interface is unreachable;
- LaCie Network Assistant (LNA) cannot find or restart the NAS;
- an LNA firmware update stalls at Step 2 of 3 or Step 3 of 3;
- a factory reset leaves the device less functional than before;
- U-Boot is alive, but normal HDD boot fails;
- the NAND rescue image is healthy, but the HDD firmware kernel is corrupted.
The exact recovered unit initially ran firmware 3.1.4.6. A known-good official 3.1.4.7 firmware image was used as the base for recovery.
The key discovery was that the NAS hardware was mostly fine:
- both HDDs were detected;
- RAID metadata for the firmware partitions was healthy;
- both disks participated normally in RAID1;
- NAND U-Boot was functional;
- the NAND rescue kernel passed its U-Boot CRC check.
But the HDD-resident firmware kernels were bad.
Both firmware slots contained:
Linux-2.6.31.14-svn7972
and the corresponding /boot/uImage failed the U-Boot data CRC check.
The known-good kernel from firmware 3.1.4.7 was:
Linux-2.6.31.14-svn8060
and its U-Boot image CRC was valid.
This is why the device looked "dead" even though the bootloader, CPU, RAM, Ethernet, HDDs, and NAND rescue system were still usable.
The recovery strategy is deliberately conservative:
- Do not touch NAND.
- Boot a temporary Linux system entirely in RAM.
- Inspect both HDDs.
- Assemble the existing system RAID1 arrays.
- Repair the first firmware slot.
- Boot the normal LaCie OS.
- Repair persistent configuration if required.
- Repair the second firmware slot.
- Only after the base system is stable, consider a normal firmware upgrade.
This model's U-Boot can be controlled over Ethernet using LaCie's CLUNC/LUMP mechanism.
That means the entire procedure can be performed with:
- the NAS;
- its two original disks;
- one Windows PC;
- one Ethernet connection;
- the repository files described below.
A serial adapter is still useful for deep debugging, but it is not required for this recovery.
The recovered NAS did not contain data that needed to be preserved, so recreating the data volume later was acceptable.
If your data matters:
- do not initialize or recreate the data RAID;
- do not format partition 8;
- do not blindly run commands copied from this document;
- make block-level backups of both drives before performing destructive operations.
The firmware slots described in this guide are small system partitions. The large data partition is separate.
This section is only an overview. Follow the linked detailed sections for the actual commands.
- Connect a Windows PC and the LaCie to the same Ethernet segment. For a direct PC-to-NAS connection, configure the PC as
192.168.11.200/24. See Prepare the Windows recovery PC. - If the normal LaCie firmware needs DHCP and your network does not already have it, run the local Windows DHCP server in
dhcpsrv2.5.2. See Provide DHCP when needed. - Start the CLUNC console and power-cycle the LaCie until you get
Marvell>>. See Start the CLUNC console. - Start the local TFTP server from
tftp_http. - From U-Boot, TFTP-load
uImageanduInitrd_lacie_ssh. - Boot the temporary rescue Linux entirely in RAM.
- Connect over SSH:
Password:
ssh -o HostKeyAlgorithms=+ssh-rsa root@192.168.11.202
lacie-recovery. - Run
busybox mdev -sandcat /proc/partitions; confirm both disks and all partitions exist. - Assemble
md4,md5, andmd6withmdadm. - Inspect
root_1,root_2, and/varread-only. - Replace the broken
root_1with the known-good3.1.4.7rootfs while preserving its filesystem UUID. - Reboot normally.
- If the Dashboard hangs or
/inforeturns HTTP 500, repair stale/var/0persistent state. - Boot the RAM rescue system again using Start the CLUNC console.
- Repair
root_2by copying the workingroot_1filesystem to it at file level, preservingroot_2's own filesystem UUID. - Reboot normally and verify the web UI, disks, RAID, clock, and repeated boot.
- Only then consider the supported firmware upgrade path:
3.1.4.7 -> 4.1.9.2 -> 4.3.19.7.
The LaCie 2big NAS does not keep the entire normal operating system in NAND.
On the recovered unit, NAND contained approximately:
mtd0— ~1 MiB — U-Boot;mtd1— ~16 MiB — rescue kernel;mtd2— ~128 MiB — rescue root filesystem;- remaining NAND — reserved/unused for this purpose.
The normal LaCie OS lives on the two HDDs.
NAND
|
+-- U-Boot
+-- rescue kernel
+-- rescue rootfs
HDDs
|
+-- boot metadata
+-- root_1 firmware slot
+-- root_2 firmware slot
+-- /var persistent state
+-- swap
+-- large data partition
A device can therefore have a perfectly healthy bootloader and rescue image while being unable to boot the normal firmware.
Each 4 TB drive used the same GPT structure:
| Partition | Approx. size | Purpose |
|---|---|---|
sda1 / sdb1 |
1 MiB | GRUB/core area |
sda2 / sdb2 |
192 MiB | boot/rescue-related area |
sda3 / sdb3 |
1 MiB | boot metadata / nv data |
sda4 / sdb4 |
1.5 GiB | root_1 RAID1 |
sda5 / sdb5 |
1.5 GiB | root_2 RAID1 |
sda6 / sdb6 |
1 GiB | /var RAID1 |
sda7 / sdb7 |
256 MiB | swap |
sda8 / sdb8 |
~3.9 TB | data/storage |
The kernel reported:
major minor #blocks name
8 0 3907018584 sda
8 1 1024 sda1
8 2 196608 sda2
8 3 1024 sda3
8 4 1572864 sda4
8 5 1572864 sda5
8 6 1048576 sda6
8 7 262144 sda7
8 8 3902362439 sda8
8 16 3907018584 sdb
8 17 1024 sdb1
8 18 196608 sdb2
8 19 1024 sdb3
8 20 1572864 sdb4
8 21 1572864 sdb5
8 22 1048576 sdb6
8 23 262144 sdb7
8 24 3902362439 sdb8
They are not mirrors of one another.
root_1 = md4 = RAID1(sda4, sdb4)
root_2 = md5 = RAID1(sda5, sdb5)
So sda4 mirrors sdb4, while sda5 mirrors sdb5. root_1 and root_2 can contain different firmware versions.
The recovered system used saved_entry=0, corresponding to root_1.
The /var RAID array is:
md6 = RAID1(sda6, sdb6)
On the recovered unit it contained a layout similar to:
/var filesystem
├── 0/
│ ├── etc/
│ ├── var/
│ └── root/
├── tmp/
└── lost+found/
A fresh root filesystem can still fail if stale state under /var/0 is incompatible with it. This became important later in the recovery.
The working recovery project was arranged approximately like this:
CLUNC/
├── 2bignetwork2r_3.1.4.7.capsule
├── clunc_win.py
├── start_clunc.bat
├── dhcpsrv2.5.2/
│ ├── dhcpsrv.exe
│ ├── dhcpwiz.exe
│ ├── dhcpsrv.ini
│ ├── dhcptrc.bak
│ ├── dhcptrc.txt
│ ├── readme.txt
│ └── wwwroot/
└── tftp_http/
├── mkfs.ext2_lacie
├── rootfs_3.1.4.7.tar.lzma
├── start_lacie_http_server.bat
├── start_tftp_fixed.bat
├── tftp_server.py
├── uImage
└── uInitrd_lacie_ssh
Official LaCie firmware capsule used as the source of the known-good 3.1.4.7 system.
Observed size: 152,792,228 bytes.
Windows-compatible CLUNC/LUMP client used to communicate with LaCie's U-Boot over Ethernet.
Convenience launcher for the CLUNC client and network-console setup.
Known-good official 3.1.4.7 kernel image.
Linux-2.6.31.14-svn8060
U-Boot image total size: 7,177,764 bytes
U-Boot data size: 7,177,700 bytes
This image passed iminfo CRC verification.
Custom RAM rescue initramfs used for this procedure. Observed size: 7,525,266 bytes.
It provides BusyBox, mdadm, filesystem tools, OpenSSH sshd, and static rescue networking.
Credentials used:
user: root
password: lacie-recovery
Official 3.1.4.7 root filesystem extracted from the firmware capsule.
Observed project size: 68,381,967 bytes.
Known-good SHA1:
b42ab0be4216f5b6f6aa965b31ddae4d7c3c5b66
Always verify this before writing it to a firmware slot.
LaCie filesystem creation utility extracted from the firmware tooling. Observed size: 252,404 bytes.
Important caveat: it can require an mke2fs.conf that defines the LaCie-specific ext2_lacie profile. If it prints:
Your mke2fs.conf file does not define the ext2_lacie filesystem type.
Aborting...
stop; do not guess formatter options.
start_tftp_fixed.bat starts the local Python TFTP server from tftp_server.py.
start_lacie_http_server.bat starts a local HTTP server for larger recovery files.
The project also contains dhcpsrv2.5.2, the Windows DHCP Server by Uwe Ruttkamp.
Project information supplied with the utility:
- web: http://www.dhcpserver.de/
- author contact:
Uwe.Ruttkamp@gmx.net
The recovery used dhcpsrv.exe, dhcpwiz.exe, dhcpsrv.ini, and dhcptrc.txt. It can run as a Windows service.
Use it only when the recovery segment does not already have a DHCP server.
CLUNC interacts with LaCie U-Boot over Ethernet. It provides the equivalent of a bootloader console without a serial cable.
When you see:
Marvell>>
you are in U-Boot, not Linux and not Windows.
CLUNC/LUMP traffic used by the recovery environment includes UDP ports around 4446 and 6666. Allow the recovery scripts on the dedicated interface through Windows Firewall/simplewall.
We use U-Boot only for temporary actions: inspect environment, set temporary networking, TFTP-load a kernel/initramfs, verify them with iminfo, and boot them with bootm.
We intentionally avoid persistent bootloader modification.
TFTP is used because U-Boot supports it directly. The bootloader fetches uImage and uInitrd_lacie_ssh from the Windows PC.
Once rescue Linux is running, large files are transferred with HTTP. The recovery used TCP port 8000 for rootfs_3.1.4.7.tar.lzma and related utilities.
SSH is the main maintenance interface after the RAM rescue boots:
ssh -o HostKeyAlgorithms=+ssh-rsa root@192.168.11.202The old rescue SSH server offers an ssh-rsa host key, which current OpenSSH clients may reject unless explicitly enabled.
DHCP is not required for the custom RAM rescue, because the rescue boot arguments assign a static address.
DHCP becomes useful or necessary when booting the normal LaCie firmware, using LNA, or entering vendor update/recovery modes.
Use either an existing LAN DHCP server or the included dhcpsrv2.5.2. Never run two DHCP servers on the same broadcast segment unintentionally.
FTP is not TFTP. The legacy LaCie update mechanism may contact vendor infrastructure on FTP port 21. It is relevant to later firmware updating, not the base disk repair.
mdadmassembles and inspectsmd4,md5, andmd6.blkidrecords filesystem UUIDs.mountis used read-only first, read-write only for deliberate repair.tarandlzmarestore the root filesystem and preserve symlinks/permissions.sha1sumverifies the rootfs archive after transfer.
LNA is useful after the base system is healthy. It was not sufficient to repair the original corrupted HDD kernel because the device could not complete the update-mode reboot.
If you have a router with DHCP:
PC ----+
+---- LAN/router with DHCP
NAS ---+
This is convenient for normal boot and LNA.
The actual recovery used:
Windows PC LaCie
192.168.11.200/24 <----------> 192.168.11.202/24
The Windows interface was Dockstation Ethernet. Wi-Fi remained the PC's normal Internet connection.
A VPN/tunnel can completely break private-LAN troubleshooting. In the real recovery, a VPN caused addresses in 192.168.11.x to appear reachable when they were not the NAS.
Disable it temporarily or explicitly exclude 192.168.11.0/24.
Open Administrator CMD:
netsh interface show interface
ipconfigThe successful setup used:
Dockstation Ethernet:
IPv4 Address: 192.168.11.200
Mask: 255.255.255.0
Gateway: none
Using the Windows GUI is fine. With netsh the pattern is:
netsh interface ipv4 set address name="Dockstation Ethernet" static 192.168.11.200 255.255.255.0Do not add a gateway to the isolated recovery adapter unless you deliberately configure routing.
Verify again with:
ipconfigAllow the recovery utilities on the dedicated interface:
- CLUNC/LUMP UDP traffic;
- TFTP UDP 69 and transfer traffic;
- HTTP TCP 8000;
- SSH TCP 22;
- DHCP UDP 67/68 if used;
- NTP UDP 123 if the PC will later serve time.
With simplewall, narrow rules for 192.168.11.0/24 are preferable to disabling the firewall globally.
cd /d D:\Distr\Lacie\CLUNCIf the NAS is on a normal LAN with a working DHCP server, use it.
If the NAS is connected directly to the Windows recovery PC or to an isolated switch, use the included dhcpsrv2.5.2 when the normal LaCie OS or LNA expects DHCP.
The custom RAM rescue itself does not need DHCP because its IP is set explicitly in U-Boot boot arguments.
Directory:
D:\Distr\Lacie\CLUNC\dhcpsrv2.5.2
The repository contains the working dhcpsrv.ini from this recovery. Use it as the baseline for the same 192.168.11.0/24 network.
If you need to generate a new configuration, run:
dhcpwiz.exe
Select the physical recovery Ethernet adapter, not Wi-Fi, Hyper-V, VirtualBox, or a VPN/tunnel adapter.
The utility can run as an application or Windows service. In this setup it was installed/run as a Windows service. If already installed, use:
services.mscFor service installation/removal syntax, use the included readme.txt for this exact version instead of guessing the service name or flags.
Use:
dhcptrc.txt
A successful request/offer proves that the NAS Ethernet interface and broadcast path are working.
Do not run this local DHCP server on a LAN that already has another active DHCP server unless the recovery NIC is isolated.
This is the canonical CLUNC procedure. Whenever a later section says return to CLUNC, come back here.
From Administrator CMD:
cd /d D:\Distr\Lacie\CLUNC
start_clunc.batKeep this console open.
Start CLUNC first, then power-cycle the LaCie.
The recovered unit had:
bootdelay=0
so the normal U-Boot sequence starts immediately. The goal is to get:
Marvell>>
If normal boot continues, keep or restart CLUNC and power-cycle again, interrupting autoboot immediately when CLUNC connects.
At Marvell>> run:
help
or:
printenv
You are now in the bootloader.
Warning
Never paste Linux shell commands at Marvell>>. Do not experiment with nand erase, nand write, bubt, or persistent environment changes.
At Marvell/U-Boot:
printenv
Useful values from the recovered setup included:
ipaddr=192.168.11.202
serverip=192.168.11.200
ncip=192.168.11.200
saved_entry=0
If necessary, set the IP variables temporarily:
setenv ipaddr 192.168.11.202
setenv serverip 192.168.11.200
setenv ncip 192.168.11.200
Do not run saveenv for this temporary recovery configuration.
On the recovered unit:
saved_entry=0
corresponded to the first firmware slot:
root_1
partition 4
md4
The second slot was:
root_2
partition 5
md5
Do not change the boot selection yet.
The original failure was identified by inspecting the HDD-resident uImage copies and seeing Bad Data CRC for the old svn7972 kernel, while the NAND rescue kernel remained valid.
The main recovery path below does not require repeating every historical CRC-inspection command on disk. It is enough to verify the known-good TFTP kernel with iminfo, then inspect the root slots read-only over SSH before writing them.
Both services run on the Windows recovery PC.
Open another Administrator CMD:
cd /d D:\Distr\Lacie\CLUNC\tftp_http
start_tftp_fixed.batThe directory must contain:
uImage
uInitrd_lacie_ssh
Keep the server window open.
Open another CMD:
cd /d D:\Distr\Lacie\CLUNC\tftp_http
start_lacie_http_server.batThe directory should contain at least:
rootfs_3.1.4.7.tar.lzma
mkfs.ext2_lacie
The recovery used:
http://192.168.11.200:8000/
Use:
TFTP -> files loaded by U-Boot
HTTP -> larger files downloaded from rescue Linux
If you are no longer at Marvell>>, return to Start the CLUNC console.
All commands in this section are typed at the Marvell/U-Boot prompt.
tftp 0x800000 uImage
Wait for the transfer to finish.
tftp 0x1200000 uInitrd_lacie_ssh
iminfo 0x800000
iminfo 0x1200000
The initramfs should identify itself approximately as:
Image Name: LaCie SSH rescue initramfs
ARM Linux RAMDisk Image (gzip)
Both CRC checks must succeed. If iminfo reports a bad CRC, stop and fix the file or transfer before booting.
Exactly as used in the recovery:
setenv bootargs console=ttyS0,115200 rdinit=/init init=/init ip=192.168.11.202:192.168.11.200::255.255.255.0::eth0:off netconsole=6666@192.168.11.202/eth0,6666@192.168.11.200/
This configures:
rescue IP: 192.168.11.202
PC: 192.168.11.200
mask: 255.255.255.0
Again, do not saveenv.
bootm 0x800000 0x1200000
The custom initramfs eventually prints messages similar to:
LACIE-RESCUE: custom initramfs started
LACIE-RESCUE: SSH target 192.168.11.202:22
sshd start rc=0
Once SSH is running, leave the CLUNC window alone and use another CMD window for SSH.
ssh -o HostKeyAlgorithms=+ssh-rsa root@192.168.11.202Password:
lacie-recovery
A typical rescue prompt is:
~ #
Everything in this and the following repair sections is typed in the SSH rescue shell, not U-Boot.
busybox mdev -sThe custom initramfs may print a series of export ... environment lines while doing this. That is noisy but not necessarily an error.
ls -l /dev/sda /dev/sdbThen:
cat /proc/partitionsYou should see partitions 1 through 8 on both drives.
If either disk is missing, stop before assembling RAID.
Immediately after rescue boot:
cat /proc/mdstatmay show:
Personalities :
unused devices: <none>
This does not mean RAID metadata is gone. It only means the arrays have not been assembled automatically.
mdadm --assemble /dev/md4 /dev/sda4 /dev/sdb4mdadm --assemble /dev/md5 /dev/sda5 /dev/sdb5The real session reported:
mdadm: /dev/md5 has been started with 2 drives.
mdadm --assemble /dev/md6 /dev/sda6 /dev/sdb6cat /proc/mdstatHealthy root_2 looked like:
md5 : active raid1 sda5[0] sdb5[1]
1572852 blocks super 1.0 [2/2] [UU]
The important marker is:
[UU]
Both members are present.
mdadm --detail /dev/md4
mdadm --detail /dev/md5
mdadm --detail /dev/md6A healthy firmware slot should report RAID1, clean state, two active/working devices, and zero failed devices.
Do not proceed with destructive changes if a firmware array unexpectedly starts degraded.
This is mandatory before formatting anything:
blkid /dev/md4
blkid /dev/md5
blkid /dev/md6Values observed on the recovered unit:
root_1 / md4:
a29998e7-275d-4117-90be-fb64676b5e29
root_2 / md5:
cb60f5d9-41ea-4b90-95d3-ae6f577d04a2
/var / md6:
521c278a-f1d5-4133-991e-2a795fabaa9b
Your UUIDs may differ. Write them down.
Always inspect read-only first.
mkdir -p /mnt/root1
mount -o ro /dev/md4 /mnt/root1Inspect:
ls -l /mnt/root1/boot
readlink -f /mnt/root1/boot/uImage
ls -l /mnt/root1/lib/modulesmkdir -p /mnt/root2
mount -o ro /dev/md5 /mnt/root2
mount | grep md5
ls -l /mnt/root2
ls -l /mnt/root2/boot
readlink -f /mnt/root2/boot/uImage
ls -l /mnt/root2/lib/modulesThe broken slot from this recovery showed:
uImage -> vmlinuz-2.6.31.14-svn7972
and:
/lib/modules/2.6.31.14-svn7972
The other broken slot contained the same old kernel.
umount /mnt/root2
umount /mnt/root1Never format a mounted filesystem.
The first goal is to make the NAS boot normally again from the active firmware slot.
There are two ways to replace the root filesystem:
- format and restore — this was used successfully on
root_1in the original recovery; - keep the existing ext2 filesystem and replace its files — useful when the filesystem itself is healthy and you want to avoid the LaCie-specific
ext2_lacieformatter dependency.
The known-good payload is rootfs_3.1.4.7.tar.lzma.
If the rescue boot was restarted, remember that the RAM filesystem starts clean. Files manually downloaded during a previous rescue session are gone.
Start HTTP as described in Start the TFTP and HTTP servers.
In the SSH rescue shell:
cd /
wget http://192.168.11.200:8000/rootfs_3.1.4.7.tar.lzmaIf you intend to use the LaCie formatter:
wget http://192.168.11.200:8000/mkfs.ext2_lacie
chmod 755 /mkfs.ext2_lacieIf wget says File exists and you are not sure the existing copy is correct, remove and fetch it again.
ls -lh /rootfs_3.1.4.7.tar.lzma
sha1sum /rootfs_3.1.4.7.tar.lzmaExpected SHA1:
b42ab0be4216f5b6f6aa965b31ddae4d7c3c5b66
Do not proceed if it differs.
During the real recovery, one bad transfer produced:
72d8e7cd7c56c82885c4ec2c36ede6f44d4a39d6
That copy was rejected and retransferred.
Caution
Confirm again that md4 is root_1 on your machine and that you recorded its UUID.
Confirm it is not mounted:
mount | grep md4If mounted:
umount /mnt/root1The successful repair used the LaCie formatter while preserving the original UUID. Example from the recovered unit:
/mkfs.ext2_lacie -U a29998e7-275d-4117-90be-fb64676b5e29 /dev/md4Replace that UUID with the value from your own blkid /dev/md4.
On a later rescue boot, the same binary printed:
Your mke2fs.conf file does not define the ext2_lacie filesystem type.
Aborting...
The program depends on an external LaCie filesystem profile.
If you see this:
- it has aborted before formatting;
- do not invent formatter options;
- either supply the matching LaCie
mke2fs.confthat definesext2_lacie, or use Method B if the existing ext2 filesystem is healthy.
After a successful format:
mkdir -p /mnt/root1
mount /dev/md4 /mnt/root1
cd /mnt/root1
lzma -dc /rootfs_3.1.4.7.tar.lzma | tar -xpf -
syncUse this only if the existing ext2 filesystem mounts cleanly and there is no evidence of filesystem corruption.
mkdir -p /mnt/root1
mount /dev/md4 /mnt/root1
ls -l /mnt/root1
ls -l /mnt/root1/bootRemove only the old root filesystem directories:
cd /mnt/root1
rm -rf bin boot dev etc lib linuxrc media mnt opt proc root sys tmp usr var wwwDo not remove /mnt/root1 itself.
Extract the official rootfs:
cd /mnt/root1
lzma -dc /rootfs_3.1.4.7.tar.lzma | tar -xpf -
syncBecause the filesystem itself was not recreated, its UUID remains unchanged.
ls -l /mnt/root1/boot
readlink -f /mnt/root1/boot/uImage
ls -l /mnt/root1/lib/modules
blkid /dev/md4You want:
uImage -> vmlinuz-2.6.31.14-svn8060
and modules:
2.6.31.14-svn8060
Then:
sync
umount /mnt/root1Before rebooting:
sync
umount /mnt/root2 2>/dev/null
umount /mnt/root1 2>/dev/null
umount /mnt/var 2>/dev/null
rebootThe RAM rescue disappears. With saved_entry=0, the NAS should attempt to boot the repaired root_1.
The normal firmware may use DHCP. If your LAN already has DHCP, use it. If you are on the isolated recovery network, start the DHCP server from Provide DHCP when needed.
In the real recovery, the NAS at one point obtained 192.168.11.50 through DHCP and was later configured statically as 192.168.11.202.
Try:
http://<NAS-IP>/
https://<NAS-IP>/
A successful kernel/root repair can still leave the Dashboard spinner running forever while a backend endpoint such as /info returns HTTP 500. That means the rootfs is booting but persistent state can still be incompatible.
Old persistent Unicorn configuration contained:
backup:
backup_folder:
backup_specific:
full_backup:
restore:
settings:
auto_update:
email:
but the fresh 3.1.4.7 rootfs had no matching unicorn/backup/settings.py.
Logs showed:
ImportError: No module named settings
Database corrupted or not fully initialized
If the Dashboard works normally and the setup wizard appears, skip this subsection.
If you have the same stale-state failure, return to the RAM rescue using Start the CLUNC console, boot the custom rescue again, and reconnect over SSH.
Then:
busybox mdev -s
mdadm --assemble /dev/md4 /dev/sda4 /dev/sdb4
mdadm --assemble /dev/md6 /dev/sda6 /dev/sdb6
mkdir -p /mnt/root1 /mnt/var
mount -o ro /dev/md4 /mnt/root1
mount /dev/md6 /mnt/var
ls -la /mnt/var
ls -la /mnt/var/0Preserve the old state:
mv /mnt/var/0 /mnt/var/0.before-repairIf that backup name already exists, choose another suffix rather than overwriting it.
Create a clean slot-0 tree:
mkdir -p /mnt/var/0Copy fresh defaults from the working rootfs:
cd /mnt/root1
tar -cf - etc var root | (cd /mnt/var/0 && tar -xpf -)Then:
sync
umount /mnt/var
umount /mnt/root1
rebootAfter the /var/0 reset, the real unit displayed the normal LaCie first-boot/setup wizard. This proved that the kernel, root filesystem, persistent services, Unicorn backend, and web UI were functioning.
The wizard may still report a storage/RAID error if the large data volume was previously deleted. That is a separate issue from the firmware boot repair.
Once root_1 boots normally, repair the inactive firmware slot so future A/B updates do not start from a known-broken bank.
Return to Start the CLUNC console, boot the custom RAM rescue again, and reconnect over SSH.
busybox mdev -s
cat /proc/partitions
mdadm --assemble /dev/md5 /dev/sda5 /dev/sdb5
cat /proc/mdstat
mdadm --detail /dev/md5Healthy output should show clean, [2/2], and [UU].
blkid /dev/md5Observed example:
UUID="cb60f5d9-41ea-4b90-95d3-ae6f577d04a2" TYPE="ext2"
Record your own value.
mkdir -p /mnt/root2
mount -o ro /dev/md5 /mnt/root2
mount | grep md5
ls -l /mnt/root2
ls -l /mnt/root2/boot
readlink -f /mnt/root2/boot/uImage
ls -l /mnt/root2/lib/modulesThe broken slot showed:
uImage -> vmlinuz-2.6.31.14-svn7972
and modules:
2.6.31.14-svn7972
Unmount:
umount /mnt/root2Do not clone the two root arrays with:
dd if=/dev/md4 of=/dev/md5
A raw clone duplicates filesystem metadata and UUIDs. File-level copying preserves root_2's separate filesystem UUID.
mdadm --assemble /dev/md4 /dev/sda4 /dev/sdb4
cat /proc/mdstatYou want both md4 and md5 at [UU].
mkdir -p /mnt/root1 /mnt/root2
mount -o ro /dev/md4 /mnt/root1
mount /dev/md5 /mnt/root2
blkid /dev/md4
blkid /dev/md5The UUIDs must be different.
Make absolutely sure your current directory is the destination:
cd /mnt/root2
pwdIt must print:
/mnt/root2
Then remove the old firmware directories:
rm -rf bin boot dev etc lib linuxrc media mnt opt proc root sys tmp usr var wwwDo not run rm -rf /mnt/root2.
cd /mnt/root1
tar -cf - . | (cd /mnt/root2 && tar -xpf -)
syncreadlink -f /mnt/root2/boot/uImage
ls -l /mnt/root2/lib/modules
blkid /dev/md5Expected kernel:
/mnt/root2/boot/vmlinuz-2.6.31.14-svn8060
Expected modules:
2.6.31.14-svn8060
The md5 filesystem UUID must still match the value recorded before the copy.
sync
umount /mnt/root2
umount /mnt/root1
rebootBecause the normal boot selection is still root_1, this reboot primarily confirms that repairing root_2 did not disturb the working system.
Before attempting a firmware upgrade, verify the base recovery thoroughly.
Confirm all of the following:
- front LED reaches a normal state;
- NAS remains reachable after several minutes;
- no unexpected reboot loop;
- both HDDs stay detected;
- the web UI completes loading;
- normal reboot works more than once.
At this point the intended state is:
root_1 -> working 3.1.4.7 / svn8060
root_2 -> working 3.1.4.7 / svn8060
with different filesystem UUIDs.
If you boot the rescue system for verification:
busybox mdev -s
mdadm --assemble /dev/md4 /dev/sda4 /dev/sdb4
mdadm --assemble /dev/md5 /dev/sda5 /dev/sdb5
mdadm --assemble /dev/md6 /dev/sda6 /dev/sdb6
cat /proc/mdstat
mdadm --detail /dev/md4
mdadm --detail /dev/md5
mdadm --detail /dev/md6All required RAID1 arrays should be clean and [UU].
If the data volume was intentionally deleted, the setup wizard may ask you to recreate storage. That is not a firmware failure.
If existing user data matters, do not recreate or initialize the data volume until it has been separately backed up or recovered.
Once the NAS is back on a normal LAN, stop the temporary Windows DHCP service unless the recovery network still needs it.
If the LaCie now has a static address, DHCP is not required for ordinary operation.
The recovered unit sometimes forgot its time after power loss. The platform exposed a DS1337 RTC; there was no normal desktop-style user-replaceable CR2032 arrangement.
Use NTP for reliable time.
Examples:
time.cloudflare.com
time.google.com
pool.ntp.org
NTP uses UDP port 123.
This was tested successfully.
Open Administrator CMD on Windows:
reg add "HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpServer" /v Enabled /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config" /v AnnounceFlags /t REG_DWORD /d 5 /f
net stop w32time
net start w32timeCheck UDP 123:
netstat -ano -p udp | findstr ":123"Verify Windows time status:
w32tm /query /statusOptional local test:
w32tm /stripchart /computer:192.168.11.200 /samples:5 /dataonlyAllow this traffic through the firewall/simplewall:
LaCie 192.168.11.202 -> Windows 192.168.11.200 UDP 123
Then configure the LaCie NTP server as:
192.168.11.200
An IP address worked successfully on the recovered unit.
An HTTP proxy can help with HTTP/HTTPS traffic, but it is not a complete network gateway.
During testing, the old LaCie updater tried:
CONNECT 2bignetwork2r-update.lacie.com:21 HTTP/1.1
and NTP uses UDP/123, which is not transported by a normal HTTP proxy.
For normal operation, either put the NAS on a regular LAN with Internet access or use proper routing/NAT if Internet access is truly required.
Do this after the recovery, not as a substitute for repairing broken root slots.
The intended upgrade path used during the investigation was:
3.1.4.7 -> 4.1.9.2 -> 4.3.19.7
Do not jump directly from 3.1.4.x to the final firmware unless you independently verify that LaCie's updater supports it.
The vendor updater relies on the A/B firmware layout. Starting an update while the inactive bank already contains a corrupted kernel creates unnecessary risk.
The recovery deliberately puts both banks into a known-good baseline first.
Some LNA/recovery transitions may expect DHCP.
If the NAS is on a normal network, use that network's DHCP server.
If it is still connected directly to the Windows PC, start the local DHCP server described in Provide DHCP when needed.
Use LNA with the appropriate firmware capsule.
Do not interrupt a genuine firmware write merely because a step takes several minutes.
However, if LNA reports:
Restart error
or remains stuck at:
Step 2 of 3
for an unreasonable period and the NAS never returns, do not repeatedly force the same update.
Return to Start the CLUNC console and inspect what the NAS is actually booting.
The original updater can use legacy protocols such as FTP. Supplying the capsule locally through LNA is generally cleaner than trying to recreate the old vendor online-update infrastructure.
Check:
- PC Ethernet is physically connected.
- PC recovery NIC is
192.168.11.200/24. - VPN is disabled or excludes
192.168.11.0/24. - Firewall allows the CLUNC script.
- CLUNC is started before power-cycling.
- Try another power cycle because
bootdelay=0leaves almost no time.
Return to Start the CLUNC console.
Remember: the custom RAM rescue does not need DHCP.
For the normal firmware:
- verify an existing LAN DHCP server is active; or
- run
dhcpsrv2.5.2.
Watch:
dhcptrc.txt
If it remains empty, likely causes include wrong NIC selection, stopped service, firewall blocking UDP 67/68, or the NAS not reaching the normal network-init stage.
Check:
start_tftp_fixed.batis running;uImageanduInitrd_lacie_sshare intftp_http;- U-Boot
serveripis192.168.11.200; - U-Boot
ipaddris192.168.11.202; - Windows firewall permits TFTP.
At U-Boot:
printenv
If needed:
setenv serverip 192.168.11.200
setenv ipaddr 192.168.11.202
Do not saveenv.
Do not boot it.
Verify the file is the known-good repository copy, restart TFTP, transfer again, and rerun iminfo.
Use:
ssh -o HostKeyAlgorithms=+ssh-rsa root@192.168.11.202busybox mdev -s
cat /proc/partitions
ls -l /dev/sda*
ls -l /dev/sdb*mdev -s may print environment lines; that alone is not an error.
Expected before manual assembly.
mdadm --assemble /dev/md4 /dev/sda4 /dev/sdb4
mdadm --assemble /dev/md5 /dev/sda5 /dev/sdb5
mdadm --assemble /dev/md6 /dev/sda6 /dev/sdb6
cat /proc/mdstatFirst confirm partition device nodes exist:
cat /proc/partitions
ls -l /dev/sda5 /dev/sdb5Then:
mdadm --assemble /dev/md5 /dev/sda5 /dev/sdb5A previous transfer already created the target file. Do not assume it is valid.
For the rootfs:
sha1sum /rootfs_3.1.4.7.tar.lzmaIf wrong:
rm -f /rootfs_3.1.4.7.tar.lzma
wget http://192.168.11.200:8000/rootfs_3.1.4.7.tar.lzma
sha1sum /rootfs_3.1.4.7.tar.lzmaExpected:
b42ab0be4216f5b6f6aa965b31ddae4d7c3c5b66
Do not extract it and do not format based on it.
The real recovery caught a bad copy with:
72d8e7cd7c56c82885c4ec2c36ede6f44d4a39d6
The correct archive was retransferred via HTTP.
Check permissions:
ls -l /mkfs.ext2_lacie
chmod 755 /mkfs.ext2_lacieRetry only after the executable bit is present.
If you see:
Your mke2fs.conf file does not define the ext2_lacie filesystem type.
Aborting...
then the formatter lacks the LaCie-specific filesystem profile.
Do not replace it with guessed options.
Use one of these approaches:
- obtain the matching LaCie
mke2fs.confthat actually definesext2_lacie; - if the filesystem is healthy, preserve it and replace its files;
- for
root_2, copy the workingroot_1at file level.
The HTTP server may be alive while Unicorn/backend services fail because of stale /var state.
See First normal boot and persistent /var repair.
This was a key symptom of the persistent-state mismatch in the real recovery.
The rootfs itself may already be correct. Inspect /var/0 before replacing the root filesystem again.
Possible causes include:
- still booting a broken firmware slot;
- kernel/rootfs mismatch;
- stale persistent state;
- data RAID missing;
- unrelated hardware failure.
Do not interpret a red LED alone as proof of NAND failure.
Check DHCP first. LNA discovery/update modes may work more reliably with a functioning DHCP server.
Also check VPN and firewall behavior.
That is suspicious. A VPN/tunnel may be intercepting the private subnet.
Disable it or explicitly bypass 192.168.11.0/24.
These commands are intentionally not part of the normal recovery path.
We use temporary U-Boot variables. Do not persist them without a specific reason.
Can destroy U-Boot or the NAND rescue system. Not required for this failure.
Same warning. A healthy NAND rescue system was one of the assets that made this recovery possible.
Bootloader update/write command. Do not use it simply because normal HDD boot fails.
Avoid:
dd if=/dev/md4 of=/dev/md5
because it duplicates filesystem metadata and UUIDs. Use file-level copy.
Before any format, verify:
cat /proc/mdstat
mdadm --detail /dev/md4
blkid /dev/md4Never infer the target only from memory.
The large partitions:
sda8
sdb8
are not needed for the firmware repair. Do not format them as part of this procedure.
This is a reminder, not a substitute for the detailed sections.
netsh interface show interface
ipconfigcd /d D:\Distr\Lacie\CLUNC
start_clunc.batcd /d D:\Distr\Lacie\CLUNC\tftp_http
start_tftp_fixed.batcd /d D:\Distr\Lacie\CLUNC\tftp_http
start_lacie_http_server.batsetenv ipaddr 192.168.11.202
setenv serverip 192.168.11.200
setenv ncip 192.168.11.200
Do not saveenv.
tftp 0x800000 uImage
tftp 0x1200000 uInitrd_lacie_ssh
iminfo 0x800000
iminfo 0x1200000
setenv bootargs console=ttyS0,115200 rdinit=/init init=/init ip=192.168.11.202:192.168.11.200::255.255.255.0::eth0:off netconsole=6666@192.168.11.202/eth0,6666@192.168.11.200/
bootm 0x800000 0x1200000
ssh -o HostKeyAlgorithms=+ssh-rsa root@192.168.11.202Password: lacie-recovery.
busybox mdev -s
cat /proc/partitionsmdadm --assemble /dev/md4 /dev/sda4 /dev/sdb4
mdadm --assemble /dev/md5 /dev/sda5 /dev/sdb5
mdadm --assemble /dev/md6 /dev/sda6 /dev/sdb6
cat /proc/mdstatblkid /dev/md4
blkid /dev/md5
blkid /dev/md6cd /
wget http://192.168.11.200:8000/rootfs_3.1.4.7.tar.lzma
sha1sum /rootfs_3.1.4.7.tar.lzmaExpected:
b42ab0be4216f5b6f6aa965b31ddae4d7c3c5b66
mkdir -p /mnt/root2
mount -o ro /dev/md5 /mnt/root2
ls -l /mnt/root2/boot
readlink -f /mnt/root2/boot/uImage
ls -l /mnt/root2/lib/modules
umount /mnt/root2mkdir -p /mnt/root1 /mnt/root2
mount -o ro /dev/md4 /mnt/root1
mount /dev/md5 /mnt/root2
blkid /dev/md4
blkid /dev/md5
cd /mnt/root2
rm -rf bin boot dev etc lib linuxrc media mnt opt proc root sys tmp usr var www
cd /mnt/root1
tar -cf - . | (cd /mnt/root2 && tar -xpf -)
sync
readlink -f /mnt/root2/boot/uImage
ls -l /mnt/root2/lib/modules
blkid /dev/md5
sync
umount /mnt/root2
umount /mnt/root1sync
rebootreg add "HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpServer" /v Enabled /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config" /v AnnounceFlags /t REG_DWORD /d 5 /f
net stop w32time
net start w32time
netstat -ano -p udp | findstr ":123"
w32tm /query /statusThese values are useful for comparison but should not blindly replace values discovered on your own NAS.
Marketing model: LaCie 2big NAS
Product ID: 2bignetwork2r
Hardware ID: nas2big
Original firmware: 3.1.4.6
Recovery firmware: 3.1.4.7
Broken kernel: 2.6.31.14-svn7972
Known-good kernel: 2.6.31.14-svn8060
7,177,764 bytes
rootfs_3.1.4.7.tar.lzma
68,381,967 bytes
SHA1:
b42ab0be4216f5b6f6aa965b31ddae4d7c3c5b66
Windows PC: 192.168.11.200/24
Rescue NAS: 192.168.11.202/24
U-Boot variables:
serverip=192.168.11.200
ipaddr=192.168.11.202
ncip=192.168.11.200
root_1:
/dev/md4
/dev/sda4 + /dev/sdb4
root_2:
/dev/md5
/dev/sda5 + /dev/sdb5
/var:
/dev/md6
/dev/sda6 + /dev/sdb6
root_1:
a29998e7-275d-4117-90be-fb64676b5e29
root_2:
cb60f5d9-41ea-4b90-95d3-ae6f577d04a2
/var:
521c278a-f1d5-4133-991e-2a795fabaa9b
These are examples from one NAS. Preserve the UUIDs from your own device.
| Purpose | Protocol/port | Direction |
|---|---|---|
| DHCP | UDP 67/68 | NAS ↔ DHCP server |
| CLUNC/LUMP | UDP, including 4446/6666 | PC ↔ U-Boot |
| TFTP | UDP 69 + transfer ports | U-Boot → PC |
| Local HTTP recovery server | TCP 8000 | NAS rescue → PC |
| SSH rescue | TCP 22 | PC → NAS rescue |
| NTP | UDP 123 | NAS → NTP server |
| Legacy FTP update | TCP 21 | NAS → update server |
| LaCie web UI | TCP 80/443 | PC → NAS |
Exact CLUNC behavior can depend on the implementation/script. If simplewall logs dropped packets during discovery, allow the recovery script on the dedicated LAN rather than opening the machine globally.