Posts by smvb64

Quote from Zoki

I hope we can call this closed now.

Everything looks A-OK - it's actually working better than it did before - resetting would cause the system to hang. I'll set the resolution to resolve now.

Huge thanks again all, for helping with this issue to the end. I'll donate to the OMV project to help out too.

Cheers and have a Happy Holiday!

SM

Quote from Zoki

Try setting a password for root and reboot

Set the password for root and was able to boot successfully! I think everything is working correctly now

Any other changes we should make?

Thanks,

SM

Quote from Soma

Nice,

For now, just powerdown the Pi, plug back your external drives and boot up.

See if everything is green on the OMV GUI and if docker containers are also OK.

About the 1st pic, if the above has no issues, you can ignore it.

I'll poke Zoki for confirmation on the next phrases:

As long as you can get to root with sudo su -, this makes not much difference AFAIK.

If not, run via SSH, sudo passwd root and it will ask for a password.

You won't see nothing on the screen while you type.

If all is good, change the thread to resolved, 😉

Display More

I powered down the pi and booted back up - Picture 1 happened again - after pressing enter I was able to log back in.

sudo su - did work and was able to access root@OMVSUPER:~#

Docker containers are functional and were able to access my shared network files as well.

When you refer to "see if everything is green on the OMV GUI"

do you mean this screen?

OMV

These are the services I have enabled.

The only issue is just the press enter to boot - everything else looks A-OK

Quote from Zoki

This error will occur if the home directory of root does not exist or root does not have a password set. Can you check that?

If you can boot and get to an admin shell you are good for the moment, but in the long run, you should get this error resolved. If it is a missing home directory, you will not be able to log in via ssh as root.

Past the output of:

cat /etc/passwd | grep root

ls -la /

ls -la /root

Display More

Yes - root does not have a password set - I can create one

cat /etc/passwd | grep root

root:x:0:0:root:/root:/bin/bash

ls -la /

total 68
drwxr-xr-x  19 root root  4096 Aug 21 10:25 .
drwxr-xr-x  19 root root  4096 Aug 21 10:25 ..
lrwxrwxrwx   1 root root     7 Dec  2  2020 bin -> usr/bin
drwxr-xr-x   4 root root  3584 Dec 31  1969 boot
drwxr-xr-x  18 root root  4080 Dec 21 17:24 dev
drwxr-xr-x 102 root root  4096 Dec 21 17:27 etc
drwxr-xr-x   2 root root  4096 Dec 15  2020 export
drwxr-xr-x   3 root root  4096 Dec  2  2020 home
lrwxrwxrwx   1 root root     7 Dec  2  2020 lib -> usr/lib
drwx------   2 root root 16384 Dec  2  2020 lost+found
drwxr-xr-x   2 root root  4096 Dec  2  2020 media
drwxr-xr-x   2 root root  4096 Dec  2  2020 mnt
drwxr-xr-x   4 root root  4096 Dec 27  2020 opt
dr-xr-xr-x 274 root root     0 Dec 31  1969 proc
drwx------   6 root root  4096 May 15  2021 root
drwxr-xr-x  28 root root  1040 Dec 21 17:53 run
lrwxrwxrwx   1 root root     8 Dec  2  2020 sbin -> usr/sbin
drwxr-xr-x  10 root root  4096 May 29  2021 srv
dr-xr-xr-x  12 root root     0 Dec 31  1969 sys
drwxrwxrwt   6 root root   120 Dec 21 17:39 tmp
drwxr-xr-x  11 root root  4096 Aug 21 15:53 usr
drwxr-xr-x  13 root root  4096 Dec 26  2020 var

ls -la /root

Quote

pi@OMVSUPER:~ $ sudo su -

root@OMVSUPER:~# ls -la /root

total 44

drwx------ 6 root root 4096 Dec 21 18:07 .

drwxr-xr-x 19 root root 4096 Aug 21 10:25 ..

-rw------- 1 root root 1272 Dec 21 18:07 .bash_history

-rw------- 1 root root 857 Dec 26 2020 .bashrc

drwx------ 2 root root 4096 Dec 27 2020 .cache

drwx------ 3 root root 4096 May 15 2021 .config

-rw------- 1 root root 278 Dec 26 2020 .inputrc

drwxr-xr-x 3 root root 4096 Dec 27 2020 .local

-rw-r--r-- 1 root root 161 Dec 26 2020 .profile

drwx------ 2 root root 4096 Dec 26 2020 .ssh

-rw-r--r-- 1 root root 277 Dec 21 18:00 .wget-hsts

Display More

Thanks again guys,

SM

Quote from Soma

Can you connect the Pi to a screen to see if it boots normal?

Or if it shows any error?

If it boots, you can at least, run sudo raspi-config and activate the SSH.

If I remember properly, it's 3 Interface options

I just connected it to a monitor and we have life!

Picture 1

and after pressing enter

Picture 2

I am able to get access to my server using the web browser and access SSH again.

Any other steps I should do? I think we got it!

Thanks,

SM

Quote from Soma

Here you made a mistake:

The /dev/sda2 fstab should point to /boot from the SDcard.

In your case PARTUUID="815c7a01-01"

It will be the fastest route, if you want.

Honestly, don't see how an update could mess anything on the OS unless you did something out of the gui.

Display More

Oops - I see the mistake - I flashed a new pi image (Unable to access SSH anymore) - made sure it was using the latest version of the Bootloader and booting from the SD card first

Ran blkid got

root@raspberrypi:~# cd /boot
root@raspberrypi:/boot# cp -a cmdline.txt cmdline.old
root@raspberrypi:/boot# blkid
/dev/mmcblk0p1: LABEL_FATBOOT="boot" LABEL="boot" UUID="C839-E506" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="701962cf-01"
/dev/mmcblk0p2: LABEL="rootfs" UUID="568caafd-bab1-46cb-921b-cd257b61f505" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="701962cf-02"
/dev/sda1: LABEL_FATBOOT="boot" LABEL="boot" UUID="EBBA-157F" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="4b9bc9e0-01"
/dev/sda2: LABEL="rootfs" UUID="b3ce35cd-ade9-4755-a4bb-1571e37fc1b9" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="4b9bc9e0-02"
root@raspberrypi:/boot#

Made the nano cmdline.txt change

console=serial0,115200 console=tty1 root=PARTUUID=4b9bc9e0-02 rootfstype=ext4 fsck.repair=yes rootwait

and the nano fstab change

proc            /proc           proc    defaults          0       0
PARTUUID=701962cf-01  /boot           vfat    defaults          0       2
PARTUUID=4b9bc9e0-02            /       ext4    noatime,nodiratime,defaults     0 1
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that
# >>> [openmediavault]
/dev/disk/by-label/4TB          /srv/dev-disk-by-label-4TB      ext4    defaults,nofail,user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl 0 2
/dev/disk/by-label/PLEXRSYNC            /srv/dev-disk-by-label-PLEXRSYNC        ext4    defaults,nofail,user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl 0 2
/dev/disk/by-uuid/695e0790-f896-4ef0-9c86-237df935f00f          /srv/dev-disk-by-uuid-695e0790-f896-4ef0-9c86-237df935f00f      ext4    defaults,nofail,user_xattr,usrjquota=aquota.user,grp>
# <<< [openmediavault]

Rebooted the Pi and unfortunately get connection refused after a few moments

Quote

Honestly, don't see how an update could mess anything on the OS unless you did something out of the gui.

Ok good to know - the only change I made was running the argon1.sh code outside of the gui. - I normally only use the gui or docker

Quote from Soma

Damn, was really hoping this would fix it.

Ok, for hybrid boot, you'll need to change the bootloader order to start first from SDcard:

As I explained previously on #4, run sudo raspi-config and set the bootloader for SDcard.

Power on the Pi with just the SDcard.

Run this commands and post them all here in a code box:

Display Spoiler

sudo su -

cd /boot

cp -a cmdline.txt cmdline.old

Now, with the Pi still ON, plug the M.2 drive and run this:

blkid # <- It will show something like this:

Code

pi@chaleira:~ $ blkid
/dev/mmcblk0p1: LABEL_FATBOOT="boot" LABEL="boot" UUID="4BBD-D3E7" TYPE="vfat" PARTUUID="738a4d67-01"
/dev/mmcblk0p2: LABEL="rootfs" UUID="45e99191-771b-4e12-a526-0779148892cb" TYPE="ext4" PARTUUID="738a4d67-02"
/dev/sda1: LABEL_FATBOOT="boot" LABEL="boot" UUID="4BBD-D3E7" TYPE="vfat" PARTUUID="738a4d67-01"
/dev/sda2: UUID="feb67ccf-d57a-41cc-a1d0-5b0d8e6011da" TYPE="ext4" PARTUUID="1c310018-1d9f-7244-be0b-a03609427f8d"

Take note of your's PARTUUID=xxxxxxxxx from the /dev/sda2

Now, to make the SDcard boot the sda2 partition:

nano cmdline.txt # <- Open the file on the editor nano and change the PARTUUID= to the same as the /dev/sda2

In my above example, it was changed from this:

console=serial0,115200 console=tty1 root=PARTUUID=738a4d67-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

To this:

console=serial0,115200 console=tty1 root=PARTUUID=1c310018-1d9f-7244-be0b-a03609427f8d rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

Now, Ctrl+O, Enter, Ctrl+X

The last thing to do, is modify the old fstab on the M.2 to see the boot partition from the SDcard (still as root):

Display Spoiler

mkdir -p /mnt/rootfsM2 # <- In case you delete it

mount /dev/sda2 /mnt/rootfsM2 # <- To have access to the old ROOT.

cd /mnt/rootfsM2/etc

cp -a fstab fstab.old # Always good to make a backup copy

nano fstab # <- Now change the PARTUUID=xxxxxxx of the /boot to the one from your's mmcblk0p1 from above blkid

Ctrl+O, Enter, Ctrl+X

cd /

umount /dev/sda2

Reboot the Pi with both SDcard and the M.2 plugged in:

reboot now and keep fingers crossed,

If the M.2 filesystems is really OK, the Pi will read the SD /boot partition and the cmdline.txt will point to the M.2 sda2 ( / ) and load it.

Good luck,

Display More

- I ran blkid and got this

Quote

/dev/mmcblk0p1: LABEL_FATBOOT="boot" LABEL="boot" UUID="C839-E506" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="815c7a01-01"

/dev/mmcblk0p2: LABEL="rootfs" UUID="568caafd-bab1-46cb-921b-cd257b61f505" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="815c7a01-02"

/dev/sda1: LABEL_FATBOOT="boot" LABEL="boot" UUID="EBBA-157F" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="4b9bc9e0-01"

/dev/sda2: LABEL="rootfs" UUID="b3ce35cd-ade9-4755-a4bb-1571e37fc1b9" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="4b9bc9e0-02"

and opened nano cmdline.txt and changed root=PARTUUID to 4b9bc9e0-02

I changed nano fstab and made sure the boot pointed to PARTUUID to 4b9bc9e0-02

I reboot the Pi and it got a little bit further this time but it didn't boot - it's refusing connections from Putty? it's upset with me aha

Do you recommend just starting from the beginning? Is it possible an OMV update can cause this? Maybe I should back up before I update.

I want to say thanks again though for all your help - learned a lot about Linux and troubleshooting boot issues

Quote from Soma

That looks good,

Run fsck -a /dev/sda1 to clear the dirty bit error but leave the bootloader as is.

Then, power down the Pi and boot it with only the M.2

If it (finally) works, great.

If it doesn't, it's possible to make a hybrid-boot:

Use the boot from the SDcard to mount the rootFS on the M.2

But try the first option,

Display More

Good stuff aha

I ran fsck -a /dev/sda1 and it automatically fixed the dirty bit error and ran it again

Quote

root@raspberrypi:~# fsck /dev/sda1

fsck from util-linux 2.36.1

fsck.fat 4.2 (2021-01-31)

/dev/sda1: 292 files, 98568/516190 clusters

Looks like it fixed it but I'm not getting the bootloader question anymore?

I tried booting it again with just the M.2 but unfortunately didn't want to boot.

We may have to do the hybrid boot method - looks like just the boot is the issue now

Thanks,

SM

root@raspberrypi:~# df -h /mnt/bootfsM2

Quote from Soma

In that case, the only last thing to try is to mount the M.2 drive and see if there's any files there:

With only the SDcard, boot the Pi.

After it's running, plug the M.2 drive.

Run this commands:

sudo su -

fdisk -l /dev/sda # <- only to confirm that it shows the sda1 && sda2 partitions

mkdir -p /mnt/bootfsM2

mkdir -p /mnt/rootfsM2

mount /dev/sda1 /mnt/bootfsM2 # <- or use the mount -t vfat /dev/sda1 /mnt/bootfsM2

df -h /mnt/bootfsM2 # <- This will show how much space is on the boot of the M2

ls -al /mnt/bootfsM2 # <- Post the output in a code box

umount /dev/sda1

mount /dev/sda2 /mnt/rootfsM2 # <- or use the mount -t ext4 /dev/sda2 /mnt/rootfsM2

df -h /mnt/rootfsM2 # <- This will show how much space is on the / root of the M2

ls -al /mnt/rootfsM2 # <- Post the output in a code box

umount /dev/sda2

If you see the files/folders on the partitions, you can try to run the fdisk on the partition instead of the drive:

fsck /dev/sda1

fsck /dev/sda2

If no files are shown, then it is possible that your M.2 is toasted,

Had one PNY 64Gb USB stick that toasted in less then a week (but I was experimenting a lot of stuff on it)

.But my M.2 is running for a long time now on the Argon without any issues (that I know of, at least)

Hope you can salvage your's.

Display More

Definitely good news! files were found - the M.2 is still kicking

root@raspberrypi:~# ls -al /mnt/bootfsM2

total 48614

drwxr-xr-x 5 root root 4096 Jan 1 1970 .
drwxr-xr-x 4 root root 4096 Dec 18 14:24 ..
drwxr-xr-x 2 root root 512 Dec 26 2020 '$RECYCLE.BIN'
-rwxr-xr-x 1 root root 26146 Dec 13 00:47 bcm2708-rpi-b.dtb
-rwxr-xr-x 1 root root 26417 Dec 13 00:47 bcm2708-rpi-b-plus.dtb
-rwxr-xr-x 1 root root 25757 Dec 13 00:47 bcm2708-rpi-b-rev1.dtb
-rwxr-xr-x 1 root root 26068 Dec 13 00:47 bcm2708-rpi-cm.dtb
-rwxr-xr-x 1 root root 25891 Dec 13 00:47 bcm2708-rpi-zero.dtb
-rwxr-xr-x 1 root root 27242 Dec 13 00:47 bcm2708-rpi-zero-w.dtb
-rwxr-xr-x 1 root root 27292 Dec 13 00:47 bcm2709-rpi-2-b.dtb
-rwxr-xr-x 1 root root 27441 Dec 13 00:47 bcm2710-rpi-2-b.dtb
-rwxr-xr-x 1 root root 29097 Dec 13 00:47 bcm2710-rpi-3-b.dtb
-rwxr-xr-x 1 root root 29716 Dec 13 00:47 bcm2710-rpi-3-b-plus.dtb
-rwxr-xr-x 1 root root 27429 Dec 13 00:47 bcm2710-rpi-cm3.dtb
-rwxr-xr-x 1 root root 28485 Dec 13 00:47 bcm2710-rpi-zero-2.dtb
-rwxr-xr-x 1 root root 28485 Dec 13 00:47 bcm2710-rpi-zero-2-w.dtb
-rwxr-xr-x 1 root root 49877 Dec 13 00:47 bcm2711-rpi-400.dtb
-rwxr-xr-x 1 root root 49833 Dec 13 00:47 bcm2711-rpi-4-b.dtb
-rwxr-xr-x 1 root root 50555 Dec 13 00:47 bcm2711-rpi-cm4.dtb
-rwxr-xr-x 1 root root 52460 Dec 13 00:47 bootcode.bin
-rwxr-xr-x 1 root root 121 Jan 1 1980 cmdline.txt
-rwxr-xr-x 1 root root 1852 Dec 15 01:23 config.txt
-rwxr-xr-x 1 root root 18693 Dec 13 00:47 COPYING.linux
-rwxr-xr-x 1 root root 3148 Dec 13 00:47 fixup4cd.dat
-rwxr-xr-x 1 root root 5352 Dec 13 00:47 fixup4.dat
-rwxr-xr-x 1 root root 8352 Dec 13 00:47 fixup4db.dat
-rwxr-xr-x 1 root root 8354 Dec 13 00:47 fixup4x.dat
-rwxr-xr-x 1 root root 3148 Dec 13 00:47 fixup_cd.dat
-rwxr-xr-x 1 root root 7219 Dec 13 00:47 fixup.dat
-rwxr-xr-x 1 root root 10199 Dec 13 00:47 fixup_db.dat
-rwxr-xr-x 1 root root 10197 Dec 13 00:47 fixup_x.dat
-rwxr-xr-x 1 root root 145 Dec 2 2020 issue.txt
-rwxr-xr-x 1 root root 6354280 Dec 13 00:47 kernel7.img
-rwxr-xr-x 1 root root 6780432 Dec 13 00:47 kernel7l.img
-rwxr-xr-x 1 root root 7906378 Dec 13 00:47 kernel8.img
-rwxr-xr-x 1 root root 6006360 Dec 13 00:47 kernel.img
-rwxr-xr-x 1 root root 1594 Dec 13 00:47 LICENCE.broadcom
drwxr-xr-x 2 root root 20992 Dec 13 00:47 overlays
-rwxr-xr-x 1 root root 799228 Dec 13 00:47 start4cd.elf
-rwxr-xr-x 1 root root 3736808 Dec 13 00:47 start4db.elf
-rwxr-xr-x 1 root root 2239680 Dec 13 00:47 start4.elf
-rwxr-xr-x 1 root root 2991688 Dec 13 00:47 start4x.elf
-rwxr-xr-x 1 root root 799228 Dec 13 00:47 start_cd.elf
-rwxr-xr-x 1 root root 4808680 Dec 13 00:47 start_db.elf
-rwxr-xr-x 1 root root 2963904 Dec 13 00:47 start.elf
-rwxr-xr-x 1 root root 3715400 Dec 13 00:47 start_x.elf
drwxr-xr-x 2 root root 512 Dec 26 2020 'System Vo

and ls -al /mnt/rootfsM2

root@raspberrypi:~# ls -al /mnt/rootfsM2

total 88

drwxr-xr-x 19 root root 4096 Aug 21 16:25 .
drwxr-xr-x 4 root root 4096 Dec 18 14:24 ..
lrwxrwxrwx 1 root root 7 Dec 2 2020 bin -> usr/bin
drwxr-xr-x 2 root root 4096 Dec 2 2020 boot
drwxr-xr-x 4 root root 4096 Dec 2 2020 dev
drwxr-xr-x 102 root root 4096 Dec 15 01:23 etc
drwxr-xr-x 2 root root 4096 Dec 15 2020 export
drwxr-xr-x 3 root root 4096 Dec 2 2020 home
lrwxrwxrwx 1 root root 7 Dec 2 2020 lib -> usr/lib
drwx------ 2 root root 16384 Dec 2 2020 lost+found
drwxr-xr-x 2 root root 4096 Dec 2 2020 media
drwxr-xr-x 2 root root 4096 Dec 2 2020 mnt
drwxr-xr-x 4 root root 4096 Dec 27 2020 opt
drwxr-xr-x 2 root root 4096 Sep 27 2020 proc
drwx------ 6 root root 4096 May 15 2021 root
drwxr-xr-x 4 root root 4096 Dec 2 2020 run
lrwxrwxrwx 1 root root 8 Dec 2 2020 sbin -> usr/sbin
drwxr-xr-x 10 root root 4096 May 29 2021 srv
drwxr-xr-x 2 root root 4096 Sep 27 2020 sys
drwxrwxrwt 8 root root 4096 Dec 27 2020 tmp
drwxr-xr-x 11 root root 4096 Aug 21 21:53 usr
drwxr-xr-x 13 root root 4096 Dec 27 2020 var
root@raspberrypi:~#

Running fsck did show results

fsck /dev/sda1

root@raspberrypi:~# fsck /dev/sda1

fsck from util-linux 2.36.1
fsck.fat 4.2 (2021-01-31)

There are differences between boot sector and its backup.
This is mostly harmless. Differences: (offset:original/backup)

65:01/00

1) Copy original to backup
2) Copy backup to original
3) No action
[123?q]? 3

Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
1) Remove dirty bit
2) No action
[12?q]? 2
/dev/sda1: 292 files, 98568/516190 clusters

fsck /dev/sda2 looks good

root@raspberrypi:~# fsck /dev/sda2

fsck from util-linux 2.36.1
e2fsck 1.46.2 (28-Feb-2021)
rootfs: clean, 538256/15015168 files, 9756010/60983086 blocks
root@raspberrypi:~#

For fsck /dev/sda1 - should I copy the original to backup and remove dirty bit?

Thanks again,

SM

Quote from Soma

All is OK on the drive side.

Now you need to check for issues on the filesystem of the M.2

Shutdown again the Pi and leave ONLY the new SDcard in it.

Boot up the Pi and run sudo raspi-config to set up the bootloader to the latest and to confirm it's booting first from USB.

Display Spoiler

(Since this is a fresh install of Pi, the bootloader is (probably) booting SDcard first:

Goto6 -> A7 -> E1 and, when you finish, it will reboot to start using the latest version of the Bootloader (if it's not installed).

    

After the reboot, run again sudo raspi-config

Goto 6 -> A6 -> B2 to set the bootloader to start 1st from USB.

 

You can now, test installing the argon script (on the SDcard without anything else) or just continue with the rest first.

With the Bootloader taken care, while the Pi is running, plug again the M.2 drive and run:

Display Spoiler

sudo su - # <- to become "root" to save some keystrokes

fdisk -l /dev/sda # <- confirm it's the M.2 drive

df -h | grep sda # <- re-confirm it shows 2x Partitions (sda1 is the boot, sda2 is the rootfs on the M.2 drive although unmounted)

Post the output of fsck -N /dev/sda # <- this will check the FS on the drive without fixing nothing.

If there's error's, run fsck -y /dev/sda

Run again fsck -N /dev/sda

See if there's no error's showing.

After these steps, Power down the Pi and remove the SDcard (keep it safe for now).

Reboot the Pi with the M.2 drive only and see if the boot goes normal.

Display More

I finished with the bootloader steps and moved on to the 2nd part. I skipped the argon script for now

fdisk -l /dev/sda - showed the M.2 Drive

df -h | grep sda - nothing happened with this command - it just went to a new line

fsck -N /dev/sda - outputted this

root@raspberrypi:/home/pi# fsck -N /dev/sda

fsck from util-linux 2.36.1

[/usr/sbin/fsck.ext2 (1) -- /dev/sda] fsck.ext2 /dev/sda

That's all

I have a feeling it's unable to open/access sda?

I tried rebooting the Pi with the M.2 drive only and unfortunately, it didn't boot

I'll plug the sd card back in for now

Thanks,

SM

Quote from Soma

Your bootloader looks OK.

I'm assuming you only have the M.2 as boot && root. (NO SDcard on it)

You can take out the M.2 from the argon and plug it to a PC.

Your boot partition will be seen on the Explorer.

See if the cmdline.txt && config.txt are readable and don't show wierd artifacts/symbols.

Then, flash a fresh RaspiOS Lite to a SDcard and add an empty ssh file to the boot partition.

Boot the Pi with only the SDcard on it.

After it boots normally, while it's running, plug in the M.2 to the Pi (with that USB link that comes with the Argon)

post the output of

fdisk -l /dev/mmcblk0

fdisk -l /dev/sda

Display More

Thank you for the response,

I checked both cmdline.txt &config.txt - all readable text - nothing looked out of the ordinary.

I was able to launch a fresh image of RaspiOS Lite and was able to SSH to it. The rules out any issue with the pi, phew.

The output of fdisk -l /dev/mmcblk0 is

Disk /dev/mmcblk0: 59.48 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: 0x815c7a01

Device Boot Start End Sectors Size Id Type

/dev/mmcblk0p1 8192 532479 524288 256M c W95 FAT32 (LBA)
/dev/mmcblk0p2 532480 124735487 124203008 59.2G 83 Linux

and the output of fdisk -l /dev/sda is

pi@raspberrypi:~ $ sudo fdisk -l /dev/sda
Disk /dev/sda: 232.89 GiB, 250059350016 bytes, 488397168 sectors
Disk model: Forty
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 33553920 bytes
Disklabel type: dos
Disk identifier: 0x4b9bc9e0

Device     Boot  Start       End   Sectors   Size Id Type
/dev/sda1         8192    532479    524288   256M  c W95 FAT32 (LBA)
/dev/sda2       532480 488397167 487864688 232.6G 83 Linux

Thank you again for helping - It seems like it does detect the drive? The 232.6G is the M.2 Drive

Hello all,

I think I shot myself in the foot - not sure how to recover from this.

I'm using a RPI 4 - ARGON case - booting off an M.2 drive - installed the latest OMV updates.

Made the rookie mistake of not backing up the server - the last backup is months old - worst case I could give that a shot.

The only major thing I could think of is I installed this script

 curl https://download.argon40.com/argon1.sh | bash 

Just so I can control the in case fan - I also played around with docker and installed OMV updates.

I went to reboot the server and nothing - green light turns on for a few moments then shuts off.

Not sure what to do here - is there any way to recover or do I have to start from scratch

I did have some duplicati backups but I think that was just for docker?

Any advice is appreciated

UPDATE;

Was able to take a screenshot of the boot up

https://imgur.com/a/IHUmoXp

Thanks,

SM

Quote from ryecoaaron

I don't see anything in that list that is generating high load. Was it high when you got the output of ps? I can understand why an RPi would be busy running plex, adguard, s6, duplicati, and qbittorrent though.

I'll see If I can get it the load to a 11 again - then run the command - If I leave it on for at least a day the numbers will slowly keep creeping up

Quote from ryecoaaron

What is the output of ps aux while the load is high?

I'm getting this:

Output

Quote from ryecoaaron

Is the RPi booting from sd or m2? I would look at the i/o wait in top as well. If the OS media is having issues and you have docker on it, I could see the load being high.

Yes the Rpi is being booted from M2 and I have docker installed. I looked at the i/o wait and did go to 0.1 then back to 0 then 0.1 again later. The issue is strange - the load just slowly keeps going up and up and at one point I lost communication with the web server.

I uninstalled docker too to see maybe it was docker acting but the load was still high

Hello all,

I am running OMV 5 5.6.13.-1 on a Raspberry pi 4 using the Argon One M.2 case.

The server has been working well for quite some time. I had around 30+ day uptime and

I decied to do some updates and reset the server.

After the reboot, I running into a strange issue where my CPU load average keeps going up and constantly. It went to around 11 at one point

I unplugged my NAS storage and the issue still persists. I ran htop as well and can't find anything too out of the ordinary.

Update: Using top

I did notice php-fpm: pool openmediavault-webgui will use 45% for a few moments drop then repeat again

I noticed as well rebooting OMV will cause the Pi to crash - I will have to manually remove and put the power back in

Pictures

Load average

Htop

Any ideas what the issue could be?

Thank you,

Dan

Quote from TechnoDadLife

I was just wondering what you did differently, because both ways do the exact same thing. I even referenced that post. Did you just happen to wait longer after starting up? All it does is add in a delay.

The difference I can think of is I edited /lib/systemd/system/docker.service with nano changed the delay to 300s and also added

ExecStartPre=/bin/sleep 30

Thank you so so much man. Worked liked a charm. This issue was driving me mad.

Cheers, Dan

Thank you all for your replies, Davidh2k link did the trick. Huge thanks, that issues was driving me crazy.

Cheers!

Dan

Thank you guys for the replies, I tried the fix in techno dads video but no dice. I will try using the code above with absolute paths.

Thanks for the reply, Please bear with me, I'm new to this.

I would be using my absolute path or the shared folder name instead of "sharedfolders" correct? " DATA"

I will try that.