Beiträge von monitor

Today my raid drives went off line and as a Raid newb, I am lost on what I can do to recover.

Meanwhile, I have bought a set of new drives to replace all 3 over time, but right now I can't even get anything at all.

I can open a putty terminal to the system.

I also have access via a direct terminal, but I have no idea regarding the process of recovering my data.

There are some backups, and many projects which are stored on my Raid system are cloned to several PC on my LAN.

At worst I will lose much of the git history, but I would prefer to restore the full system - with some help from the people on this forum, I hope.

I have looked at several threads here and on other places which try to talk users through recovery, but each case seems subtly different and I don't feel brave enough to go it alone..

Another option, but as a noob, and not really wanting to "fix things that ain't broke", I need to make sure I can schedule enough time away from my usual work to 'upgrade' to something new and untried (for myself) such as even a new way to make backups.

Will certainly give it a shot on the next open 'slot'

Thank you.

BernH: The fact that I did no stop OMV, would probably explain the issues I was having.

Thank you for pointing that out.

I am running 6.?? but IIRC, my previous look at the backup plugin left me with the wrong impression. Will have to reread the plugin docs again.

Zitat von chente

Search the forum and the omv-extras wiki for updated procedures. If you can't find information or have questions, ask your questions.

Don't follow outdated videos. The author will no longer support you, try it and you will see the result.

That is what I had intended /wanted to do with my question.

Much of what I had found regarding 'backups' (and the backup plugin) only seems to back backup parts.

Being a relative noob to OMV, I figured, that procedure ought to have stood the test of time since it only uses 'standard' linux commands AFAIK

After following the Youtube video from TechnoDadLife (

I realize the video is 2 years old, but the comments do not mention any such issues - or, at least I did not find any

My OMV version - latest 6.?? (It'd sure be nice to have the exact version shown in the 'About' page)

My OS drive is a SSD, the backup drive is a 500GB laptop drive (a previously used drive)

After running the backup command, when trying to boot from the newly backed up drive, I ran into issues where the boot messages from the PC terminal advised me that I would have to manually run fsck?? on /dev/sda1, which I did.

It advised me that somethings needed fixing, I agree to a couple of the requests, but gave up eventually and tried to boot from the disk anyhow - needless to say without luck, on the first try.

After checking the drive with GSmartControl disk checker and getting a clean bill of health, I copied the OS once more and tried to boot again.

When I tried to boot from the new 'backup', I got the same issues as before, tried to clean a couple of the remedies offered by fschk and eventually gave up.

Just now, as I tried to reproduce the issues and error messages for this question, lo and behold, the PC booted properly, without any hiccups and is now running OMV as far as I can tell.

Now, my original questions are slightly modified, but still much the same:

What is going on?

Is the proposed way the only and best way?

What, if any thing can I do to make sure this issue does not come back, i.e. do I really have a usable back up drive?

and loads more questions, related to all of this

Thank you for your help

By now I have been able to upgrade to OMV 6, though it was a bit of a struggle with some real bumps in the road.

From that experience alone, I would dearly love to have some document which spells out the important details of an existing configuration, preferably on a piece of paper. In the best case, one would not have to switch back and forth between the original and new installation to review specifics. In the worst case, if the original drive gets mangled or overwritten, it is hell to try and find where on the net one might be lucky enough to find pertinent information.

For now, I think I have managed to get my git repos back on line and am gradually finding & figuring out equivalent apps and workflow under Mint to do the necessary things.

Since I never really have used Linux/Mint in a networked environment before, there are a lot of uncertainties, but I think I have finally accepted that SMB/CIFS is the simplest (& best?) way to get what I need while I wean myself off Windows.

If you think gitea - or some other method - would be a better option, I would be interested, but for now, it seems, I can get by with what I have.

In any case, thank you for your patience.

Thank you for confirming the upgrade question.

Because I have no clue as to the protocol or path I could/should use, I have tried several GUI front ends.

Under Windows, I always use TortoiseGit

Under linux/Mint I have tried just about every GUI available via the Software manager.

Command line git is installed as a prerequisite, but of no use to me until I sort out the URL to be used.

Currently, my workflow as a result of trial and error:

From the Network directory on the desk top, I open up my NAS git SMB/CIFS share and select my git directory.

Then, I have found that I can use Gittyup GUI front end to clone my project from the NAS using the available dialogs

After launching Gittyup:

Clone repository

in the Clone Repo dialog, click on the '....' button

in the 'Choose directory' dialog left hand pane,click on the '+' -> Other locations, which shows the options:

'On this computer'

Networks - git on mynas.local

This highlights/selects mynas.local and then I can click on the 'Select' button which takes me back to the 'Clone directory' dialog with the URL field filled in as:

/run/user/1000/doc/2916a198/smb-share:server=mynas.local,share=git

With that setup I can then select where I want the 'clone' to end up.

To commit to my local repo, I have been using git gui.

But nothing I have tried allows my to push back to my NAS repo and that is where I am stuck

On a fresh install of 6, all the config changes stay on the new boot drive, correct??

Then going back only involves swapping the old & new boot drives?

The mounting is done behind the scenes it seems.

The x:\repos\my-project.git is what has me stumped.

AFAIK, my git repos are on the RAID drive in /git/test.git

My thoughts on upgrading would be to do a clean install of 6 to a small SSD and then swap it out for my current boot drive.

Can I expect that to work? If so, I would try to upgrade over the weekend.

As for pushing to the NAS git repo, none of the methods I have tried work for me, even if I have the client mounted and ready to clone.

Thank you for the offer to help me set up gitea.

As I am the only one using the git repos, I am very happy to accept your offer.

First of all though, a question: I am running OMV 5 right now. I did try to upgrade to 6 some time ago but did not have any luck.

Would it be best to try an upgrade first or how much trouble would it be to upgrade later with the gitea functionality installed already?

The cloning was taken care of by git GUIs such as Gittyup, though I did have to jump through some hoops to connect to the NAS SMB/CIFS directory before invoking the 'Clone directory' dialog so that it would show in the 'Choose Directory' dialog.

This works for cloning, but not for pushing any changes.

While the NFS share shows under 'Networks', I have not been able to connect to it via that icon.

One of the problems I have is that I cannot figure out the path to the directory on my NAS.

I have tried to compose a path for both git/https/ssh access, but even though I know the server 'hostname, -> mynas.local, I think, none of the path strings I have tried seem to work.

As all of it fails, I can't be sure which part of the URL is wrong, or even whether the necessary services are enabled/installed on the NAS.

When I jump through the hoops and connect to the git repo on NAS, Gittyup ends up using the URL

/run/user/1000/doc/829de6f8/test.git

However, that same URL does not work for a push.

As I can use these git repos from Windows (clone & push) without issues, I have assumed that it is not a permissions problem.

Browser under Mint is Google Chrome Version 102.0.5005.61 (Official Build) unknown (64-bit)

AFAIK, there was no zooming; I very rarely use that feature.

And FWIW, when I came back to the forum just now, the button was visible

I'll close this thread for now

Not sure how that would translate to a directory which shows up on my desktop as "git on mynas.local"

Existing system

OMV 5 running RAID 5 on a separate PC

OMV is setup with a SMB-CIFS share to allow the Win PCs to access the local git master - all works well

The git access it managed by TortoiseGit on the Win PCs

It is using a shared folder /git on the RAID system

Under OMV, I have also enabled NFS

Now, to try and wean myself off Win, I want to run a Linux/Mint PC on the same LAN and access that same git master repository.

I have tried several of the Linux git GUIs and have managed to clone several projects from the OMV git repo, but no matter which git GUI I have tried, I have been unable to push updated data back to the master.

The main issue I seem to be having is specifying the correct git protocol, but I am totally lost as to how to compose that with my current setup.

Although, I am not too conversant with the command git line, I am prepared to learn more about that as well, once I sort out how to specify the correct protocol and am sure the OMV box is setup correctly for this.

Any help, pointers or comments will be most appreciated

Just now, I was trying to post to this forum from my dual-boot PC under Mint 20..x

I was able to sign in, but there seems to be no way to start a new topic.

When I signed in from another Windows PC on my LAN, I was able to find the button to start a new thread - this one.

FWIW, I was able to see the buttons to mark all threads as read and also was able to modify the forum categories I wanted to see.

These settings propagated to my Mint box.

Quite likely this might be related to cookies or other permission differences, but I am not sure which ones to check nor how to get to these.

TIA

Thank you for the pointer.

Still, and in any case, it is easier to ignore things we don't recognize or need, than to find things which were never there

I have now swapped out the Samsung SSD for a WD drive and re-installed OMV5.6 according to the YouTube Video and from what I can tell thus far, things are working as expected.

The part in the video about how to handle SMB etc. is most important to me since I very rarely getting into any of this installation - really only when I need to update or upgrade.

Right now, the WD SSD has been running without any of the errors that popped up with the Samsung SSD, though, AFAICT, it is working perfectly in a PC, formatted as a NTFS drive

I have given OMV 6 a try, with the WD SSD, but the installation seem to run into issues with identifying the proper drive to install the new OS to and my attempts at backtracking failed.

Unfortunately, I did not keep very good and detailed records for that so all I can now say is that I got stumped.

Another very important WIBNI I which I wish I had or that it was available is a way to list all of the important configuration data to a text file which can be saved to somewhere on a disk and later on printed, if necessary, as a guide to what the many option and setting were in the 'working' system.

As I still had my OMV 4 HD, I was able to boot back to the 'working ' system and try to get that information via screen shots, but ran into several issues even with that.

Not knowing just what would need, where to find it, meant a good number of restarts and drive swapping

Some of the screenshot are nearly useless unless one realizes that some of the fields will be very faint, because the screen strings are greyed

Yes it is a Samsung 870 EVO drive

OK, I think I finally been able to figure out how to get at the log and I 'll attach a file with copy the last set of lines, which look like they start at about the time of the last restart after I made sure the cables were seated properly

Some of the lines look identical to what I see in the terminal window, along with a whole lot more, though it really does not make any sense to me.

HTH