Raspiblitz: Error formatting SSD 1 TB (Sandisk)

[Stickiesteez]

This is the error I received after the second attempt to format the SSD. The first time the error was: /dev/sda: unrecognised disk label.

Any solutions for this problem?

Thanks in advance.

[CoderBoogs]

@Stickiesteez What SSD case are you using? I ran into the same issue last week but then I entered a 32GB usb to run the BTFS then I got past this error as well

[Stickiesteez]

@CoderBoogs I use the UGREEN USB C 3.1 Gen 2 case. Could you explain in little bit more detail how you fixed this? I just noticed #1120. Rootzoll mentioned that the procedure was not able to remove a partition. If I a create a new primary partition on the SSD, won't that fix the issue?
I'm a newb so please forgive me..

[CoderBoogs]

@Stickiesteez hey I am a noob as well. But I was was having this same issue till I tried this

“Your HDD/SSD will get formatted with the linux standard file system EXT4. If you want to try out the experimental new BTRFS that RaspiBlitz supports since v1.4 - you need to start the setup with an additional 32GB USB thumb drive connected to the second USB3 port of the RaspberryPi. Then you will unlock this new secret feature.”

after I did a re-flash to SD and restarted the instructions from the beginning and when it came to the formatting the SSD this issue went away. This error is very annoying I almost gave up here. Before I did this I tried to format the drive using windows and did a fresh restart and it didn’t work. But I was using the wrong case it appears you are using the case they recommend so if this solution doesn’t work then it’s beyond my knowledge

[openoms]

Need to clean the partitions to solve this.

All DATA WILL BE LOST on the disk!

Connect the disk to your desktop and format to FAT32.
Booting with a fresh SD the RaspiBlitz script will format it appropriately to EXT4.

[openoms]

@rootzoll there are multiple reports of this problem on TG as well.

The install script needs to be forced to clean all partitions (if there is no data to restore) otherwise every disk running windows previously will continue to have this issue.

[rootzoll]

@openoms tagged for v1.6 release - I dont have a windows system. Whats the way to test this with a osx or linux around?

[openoms]

@openoms tagged for v1.6 release - I dont have a windows system. Whats the way to test this with a osx or linux around?

Windows creates a 100 MB partition as the first and a second to fill the disk (where the system deploys). If someone just formats the disk or not even that they are left with two partitions on the disk causing the problem with the datadrive script.

[rootzoll]

@openoms in home.admin/config.scripts/blitz.datadrive.sh before formatting there is a part that should take care of getting rid of every partitions on the disk before making the raspiblitz own partitions and formatting. Have you any idea why it would not be able to get rif of those windows partitions:

beginning from line 346:

  # wipe all partitions and write fresh GPT
  >&2 echo "# Wiping all partitions"
  for v_partition in $(parted -s /dev/${hdd} print|awk '/^ / {print $1}')
  do
   sudo parted -s /dev/${hdd} rm ${v_partition}
   sleep 2
  done

All ideas very much appriciated to solve this in future versions.

[Stickiesteez]

Thanks, I cleaned the partitions and formatted to FAT32. This resolved the corrupted GPT tables issue but the script won't get past the 'waiting until the partion gets available' message. Tried it with a fresh SD and another 1TB SSD (not running windows before) and having the same issue. Bought the exact same devices as on the shopping list. Really at a loss here..

[openoms]

You don't have anything else plugged in the RPi, right (like a USB drive)?
Can you please share the exact model of the disks you have tried?

[Stickiesteez]

Nothing else plugged in. Tried it both times with a Sandisk Sdssda-1T00-G26 Solid State Drive Plus, 1Tb, Tot 535Mb/S. Case i use is the UGREEN USB 3.0.

[openoms]

Thanks, your hw seems right, still something is wrong which is not present with other users or in our own tests.
I cannot think anything else right now apart from maybe try again plugging the disk in one of the black USB2 ports which can result to different behaviour with the disk drivers.

[Stickiesteez]

This worked and it is syncing now! Thank you! Can I plug the SSD in one of the blue ports after the syncing is done or wouldn't you recommend this?

[openoms]

This worked and it is syncing now! Thank you! Can I plug the SSD in one of the blue ports after the syncing is done or wouldn't you recommend this?

This suggests that the problem lies with the disk adapter and the usual UASP compatibility issues. Can you please share the exact model you are having in a link or photo please?

Syncing is likely quite slow and cannot tell if there will be new errors when plugged back to the USB3 ports. Would recommend using another disk adapter from this list: https://github.com/rootzoll/raspiblitz/issues/691#issuecomment-520526004 for example.

[rootzoll]

there are multiple reports of this problem on TG as well.

The install script needs to be forced to clean all partitions (if there is no data to restore) otherwise every disk running windows previously will continue to have this issue.

@openoms the script in v1.5 already tries to get rid of all partitions with

  for v_partition in $(parted -s /dev/${hdd} print|awk '/^ / {print $1}')
  do
   sudo parted -s /dev/${hdd} rm ${v_partition}
   sleep 2
  done

Is there a better way to remove all partions?

At least for now I added a debug line to maybe see on which command and which parameter that error occurs.

TODO: restest the formatting before v1.6 release

[quirdan]

Is there a better way to remove all partions?

Non interactive fdisk delete all partitions:
sfdisk --delete /dev/sda

Wipe all signatures:
wipefs -a /dev/sda

Quick and dirty (zero out the first block):
dd if=/dev/zero of=/dev/sda bs=512 count=1

[rootzoll]

Thanks @quirdan I replaced the partition wiping part. I cannot reproduce the initial error on my test machines, but I think its the best we can do for the next release. This fix will be part of v1.6RC1 .. would be great if @Stickiesteez or @openoms can test if this eliminates the problems with the former windows boot drives.

[raspito]

Hi guys, I believe my ugreen enclosure is faulty. It was disappearing from my pi, so I formatted it on my pc and tested it with HD Sentinel. Got a stack of CRC errors, and maxed out at 10MB/s on a standard copy.

So, I put the same drive into this wavlink enclosure, and had no more CRC errors and over 100MB/s on my windows machine.
https://www.amazon.com/WAVLINK-External-Enclosure-Function-Tool-Free/dp/B082PFJLJG

When I tried to set it up with a fresh install, it took forever to format, but made it all the way to the last step (formatting) where it hung for about 10 minutes before failing. Getting another ugreen drive, unless there's a preferred option now.

[raspito]

Update to my issue:

Got the new ugreen case, tested on windows, perfect.
Tried the drive in the old ugreen again, same problem.
Switched the (USB-USBC) cable - problem carried with it.

So, beware of the cable that comes with the ugreen drive!

[rootzoll]

TODO for v1.6 release: Test formatting of HDD again during a complete fresh setup.

[countfloyd66]

I had similar issues with my SanDisk SSD. Not at the formatting stage mind you, but during the sync process.

Plugging it into the USB2 port and not the blue USB3 port seems to be making all the difference.

And yes, dont cable tie your usb cables for this project.

You can also plug the drive into another *nix box and format ext4 / low level sector scan before mounting in the RBlitz

[raspito]

I am finally syncing the blockchain with the replacement enclosure plugged into the USB2 port. Are we paying a major performance penalty (vs USB3) here? FWIW I am using a Crucial MX500 drive in the recommended ugreen enclosure.

[rootzoll]

@raspito yes using USBv2 instead v3 will cost you a good chunk of speed on the syncing here.

[raspito]

So guess what, even with USB2 it crashed again. I tried using a fresh mynode image to see if it was anything in the blitz codebase but same issue.

Noticed this in the mynode github: https://github.com/mynodebtc/mynode/issues/72

So, I wonder if this ugreen enclosure is the issue. Have purchased an orico and will report back.

[openoms]

@raspito the Crucial MX500 is likely drawing too much power: https://github.com/rootzoll/raspiblitz/issues/905#issuecomment-581526545
Powerwise the USB2 port is likely even worse.

The X825 board gives you a way to power the disk externally or use another tested disk model (like the Sandisk mentioned in this issue).
You can use that Crucial drive in an old laptop/PC instead.

[raspito]

Oh, thank you @openoms.

I wonder why the RP4 wasn't specced to power external SSDs. Instead of that complicated board, could I use a powered USB3 hub to do ensure it's getting enough juice?

[openoms]

Why do you think the X825 is complicated?
It is essentially a SATA-USB adapter with optional external power.

The known UASP issues might be present with the powered USB hubs too. I am not aware of any tested with the RPi4, but if you have one try it. If the UASP seems to be the problem it should work through the USB2 (slow).

[raspito]

You're right, though it takes the fan power right.. so more steps?

Going to try this: UASP ready.

http://www.orico.cc/usmobile/product/detail/id/3518

[openoms]

You're right, though it takes the fan power right.. so more steps?

No. The X825 board can power the RPi through the GPIO , but both can be powered separately as well via barrel connector to the X825 and a USBC to the RPi.
The less power hungry SSD-s can be powered through the USB3 as with any other USB-SATA adapter. (see the issue I linked above)

Going to try this: UASP ready.
http://www.orico.cc/usmobile/product/detail/id/3518

Mind you the case you linked is for a 3.5" HDD, not 2.5" SSD.

[raspito]

I understand you, but I've already got a high quality SSD, I don't really want to buy another. The powered case above allegedly supports 2.5 and 3.5 inch drives (scroll down to the product description image), so this could be an easy fix.

Will report back! Thanks for your help.

[raspito]

6 hours later and I am at 15% blockchain sync. Great find regarding the power draw of the larger SSDs, @openoms.

This powered enclosure works fine with the Crucial MX500 and gives it the juice it needs.
http://www.orico.cc/usmobile/product/detail/id/3518

Obviously, it's bigger than I'd like, but there don't appear to be powered 2.5" enclosures around. Will report back in after some substantial uptime.

@rootzoll I'd recommend making it clear that the raspberry pi can't provide the required power to certain 1TB SSDs so that people buy the recommended drives and not their personal favorites (or what's on sale).

[rootzoll]

@raspito i added already the notice that people should try to follow the shopping list as close as possible to prevent errors - but I will add a special notice for that also

[rootzoll]

Tested for v1.6 - looking good. Closing issue.