Posts by msacco

    All of these talk about cache, but it happens even on a guest profile(which doesn't have anything stored), as well as incognito, mobile phone and different browsers.

    Hey, my omv dashboard started to crash on the dashboard page, I load the dashboard page, then when it fully loads after like 5-10 seconds the page crashes


    I think it started happening after the recent version update(7.7.0-2 (Sandworm)).

    Tried in incognito, tried on a guest browser, same issue. Even on mobile..

    Anyone knows anything about it?


    Thanks.

    Sorry, I haven't read the entire thread. If what you want is to update the OMV version you can do it with the omv-release-upgrade command. omv-regen is not going to help you with that.

    I guess I was confusing 2 different things sorry.

    I had my system died, and didn't make a full dd backup, only partial dd backup. I managed to get my system up and running through this, but I think it might be better to try and get a fresh system running as things didn't work 'out of the box', so ryecoaaron suggested omv-regen to backup my system and transfer it to a new image.


    I thought that if I'm already doing that, might as well upgrade to OMV7/Bookworm.

    So I think I'll try to install OMV6, restore the backup with omv-regen and then try to upgrade to OMV7 if that would play nicely.


    Thanks.

    In this case you cannot do the regeneration. omv-regen currently depends on the versions of OMV-related packages available in the repositories being the same as the ones on the original system. In this case there has been an OMV update, therefore you cannot regenerate.


    For it to work you must return to the original system, update it and make a new backup. Then you can regenerate with that new backup.

    Got it, wouldn't it be easier to install Bullseye and OMV6 and then try to update it to Bookworm and OMV7?

    Is it even possible?


    Thanks.

    You should be able to see the log in /var/log/omv-regen.log

    I was only able to see the full logs through nano, I tried cat and a few others but was not able to see this log wit that, not sure why.

    Anyone got some useful logs I guess:

    Code
    Due to a recent update or because the original system was not updated when
    the backup was made, the version of openmediavault installed does not
    match the version that the original system had.
    The regeneration cannot continue under these conditions because the system
    it could end up corrupt.
    You must make a new backup of the original updated system and start the
    rebuild process again.

    The original backup was created on OMV6 and Bullseye lite, the new system is on Bookworm and OMV7.

    I think I saw that it can work with OMV6 and OMV7, but not sure if maybe it can't overcome Bullseye to Bookworm?


    What should I try in this case?


    Thanks.

    chente will have to help with that.

    Thanks, hope he might be able to help.

    I actually do see that a new folder has been created inside the /ORBackup folder:


    It looks like it is some of the backup files, not sure if I should just manually copy it to the root folder or something, I'd expect the tool to do it automatically, hope chente could reply and shed some light :)

    I couldn't do that myself. There would be unknown cruft that could cause a problem down the road even if it is working now.


    I would stop using rsync. That really was just an idea out of desparation. I have restored dd backups many, many times and haven't seen the issues you are having. You could take your system now and use omv-regen to backup the "new" system then restore it. Worst case, I would just reinstall and setup things from scratch.

    So technically I got almost everything to work through the dd backup, omv works, docker works, don't have any actual issues really, but I wanted to give omv-regen a try.

    I've created a backup using omv-regen, installed a fresh omv7 installation on Bookworm raspbian lite, when I tried to use omv-regen regenera to restore it, it seemed as if it runs properly, I got no errors or anything, but nothing actually happened it seems.


    Are there any logs that can show if the restore actually worked?


    Worst case I'll continue with what I had working, but would be nice to start fresh with the settings backup and move on to omv7 as well.

    Thanks.

    it could've been on the bad sector (or whatever) that caused the dd to fail.

    Well tried with the --delete argument, but it doesn't work unfortunately, getting some weird kernel panic errors so I don't expect q small change for it to be fixed.



    Guess I'll continue without the --delete argument as I did manage to boot the system and have it mostly running properly.


    If you have some other ideas that might worth a shot feel free to share.

    Meanwhile I guess I'll try to continue with the mostly working OS and see if I can get it sorted out.


    Thanks.

    Many, many files could potential be left from the standard install that might cause configuration issues. --delete will delete anything on the destination that doesn't exist in the backup.

    Hard to say. Try it. Since you have a backup, you can always try it again.

    Alright, will try it now and see.

    Any idea about the potentially corrupted file?


    38861-pasted-from-clipboard-png


    This is the only file I've seen, but no idea if possibly there are more such files, though most things do work so I guess the majority is fine.

    Not sure if there is a way to test how many these files there are.

    I meant restoring the dd backup whether that is by using dd or mounting/rsync.

    The rsync command should've had the --delete flag.

    I tried to understand what the --delete flag does, but not sure what would be the actual difference in this case, would you mind explaining?


    Also, I managed to get the system to work almost completely by using the latest Bullseye image as macon suggested, then just had to modify fstab to match the updated partitions which worked and booted properly.
    Omv now runs fine, as well as all my shares and most of my services, but my main issue is with docker that isn't running, and reinstalling doesn't seem to help.


    I wonder if somehow my backup what partially corrupted somehow. For example one of my containers had this for the config.v2.json:


    Others seemed ok besides this single file.

    It seems like it could be somehow related to crowdsec-firewall-bouncer.service, tho not really sure why it would be related.


    Do you think trying again with the --delete flag should change or improve anything?


    Thanks.

    If your backup is from OMV6, you should use RaspianOS light Bullseye for the initial installation. Especially when using the rsync path.

    Thanks, I'll try that :)

    I did manage to get some progress and actually got it to work, but I'm getting stuff like this:

    Code
    apt
    apt: /lib/aarch64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /lib/aarch64-linux-gnu/libstdc++.so.6)

    Likely due to the system itself or something like that, so I'll give this a go.

    It is a pain in the ass. That is why it so hard to document. I really don't like even trying to walk someone through it. That is why we tell people to reinstall and then just sync the os dd.

    By 'sync the os dd', do you mean the rsync part? Or some other sync through omv webui itself? Or just manually copying files from the mounted dd?

    Also not sure if different raspbian versions could make a difference with the backup that I have which is a few months old.


    Tbh I think I'm getting somewhat close, most of the issues were things like nuances or some partitions that I needed to play with.

    I always started with a clean raspbian lite, should I try to start with a clean omv setup? The backup is of omv6, and latest would be omv7 it seems, so not entirely sure about that as well.


    Thanks.

    Ok so I managed to get 'some' progress, the rsync command should be like this:
    rsync -avr --progress /mnt/backup/ /path/to/mounted/sdd2

    with the '/' at the end otherwise it would just copy the folder itself and not the content inside the folder.


    I did manage to copy everything to the root partition, but it seems like that screwed things up and didn't work.


    I then tried to rsync _boot.dd but that didn't help either.

    I guess technically by having a backup of both root and boot I should be able to restore it, but just not sure how to do it properly, maybe some things are different and needs to be adjusted manually?


    Thanks.

    Thanks! rsync seems to be running now.
    Sadly I never expected the system to die instantly like that without any symptoms etc, so my backups were not fully tested properly, and weren't actually done properly as I didn't fully set it up properly.

    Not sure how old my current 'backup' is, but we learn from mistakes, so I'll surely know how to better set up my backups and test them.


    Kinda ironic that my main setup is a NAS for backup with 3-2-1, but I didn't properly backup the system itself running it.
    Oh well :)


    Do I also need to rsync boot.dd to the boot partition?


    Edit - rsync finished, got this output

    Code
    sent 17,926,736,804 bytes  received 3,556,784 bytes  16,733,825.09 bytes/sec
    total size is 17,909,399,466  speedup is 1.00
    rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1338) [sender=3.2.7]

    Looks like many things weren't moved properly, not sure why, any way to access some logs?

    It is best to make it the exact same size. You don't need to extract the .gz file. The command I have you will do that. I don't understand why it isn't working but if you have the .gz file extracted, you could mount it and rsync the files over the fresh install. Then the partition size won't matter.

    This was in .fdisk file, I tried to match the partition sizes

    Quote

    sdd 8:48 1 59.7G 0 disk

    ├─sdd1 8:49 1 252M 0 part

    └─sdd2 8:50 1 29.5G 0 part

    But that still didn't work, same error

    Quote

    gunzip -c /mnt/sdc3/omvbackup/backup-omv-2024-02-24_05-46-17.dd.gz | sudo dd of=/dev/sdd2 bs=512

    dd: error writing '/dev/sdd2': No space left on device

    1+0 records in

    0+0 records out

    0 bytes copied, 0.000506236 s, 0.0 kB/s

    Would you mind giving some instructions on how to mount the dd file and what rsync command to use?
    Just trying to make sure I use the right arguments for each command as things don't work out for me anyhow, better eliminate possible mistakes.


    Thanks.

    Was your partition that was backed up on 2.1G? That is too small in my opinion for OMV but the partition has to be the same size as the backup.


    You have to extract the .gz file and can't write directly to the system. You also can't write it to a live system.


    gunzip -c /mnt/sdc3/omvbackup/backup-omv-2024-02-24_05-46-17.dd.gz | sudo dd of=/dev/sdd2 bs=512

    That was a clean raspbian lite installation, I think the original system was 64gb card with 32gb root partition size.

    I tried to increase the root partition size to 64gb~ but still had the same issue, does the size needs to be exact?..


    I did extract the .gz file, and I didn't write it directly, maybe I didn't explain it properly.

    I installed on an sd card a clean raspbian lite OS(64gb card), then put that sd card with a usb adapter on another rpi4 system and mounted the backup folder too, so the sd card I intended to write into wasn't live.


    Quote

    sdd 8:48 1 59.7G 0 disk

    ├─sdd1 8:49 1 512M 0 part

    └─sdd2 8:50 1 59.2G 0 part

    /dev/sdd is not mounted.


    Have a look at the .blkid file


    You have to uncompress the file first and write it using dd.


    Yeah I tried with the file uncompressed too, but still the same error.

    Quote

    /dev/mmcblk0p1: LABEL_FATBOOT="bootfs" LABEL="bootfs" UUID="37CA-39EC" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="a34a2be1-01"

    /dev/mmcblk0p2: LABEL="rootfs" UUID="a4af13c6-d165-4cbd-a9f6-c961fef8255d" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="a34a2be1-02"

    This is the content of .blkid file.



    Thank you both for trying to help :)

    Unfortunately you did not choose the dd-full option.

    Best way forward is to do a fresh install (without configuration) and then write the dd.gz file over the root partition.

    F :(

    I think I somewhat tried that but it didn't work, maybe I didn't do it properly.

    Does fresh install = just clean raspbian or clean omv installation?

    I have installed a clean raspbian lite system, then put the sd card on my other rpi(through usb), and tried to run this:

    Quote

    sudo dd if=/mnt/sdc3/omvbackup/backup-omv-2024-02-24_05-46-17.dd.gz of=/dev/sdd2 bs=512

    dd: error writing '/dev/sdd2': No space left on device

    1+0 records in

    0+0 records out

    0 bytes copied, 0.00530771 s, 0.0 kB/s

    sdd 8:48 1 59.7G 0 disk

    ├─sdd1 8:49 1 512M 0 part

    └─sdd2 8:50 1 2.1G 0 part


    /dev/sdd1 should be boot partition

    /dev/sdd2 should be root partition

    (I guess...)


    I tried to increase the partition size of sdd2 to 100% or remaining storage, but still the same thing.

    Any ideas?


    Thanks.

    Hey, I need to perform a backup restore because my sd card died.

    I tried to follow the restore steps, but I don't have some of the files listed there.

    Here are all the files that I have:


    Is it possible to perform the restore with these?

    Thanks.