Copy Root to USB is not terminating

Setup, Configuration and Use Installation
1
  • Platform information:
    • Hardware: _Raspberry PI 3B+
    • OS: openhabian-pi-raspbian-201908050414-gitca0976f-crc6a66b5a1.img
    • openHAB version:2.4
  • Issue of the topic: Move Root to USB just keeps on copying. It doesn’t seem to end.
    At the end of the current log, there’s a message saying the copying is 77% done. But this number goes up and down. It has been as high as 98% but now it is back down.
    I have been waiting for 1h20mins now. This looks like a never ending loop.

Can anyone help?
Thanks in advance,
Wim
------------------------------------------------------------------ LOG --------------------------------

Log:
2019-08-16_18:28:10_CEST [openHABian] Checking for root privileges… OK
2019-08-16_18:28:10_CEST [openHABian] Loading configuration file ‘/etc/openhabian.conf’… OK
2019-08-16_18:28:11_CEST [openHABian] openHABian configuration tool version: [master]v1.5-502(1741bb7)
2019-08-16_18:28:11_CEST [openHABian] Checking for changes in origin… OK
max_usb_current already set, ok
stopping openHAB
1+0 records in
1+0 records out
512 bytes copied, 0.0192202 s, 26.6 kB/s
partitioning on ‘/dev/sda’
Checking that no-one is using this disk right now … OK

Disk /dev/sda: 57.8 GiB, 62058921984 bytes, 121208832 sectors
Disk model: DataTraveler 3.0
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Created a new DOS disklabel with disk identifier 0x725fb44d.
/dev/sda1: Created a new partition 1 of type ‘Linux’ and of size 57.8 GiB.
Partition #1 contains a ext4 signature.
/dev/sda2: Done.

New situation:
Disklabel type: dos
Disk identifier: 0x725fb44d

Device Boot Start End Sectors Size Id Type
/dev/sda1 2048 121208831 121206784 57.8G 83 Linux

The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.
creating filesys on ‘/dev/sda1’
mke2fs 1.44.5 (15-Dec-2018)
/dev/sda1 contains a ext4 file system labelled ‘oh_usb’
last mounted on /mnt on Fri Aug 9 14:05:02 2019
Creating filesystem with 15150848 4k blocks and 3792896 inodes
Filesystem UUID: 0ea8d7dd-4088-44c8-a6cb-a4ecab8afb2d
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424

Allocating group tables: done
Writing inode tables: done
Creating journal (65536 blocks): done
Writing superblocks and filesystem accounting information: done

mounting new root ‘/dev/sda1’

copying root sys, please be patient. Depending on the speed of your USB device, this can take 10 to 15 min

2,021,696,887 77% 16.08kB/s 10:03:46 ^Cr#47141, ir-chk=2877/66469)

2

Use zram instead (option 6A), root on USB is no better than SD anyway.

3

Markus, thanks for your reply. The goal was indeed to configure for more stability. I’ve been reading many opinions on ways to increase stability. Some say USB. Others say to reduce writes to the sdcard. And that is what the zram option does, isn’t it? But there doesn’t seem to be consensus…
I also understand that using a UPS is actually the best thing to do.
Any comments?
Thanks
Wim

4

zram basicly runs all write extensive stuff to ramdisk which indeed significantly improves lifespan of given SD card.

however be cautious with zram, as shutting down/powerfailue etc. will definitely harm your OH instalation (!)
I’m definitely using UPS on RPI which runs zram, but not yet ready for production (for me)

(btw some say USB and SD are the same, well might be, but from years of real experiences USB lasts way longer than any SD card I’ve had… so I’m usign USB where possible by default.)

We are having some discussion about zram here

and here is zram sync discussion (which should make things way more failue-proof)

5

It’s the same technology. Flash memory has a limited number of times you can write to a given area of memory. You may be more likely to get higher quality flash in USB thumb drives, but both will wear out the same.

It’s also worth noting that the more common cause of corrupted SD cards/USB thumb drives is not wear out but loss of power. Because of the way flash memory works, if the device happens to be writing when there is a loss of power, you can lose not just what was being written but parts of other files as well resulting in corruption. So even with the zram config, an UPS of some sort is a must for long term reliability. Or some other mitigation like a recent clone of the system that can be swapped in.

6

it might be same technology, but I’m convinced that USB’s are made better as original usage of SDcards has been started as photostorage of digital cameras, instead of USB’s which were designed from very begining to be used as storage by regular joe’s

anyway, proper backup is always best solution against any kind of corruption on any media.

7

Or I had an old laptop SSD I placed in a USB case. The larger size may reduce overall writes too. Etcher complained about imaging a 120GB USB drive. :face_with_raised_eyebrow:

8
9

SSDs are slightly different. First if all that are way over provisioned so that 120 GB drive may have 250 GB of any flash. They can also include logic to better keep track of wear on the individual sectors and capacitors to help with per loss problems.

In server farm tests, SSDs last just as long as She’s and sometimes even longer. But thumb drives and sd cards have none of that extra stuff to improve their reliability and longevity.

10

Yes, women last longer than men LOL
(I know it was spell check)

1 Like
11

They have a DRAM cache so way less writes actually go to flash under common use conditions.