Does not meet the conditions for updating the TOS 5.1?

[Gremlin]

change the boot order in the EFI / BIOS to USB?

Except that you need to update to a special bios in order to allow TNAS to boot from an external usb port. The Bios as delivered is inhibited. At which point you may as well follow the recommended procedures even if it upsets you. (or replace the operating system - whatever floats your boat).

[crisisacting]

The boot procedure is done via BIOS/EFI so it should be possible to boot from an external USB.

Never posted that it wasn't possible.

Isn't it possible to flash the 5.1.40 on a USB device and change the boot order in the EFI / BIOS to USB?

Installing TOS to an external drive hasn't ever been possible through their TNAS initialization wizard; it only detects internal drives during the process.

Already suggested an attempt to try to work around that limitation to you.

Maybe I could even copy my existing 5.1.37 system partition to an USB Stick and start from that stick.

You go ahead and attempt whatever you want.

Seemingly, you're ready to waste time with theories, but not willing to actually follow their provided procedures to get the device properly setup with the expanded system partition.

[Gremlin]

{L_BUTTON_AT}crisisacting

Two minds, single thought! The ether is most powerful.

[crisisacting]

Except that you need to update to a special bios in order to allow TNAS to boot from an external usb port. The Bios as delivered is inhibited.

You can change the boot order to boot other EFI sources as well as USB devices.

If Secure Boot is active, then enrollment would be necessary to allow for direct booting from any other source.

If it's available to change, you could even switch from EFI to less secure Legacy.

At which point, you may as well follow the recommended procedures even if it upsets you. (or replace the operating system - whatever floats your boat).

Yup

[UncleJohnsBand]

So the note above has me confused when looking at the steps....

Note: Do not delete the four partitions that are not displayed, this is USB InitBoot, which is used to boot and install TOS.

Below is what I see from the ls /dev/sd* command. Are you just saying with that note to only delete the 1-4 partitions on the SDA drive?

/dev/sda /dev/sda3 /dev/sdb1 /dev/sdb4 /dev/sdc2 /dev/sdd
/dev/sda1 /dev/sda4 /dev/sdb2 /dev/sdc /dev/sdc3 /dev/sdd1
/dev/sda2 /dev/sdb /dev/sdb3 /dev/sdc1 /dev/sdc4

For me SDA and SDB are my paired 3gb drives I use for my raid.
SDC is a stand alone SDD.
SDD is my connected 1TB USB drive that my data is currently backed up to.

Just looking to make sure if I have to do SDA and SDB or just SDA and will by SDC (SDD) drive remain ok through this and will the SDC (USB) be fine as well since that is where the data is I need to restore.

Please advise.

Everyone but me got a response.....

Tech - are you going to respond?

[crisisacting]

{L_BUTTON_AT}UncleJohnsBand

If your TNAS configuration is a source of confusion, then mount the drives from this previous TOS configuration into another PC to wipe the drives; would suggest using Parted Magic, a live boot Linux distribution that's built specifically for these kind of situations to Secure Erase those drives.

[UncleJohnsBand]

{L_BUTTON_AT}UncleJohnsBand

If your TNAS configuration is a source of confusion, then mount the drives from this previous TOS configuration into another PC to wipe the drives; would suggest using Parted Magic, a live boot Linux distribution that's built specifically for these kind of situations to Secure Erase those drives.

Thanks... Source of confusion is directions... They highlight a note... Which to me is erroneous without further explanation. The explain doing one drive... But don't elaborate if really they mean both drives in the raid... Or alm found drives which in my case would include a stand alone SSD as well as my attached USB. I've backed up to the attached USB and plan was to restore data from there.... But if it has to be destroyed I need to redo that plan. So not confused... Just need deeper more clarify response based on my setup. I do appreciate you taking the time to help out as it seems my question is just getting ignored by the tech team.

[crisisacting]

{L_BUTTON_AT}UncleJohnsBand

Disconnect the USB drive to eliminate them from the listing. According to their instructions, only drives with 4 partitions require the removal process through the 'parted' command in SSH if partition 2 is 2 GB in size on each respective SD× drive. Per your previous post, it should be SDA, SDB & SDC in your setup. At this point, await their clarification before you destroy the partitioning.

[Chief]

If it matters or is helpful to anyone, I followed the "If there is no USB hard disk enclosure and SATA cable..." method to delete partitions via ssh on an F5-221.

After powering on the enclosure with no HDD installed and logging in via ssh, I just inserted one HDD, followed the steps, removed that HDD and inserted the next one without powering the chassis down... then lather, rinse, repeat until all were done.

The only difference from the provided instructions in my case was, for each HDD, partitions were listed 'sdb' instead of 'sdc'.

After that I left the enclosure powered on, re-inserted all of the HDD, then accessed it via the browser and followed the installation instructions for an install from the Internet.

The entire process took maybe 15-20 minutes, and that mostly because I kept getting distracted by other things while deleting partitions.

Interestingly, it looks like the HDD did not lose any data. I was expecting to have to reload everything from a recent backup, but as near as I can tell all directories and files survived the install to 5.1.40. This was a pleasant surprise.

The only side effect I've noted from recent 5.1.xx TOS versions, is that shutdowns seem to take a bit longer than earlier versions used to.
Normally this would not be easy to notice, but due to both of my F5-221's periodically flooding my network with ARP requests, I've set up Scheduled Tasks to shut them down in the early morning hours, then turn them back on again, which minimizes their ARP request output day-to-day.

Originally I had the shut-down and power on configured to occur five minutes apart, but sometimes I find one NAS or the other is not powered on again the next morning. I think this is because the shut-down process sometimes takes slightly longer than five minutes now, so the power-on event doesn't get triggered. To try to resolve that, I've just set the power-on event to seven minutes after the shut-down event, and should know if that fixes things in the next day or two.

[Gremlin]

{L_BUTTON_AT}Chief

Thanks for your post. Interesting.