General NAS-Central Forums

The boot procedure is:

• On boot the cpu starts executing from some predefined address.
• This address is the entry point of u-boot in flash.
• U-boot detects if the reset button is pressed, and does the red light sequence
• U-boot tries load a kernel from sda10, and if that fails from sda6 (On a 2Big2 also sdb10 and sdb6 are probed, when sda fails)
• The kernel is started, with in the cmdline the rootfs specified, being sda7, read only. When a factory reset is requested, it's also specified in the cmdline.
• The kernel mounts sda7, and runs /sbin/init from it.
• /sbin/init checks if the cmdline specifies a factory reset, if yes, it basically reformats sda9, cleans sda10, and reboots.
  If no, a unionfs is created from sda8 (ro) and snapshots on sda9 (the latest snapshot rw), and a rootswitch is done.
  Booting continues from unionfs/sbin/init

The update procedure is

• A new snapshot is created on sda9, and the rootfs in the capsule file is written to it.
• The kernel from the capsule file is written to sda10.
• When available, some scripts from the capsule are executed.
• The box reboots.
• The kernel is loaded from sda10, and sda7/sbin/init is executed.
• The new unionfs is created, with the new snapshot being the top layer.
• If available some cleanup script from the capsule is executed.

So, to be able to do a factory reset, we only need the kernel, and sda7. Updating only affects sda9 and sda10. The only reason I can find why a factory reset could fail (besides *very* serious bugs in the scripts in the capsule, which damages sda7 or sda8), is when the kernel in sda10 is damaged, and u-boot still tries to use it, even when a factory reset is requested (that behaviour should be considered buggy).
It would be worth a try to cleanup sda10:Repeat that for the other disk.

Hmn, odd - the command worked for one, but hung the PC when I tried the second, undeterred I soldiered on with the one drive figuring I can sort the other drive out afterwards, so I popped in the one drive and tried the factory reset - still no go.

Looks like I'll have to do the whole wipe and start over after all

Anyway that can wait I have a kids party to go to and being the only driver... well you know how it is!

Mijzelf, this problem as hapenned two times (with rmar and Lumpsack).
There is some conjugation of factors that make this happen and i haven't understand what this factors are.
I think both rmar and Lumpsack had a not rooted version 2.0.6 and updated with a rooted custom capsule 2.0.6.

Maybe the best way, is to warn useres to make a factory reset and so cleaning the drive before updating with a custom capsule.

What do you think? Do you have any idea why this happened to rmar and Lumpsack?
Of course, a folder can also be made with pre-generated custom capsules to make sure the custom capsules are correct and avoiding the need for users to create the capsule for themselfes.

Hi Everybody,

Now I did a capsule with version 2.1.2, and I ran into tries, to see what cause the other problem, like no power to the NAS. And now, when the power is off with torrent downloading, whch cause problems on the other capsule, in that one it restart quite fine.

And Myzelf, if it happens next time, I'll just do the sdb10, and see if it works, at least if I can do a hard reset (factory default)

Regards

Rui

Thank you, thank you, thank you!!!

I have a new clean drive back up!!

Now given all that fun do you think its worth going through the firmware again - especially given my linux noobness?

Glad to ear that!


It's your choice. As you read in this topic only two times the custom capsule did not work: you and rmar (first try in 2.0.6).

If you decide to go ahead with version 2.1.2 like rmar, please give us the results.

lol, I must be a glutton for punishment - I'm compiling it again - well, almost as suggested I'm going with the new version.

hehe, or not - being a live cd it ran out of space and wouldn't work - maybe its a sign

@andreus: I have no idea how a capsule could get wrong. Except maybe lack of diskspace at creation, truncating the capsule. But in that case I suppose the checksum would be wrong, so the capsule would be rejected.

Maybe Lumpsac still has the capsule which bricked his box?

About serving prebuild capsules, that would be a lot of work to keep it up to date. (6(?) boxes, each 3 months a new firmware). And it's not said the capsule itself is the problem. It could be also the updating. Search the forums, and you'll find people who bricked their box using an official Lacie capsule. Here is a recent one.

I just fired up the virtual and I still have the capsule, I'm just uploading it to Google and will edit this post when its done.

Okay, https://docs.google.com/open?id=0B000skCWnm1fNjFlZDAwYjAtOTZhYy00MTgzLTk0NGQtMDYwOTMxMGI4ZWIz <- that horrible link is the capsule.

I can see the advantage in prebuilt capsules, as not everyone has Linux, that said I can also appreciate its a lot of work for no thanks.

I may play with this stuff again later, but all I was intending to do with it was set up an SQL server to centralise my XBMC and perhaps host a wordpress site, for both of these I suspect I'd need to go the linux route and while I do like the cost and availability of linux I find it daunting and very unfriendly (although that is at last changing)

Yes, i also think that the problem must be related to some particular nas configurations or lacie update system. I think that's why after a factory reset it worked for rmar.



Yes it's true, the script works for 5 products and normally in 3 months that will have to be another 5 capsule versions. I also see the advantage, so if anyone wants to do it i think it will be good.


I have downloaded it. When i have more time i'll see if everything is correct with this capsule.

Well, I thought I'd give it another go using 2bignetwork2_2.1.2.1.capsule - but couldn't get either of the network assistants (1.4.1 & 1.5.4) to actually install the capsule.

I gave "method 3" - using the Share\Update method a go and after a very long agonizing wait it eventually pinged back and came fired up - the file had gone from the share\update folder which I don't know if that is normal or not but I deleted the "share" share to be safe as I don;t want it updating every time it get switched off (not that its that often)

I did notice on the dashboard that it still says 2.1.2 (not 2.1.2.1 as I was expecting), however I can access the TwonkyMedia server page on port 9000 so I guess I'm good.

So I'd like to thank you all for your efforts helping me get to the point where I can start doing some real damage

I find it always better using method 3. Network assistant gave me problems from the start.
Hummm. Maybe the "blue blink light" problem after "update" is because of updating using network assistant (i don't know how rmar did it).
Yeah it takes a while... need to have nerves of steel lol.
After update Lacie OS automatically deletes the capsule from the share. You don't have to delete the share.


It's normal, the last ".1" is just for the update system accept "updating" with the same capsule version that is currently installed.


You're welcome.
Now you know you to recover from most of software damage

again thanks, oh by the way I used method three the first time too, so sadly I can't blame the assiant - I suspect it may just have been a corrupt file, no telling really.