Syncloud unreachable, ping only works (MAYBE SOLVED)

Hi,
Syncloud was fine 3 days ago when I switched it off. Today it cannot be reached in any way (web browser, SSH), in local network either. The only kind of interaction that I have is the ping and it works (sorry for the Italian):

C:\Users\simon>ping 192.168.1.14

Esecuzione di Ping 192.168.1.14 con 32 byte di dati:
Risposta da 192.168.1.14: byte=32 durata<1ms TTL=64
Risposta da 192.168.1.14: byte=32 durata<1ms TTL=64
Risposta da 192.168.1.14: byte=32 durata<1ms TTL=64
Risposta da 192.168.1.14: byte=32 durata<1ms TTL=64

Statistiche Ping per 192.168.1.14:
    Pacchetti: Trasmessi = 4, Ricevuti = 4,
    Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
    Minimo = 0ms, Massimo =  0ms, Medio =  0ms

While in the web browser I get a “ERR_CONNECTION_REFUSED” error (sorry for the Italian again)r:

Impossibile raggiungere il sitoConnessione negata da 192.168.1.14.
Prova a:

Verificare la connessione
Controllare il proxy e firewall
ERR_CONNECTION_REFUSED

Any idea of any other test that I can do before phisically connecting a screen and a keyboard to the machine? Or better to say: I’m gonna connect them…but what’s next? Thanks in advance.
Simone

p.s. that machine is up to date with latest Syncloud platform. It was updated successfully 3 days ago, if I’m not wrong

===update===
After having attached screen and kbd, I have found that the OS was starting in “emergency mode”. I have inserted root ps and asked the system to reboot normally and now it works. HEre below a picture of the console, sorry for that but it’s the only way to post it:

You could go up or down on thet screan to find non OK service google says (debian - How to determine exactly why Systemd enters emergency mode - Unix & Linux Stack Exchange)

You could try to find the reason for that:

journalctl -xb | egrep -i '(error|fail|warn)'

Thanks a lot, @boris. It seems like the SD card has gone, what is your opinion? Sorry for the picture, that’s the only way I have now:


Thanks

Simone

Ah that makes sense, just replace the sd.

What device is this?
Syncloud hc1/2 does not reqlly store anything usefull on sd so just write fresh sd image.

Other devices like Syncloud H4 use it as main OS storage, so write fresh image add users and install/restore apps.

That is why you need a daily backup enabled.

Off-site mirror device is also great in this case.

It’s an Odroid HC4. SD refresh makes me anxious about rebuilding the RAID. But…that’s it. What do I need to perform the daily backup? Would you be so kind to redirect me to some documentation? Thx a lot

Simone

Raid is now supported by Syncloud but it is btrfs filesystem you would to add two empty disks and then copy your data to it.

Auto backup schedule can be also enabled

In case you have a mdadm/ext4 RAID 1 array you get this error through GUI:

Previous change
A dependency job for opt-disk-external.mount failed. See 'journalctl -xe' for details.

Hi @boris ,
this is an issue for me: I have an existing RAID1 array in ext4 file system (mdadm), reassembling it is a piece of cake but , as far as I understand, it is no more supported. Formatting those disks is not a doable option for me because the amount of data they contain is much bigger than any other storage device that I own, physical or cloud. I built that RAID with the precise idea of never formatting it and expanding when necessary.
What do you suggest? It seems like that EXT4 partitions can be converted to butter fs, but it’s risky and time consuming: I could convert one disk of the RAID, verify that it works and then use it as master to rebuild the RAID.
Frankly speaking I would prefere to have a retrocompatibility option in Syncloud, it’s not important that it works through the GUI, the command line is welcome as well ;-). I don’t think to be the only person who has “invested” in MDADM/EXT4 RAID disks…
I’m looking forward to receiving some news to finish restoring the system (faulted SD). Thanks a lot

Simone

p.s. here follows the output of journalctl -xe

root@syncloud:~# journalctl -xe
Dec 27 00:04:16 syncloud sh[1790]: XMT:  | X-- Request renew in  +3600
Dec 27 00:04:16 syncloud sh[1790]: XMT:  | X-- Request rebind in +5400
Dec 27 00:04:16 syncloud sh[1790]: XMT: Solicit on eth0, interval 109150ms.
Dec 27 00:04:16 syncloud dhclient[1843]: XMT: Solicit on eth0, interval 109150ms.
Dec 27 00:06:05 syncloud sh[1790]: XMT: Forming Solicit, 655350 ms elapsed.
Dec 27 00:06:05 syncloud sh[1790]: XMT:  X-- IA_PD 06:49:00:5e
Dec 27 00:06:05 syncloud sh[1790]: XMT:  | X-- Request renew in  +3600
Dec 27 00:06:05 syncloud sh[1790]: XMT:  | X-- Request rebind in +5400
Dec 27 00:06:05 syncloud sh[1790]: XMT: Solicit on eth0, interval 131420ms.
Dec 27 00:06:05 syncloud dhclient[1843]: XMT: Solicit on eth0, interval 131420ms.
Dec 27 00:06:26 syncloud snapd[1651]: 2022/12/27 00:06:26.874659 store.go:1174: assert type: snap-declaration, key: 16/platform.
Dec 27 00:06:26 syncloud snapd[1651]: 2022/12/27 00:06:26.946964 database.go:568: Syncloud hack: failed signature verification:
Dec 27 00:06:26 syncloud snapd[1651]: 2022/12/27 00:06:26.948576 autorefresh.go:215: Cannot prepare auto-refresh change: not imp
Dec 27 00:06:26 syncloud snapd[1651]: 2022/12/27 00:06:26.948768 stateengine.go:101: state ensure error: not implemented yet
Dec 27 00:07:16 syncloud platform.backend[3546]: cert/generator.go:83        certificate info        {"category": "certificate",
Dec 27 00:07:16 syncloud platform.backend[3546]: cert/generator.go:86        not regenerating real certificate        {"category
Dec 27 00:07:16 syncloud platform.backend[3546]: 2022/12/27 00:07:16 public ipv4: 79.43.23.27
Dec 27 00:07:16 syncloud platform.backend[3546]: 2022/12/27 00:07:16 [DEBUG] POST https://api.syncloud.it/domain/update
Dec 27 00:07:17 syncloud platform.backend[3546]: cron/backup_job.go:68        auto backup is disabled
Dec 27 00:08:17 syncloud sh[1790]: XMT: Forming Solicit, 655350 ms elapsed.
Dec 27 00:08:17 syncloud sh[1790]: XMT:  X-- IA_PD 06:49:00:5e
Dec 27 00:08:17 syncloud sh[1790]: XMT:  | X-- Request renew in  +3600
Dec 27 00:08:17 syncloud sh[1790]: XMT:  | X-- Request rebind in +5400
Dec 27 00:08:17 syncloud sh[1790]: XMT: Solicit on eth0, interval 121000ms.
Dec 27 00:08:17 syncloud dhclient[1843]: XMT: Solicit on eth0, interval 121000ms.
Dec 27 00:10:18 syncloud sh[1790]: XMT: Forming Solicit, 655350 ms elapsed.
Dec 27 00:10:18 syncloud sh[1790]: XMT:  X-- IA_PD 06:49:00:5e
Dec 27 00:10:18 syncloud sh[1790]: XMT:  | X-- Request renew in  +3600
Dec 27 00:10:18 syncloud sh[1790]: XMT:  | X-- Request rebind in +5400
Dec 27 00:10:18 syncloud sh[1790]: XMT: Solicit on eth0, interval 112530ms.
Dec 27 00:10:18 syncloud dhclient[1843]: XMT: Solicit on eth0, interval 112530ms.
Dec 27 00:12:10 syncloud sh[1790]: XMT: Forming Solicit, 655350 ms elapsed.
Dec 27 00:12:10 syncloud sh[1790]: XMT:  X-- IA_PD 06:49:00:5e
Dec 27 00:12:10 syncloud sh[1790]: XMT:  | X-- Request renew in  +3600
Dec 27 00:12:10 syncloud sh[1790]: XMT:  | X-- Request rebind in +5400
Dec 27 00:12:10 syncloud sh[1790]: XMT: Solicit on eth0, interval 126250ms.
Dec 27 00:12:10 syncloud dhclient[1843]: XMT: Solicit on eth0, interval 126250ms.
Dec 27 00:12:17 syncloud platform.backend[3546]: cert/generator.go:83        certificate info        {"category": "certificate",
Dec 27 00:12:17 syncloud platform.backend[3546]: cert/generator.go:86        not regenerating real certificate        {"category
Dec 27 00:12:17 syncloud platform.backend[3546]: 2022/12/27 00:12:17 public ipv4: 79.43.23.27
Dec 27 00:12:17 syncloud platform.backend[3546]: 2022/12/27 00:12:17 [DEBUG] POST https://api.syncloud.it/domain/update
Dec 27 00:12:18 syncloud platform.backend[3546]: cron/backup_job.go:68        auto backup is disabled
lines 998-1039/1039 (END)

Do not think that I have removed mdadm raid support, what do you see on storage page in partition mode?

this is what I see in partition mode:

image

for the moment I have tried disk mode only without initialization to avoid data loss.

update: it works! Partition (raid) is now activated.
Suggestions:

  1. make the help button a little more clear about the 2 modes. Currently it is about disks only;
  2. make the “save” button disappear after the activation of the partition has gone fine. Currently it remains (see below) and in case you press it you get an error (“not a btrfs file system”). Users could get bewildered :wink:
    image

Now only one problem remains: the system partition cannot be extended or, better to say, the “extend” button is not visible in GUI:

image

Any suggestion? Thx

Could you open this url in your browser and post the response?

[device]/rest/storage/boot/disk

Where device is your IP or domain name.

Partition vs disk is a confusing concept right now I agree!

Partition mode was the original option where device would create or use an existing partition. Multi disk was possible but absolutely not acceptable as it required a terminal. Filesystem ext4 + hacks for md adm raid.

Disks mode is the new automated way of adding multiple (no terminal needed). Filesystem is btrfs which supports multiple disks and does not even need to have partitions.

I hope users migrate to disks even a single one eventually but I will keep partitions mode of cause.

Here it is:

Unauthorised

You need to login to your device first and see internal memory page first. Then change the url in browser.

Open this first and see the internal disk page as you showed me.

https://[device]/internalmemory

Then change it in the browser to this:

https://[device]/rest/storage/boot/disk

And hit enter to see the result

{"success":true,"data":{"size":"3G","device":"/dev/mmcblk0p2","mount_point":"/","active":false,"fs_type":"ext4","extendable":false}}

Can you run this
/snap/platform/current/bin/boot_extend.sh

it worked! Thanks. Here follows the output, in case you find something relevant to understand why Syncloud had flagged the partition as “extendable”:false:

root@syncloud:~# /snap/platform/current/bin/boot_extend.sh

Welcome to fdisk (util-linux 2.33.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help):

Command (m for help):
Disk /dev/mmcblk0: 59.5 GiB, 63864569856 bytes, 124735488 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x6d674511

Device         Boot  Start     End Sectors  Size Id Type
/dev/mmcblk0p1        2048  526335  524288  256M 83 Linux
/dev/mmcblk0p2      526436 6817792 6291357    3G 83 Linux

Command (m for help): Partition number (1,2, default 2):
Partition 2 has been deleted.

Command (m for help): Disk /dev/mmcblk0: 59.5 GiB, 63864569856 bytes, 124735488 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x6d674511

Device         Boot Start    End Sectors  Size Id Type
/dev/mmcblk0p1       2048 526335  524288  256M 83 Linux

Command (m for help): Partition type
   p   primary (1 primary, 0 extended, 3 free)
   e   extended (container for logical partitions)
Select (default p): Partition number (2-4, default 2): First sector (526336-124735487, default 526336): Last sector, +/-sectors or +/-size{K,M,G,T,P} (526436-124735487, default 124735487):
Created a new partition 2 of type 'Linux' and of size 59.2 GiB.
Partition #2 contains a ext4 signature.

Command (m for help):
Disk /dev/mmcblk0: 59.5 GiB, 63864569856 bytes, 124735488 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x6d674511

Device         Boot  Start       End   Sectors  Size Id Type
/dev/mmcblk0p1        2048    526335    524288  256M 83 Linux
/dev/mmcblk0p2      526436 124735487 124209052 59.2G 83 Linux

Command (m for help): The partition table has been altered.
Syncing disks.

resize2fs 1.44.5 (15-Dec-2018)
Filesystem at /dev/mmcblk0p2 is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 8
The filesystem on /dev/mmcblk0p2 is now 15526131 (4k) blocks long.

root@syncloud:~#