be carefull to NOT TYPE
rm -r ..
It might tell you its in use and not allow it but otherwise you can get in real data deleted trouble!
If you want to get it working without any reinstallation you could do the following:
get yourself a live medium and boot it
mount the medium where your installation is, if you have a seperate /boot partition mount it inside the other mount
chroot into the mounted system
if it is not installed run apt-get install grub2
look at your /etc/fstab and make sure there is nothing like /dev/sdX but a disk-by-uuid
If not, change to corresponding id
reboot and you should be fine
It could be enough to change the fstab without chroot and all the stuff.
The problem is, the system creates the alphabetical device names in the order he got the devices. If for example the install medium was listed first, it will be assigned /dev/sda and what ever was assigned /dev/sdb during this boot will be /dev/sda at the next boot without the thumbdrive. /dev/sdl tells me, there were a hell lot of drives connected during installation, which is the reason you should not have used the installation iso. if you use unique disk ids you dont run into this issue, as they always stay the same, whatevery other devices you connect. I know they are somehow bad to type, but you should use them whereever it is possible for this exact reason.
will set temporary english output in the console you are logged in.
You may want to check if the firmware package is installed. If I recall correctly, the free part should be fine in this case:
apt-get install firmware-linux-free
You may add the nonfree repos and also install firmware-linux-nonfree, but amdgpu should be working with the free one.
I dont know why you should install any graphical environment where amdgpu is necessary on a nas, but if you do, you might want to install
apt-get install xserver-xorg-video-amdgpu
ECC is not available as you use non ecc udimm memory.
Well, something went wrong with the key exchange.
The easiest way I know is to simply use
This will allow to connect to your pi without getting asked for the password, until keys change.
If it is only about key verification just log in via ssh once and accept the key so it gets written into know_hosts.
Also you should use lower case user names only, upercase may cause unexpected behaviour.
That would probably be my way to go. Although I think, it is even easier to just add the new disk as a new one and rsync, its not that many steps to recreate shares and stuff.
I got a lot of meatings out of office today, so I will be able to create the diff in the evening.
I could use a custom kernel in the OMV installtion if that would solve the issue, but I am not sure if the answer is within the kernel config.
This makes no sense to me how it could be that different.
I absolutly agree and surely hope it is just a small config I somehow missed.
That is exactly what I expected.
You can create it via
mkdir -p /var/log/nginx
It will be owned by root than, so you need to change the owner to the nginx user, which I am not sure how it is named right now. Maybe something like www-data or nginx. If it would be www-data you can change the owner like this, just replace www-data if the user is named differently
chown -R www-data:www-data /var/log/nginx
To find out how it is named you can look into /etc/group or the nginx systemd file.
The problem is, that the nginx user cannot the create the /var/log/nginx folder as it propably has no writing permission in /var/log. If he cannot create the folder he also cant create the logfile, that's at least on of the reasons he does not start.
edit: corrected chmod to chown for future readers
Tested all three, the differences in write speed are within the statistical error.
Proxmox Kernel is indeed faster, but still very very slow. 87mb/s instead of 82mb/s.
I am absolutly helpless at the moment. Maybe I will need to trace dd and have a look for some strange bottle necks.Code
Ill give it a try and post the result allthough I am not sure about the zol kernel module dependency here and if it will be broken.
I agree that it is supprising to see that different behaviour between arch and debian here and I agree, that compilation should not be cause this.
There are no firmware updates for those drives available.
It is totally wierd and only this particular combination of ssd, system and os is showing this. If I change anything of the three, its working just as expected.
Its also not about mount options as I use dd on the device.
Well, the very same setup is fast using another os, as i tested running arch with a quite close kernel. There are others having this issue using samsung ssds and debian.
Also every other ssd i place in the very same spots are fast.
edit: no caching in controller active, just checked
Check owner and rights of /var/log/nginx
Maybe you removed the nginx folder and it cannot recreate it due to no writing permissions in /var/log?
You might start with just commenting the disk in /etc/fstab and boot. To access your data than mount it correctly by hand after you booted and change your fstab accordingly. Unless you did not do any big mistakes your data are still there.
I got an issue utilizing a set of Samsung PM871 SSDs in Openmediavault. The system is a a dual Xeon 2680v2 build with 8*16gb ram, using two Broadcom 2308 SAS controllers in jbod mode and two supermicro BPN-SAS2-826EL1 expander backplanes.
I am succesfully running 12 HGST Ultrastar 7k6000 in Raid z2 using zol, which gives better than expected performance.
However, I wanted to add a 6 disk mdadm raid0 with ssds for fast operations to do some quick multi node mpi work on them, where data consitency is less of a concern. As clients are all connected via FDR Infiniband I can make use of faster speeds, although the SAS Controller is becoming a bottleneck.
Unfortunally the SSDs are slower than the spinning disks in this particular system, which seems to be a software issue. Even with large block sizes the maximum write speeds are consistently at 82mb/s, while reads behaving as expected. Even with small block sizes the spinning disks are faster. I dont have this issue with a set of Samsung 850 pros i tested and not with some cheaper intenso ssds. Testing the drives in another system gives the expected write speeds and booting an arch linux from usb stick on the openmediavault system I get much faster writes too.
I am kind of clueless at the moment. Any idea what to do about that?
I am running Kernel 4.19.16-1, the arch stick I tested was also build with a 4.19.x Kernel. The system was set up utilizing a basic debian installation and the openmediavault repo.
Thank you in advance!