Just to be sure. If you create a file with touch /root/.test does this file survive a reboot?
How do i check, if the file has survived ?
Should there be an output after touch /root/.test ?
Just to be sure. If you create a file with touch /root/.test does this file survive a reboot?
How do i check, if the file has survived ?
Should there be an output after touch /root/.test ?
cat /etc/mdadm/mdadm.conf
# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file.
#
# by default, scan all partitions (/proc/partitions) for MD superblocks.
# alternatively, specify devices to scan, using wildcards if desired.
# Note, if no DEVICE line is present, then "DEVICE partitions" is assumed.
# To avoid the auto-assembly of RAID devices a pattern that CAN'T match is
# used if no RAID devices are configured.
DEVICE partitions
# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes
# automatically tag new arrays as belonging to the local system
HOMEHOST <system>
# definitions of existing MD arrays
INACTIVE-ARRAY /dev/md0 metadata=1.2 name=openmediavault:SimonsNAS UUID=430dadae:5f1c40c9:c3a5a8d5:15749f6c
# instruct the monitoring daemon where to send mail alerts
MAILADDR xxx_xxx@xxx.de
Alles anzeigen
Seemed to work nonetheless!
mdadm --detail /dev/md127
root@openmediavault:~# mdadm --detail /dev/md127
/dev/md127:
Version : 1.2
Creation Time : Mon Oct 8 21:07:22 2018
Raid Level : raid5
Array Size : 29298917376 (27941.63 GiB 30002.09 GB)
Used Dev Size : 9766305792 (9313.88 GiB 10000.70 GB)
Raid Devices : 4
Total Devices : 3
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Mon Mar 4 17:27:49 2019
State : active, degraded
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 512K
Name : openmediavault:SimonsNAS (local to host openmediavault)
UUID : 430dadae:5f1c40c9:c3a5a8d5:15749f6c
Events : 49241
Number Major Minor RaidDevice State
0 8 16 0 active sync /dev/sdb
1 8 32 1 active sync /dev/sdc
2 8 48 2 active sync /dev/sdd
- 0 0 3 removed
Alles anzeigen
Seemed to work nonetheless!
Ok try this again
mdadm: Unrecognised md component device - /dev/sda
that's saying it's not part of the array nor does it have a signature, so why does mdadm --detail show raid devices = 4.
What's the output of wipefs -n /dev/sda
I might have found the mistake !?
It says sda1 in blkid
/dev/sdb: UUID="430dadae-5f1c-40c9-c3a5-a8d515749f6c" UUID_SUB="945f5477-7c7f-97b5-cf6d-60701af938fb" LABEL="openmediavault:SimonsNAS" TYPE="linux_raid_member"
/dev/sdc: UUID="430dadae-5f1c-40c9-c3a5-a8d515749f6c" UUID_SUB="921d4d34-4ee0-dc0a-1ef0-6c014035953c" LABEL="openmediavault:SimonsNAS" TYPE="linux_raid_member"
/dev/md127: LABEL="Raid5" UUID="4ba52b0b-c03f-4854-964f-a18ca8bcebe4" TYPE="ext4"
/dev/sdd: UUID="430dadae-5f1c-40c9-c3a5-a8d515749f6c" UUID_SUB="177204c9-dfb9-f78c-725b-b9861fe857b6" LABEL="openmediavault:SimonsNAS" TYPE="linux_raid_member"
/dev/sde1: UUID="4bc0abc4-ac0f-4814-a4f4-e51213828b15" TYPE="ext4" PARTUUID="0286303e-01"
/dev/sde5: UUID="02284066-1848-411d-9a57-7d952e67d8a7" TYPE="swap" PARTUUID="0286303e-05"
/dev/sda1: PARTUUID="69221752-7171-483e-a28f-ae7d83f81caf"
I might have found the mistake !?
That would indicate that sda has a file system on it hence my previous request
That's why it's showing as sda1, wipe the drive in the GUI, then add it to the array mdadm /dev/md127 --add /dev/sda that should resolve it.
Ok, it's recovering now. I hope this resolves the issue.
I will let you know when its done.
Thank you for your time and patience.
I will let you know when its done.
Another two days time then
How do i check, if the file has survived ?
Should there be an output after touch /root/.test ?
touch /root/.test creates an empty file if not already existing and after a reboot you would check with ls -la /root/.test. We had a similar looking issue recently at a customer using a counterfeit USB pen drive to boot from where all writes went to nowhere. So as long as the server wasn't rebooted it seemed config changes were written to 'disk' but after a reboot everything was gone.
But this shouldn't apply to your M.2 SSD situation. BTW: I have the same Transcend SSD with 128 GB and when using extensively in an USB 'enclosure' like yours it badly overheats and throttles... (SMART temperature check revealed +80°C)
Everything seems to be normal, even after reboot.
@geaves Thank you again! Much appreciated
touch /root/.test creates an empty file if not already existing and after a reboot you would check with ls -la /root/.test. We had a similar looking issue recently at a customer using a counterfeit USB pen drive to boot from where all writes went to nowhere. So as long as the server wasn't rebooted it seemed config changes were written to 'disk' but after a reboot everything was gone.
But this shouldn't apply to your M.2 SSD situation. BTW: I have the same Transcend SSD with 128 GB and when using extensively in an USB 'enclosure' like yours it badly overheats and throttles... (SMART temperature check revealed +80°C)
"NAS-only-usage" should be fine temperature-wise (only little writing+reading) ?
Otherweise do you suggest another solution for my OS?
Output of ls -la /root/.test
Seems to be ok !?
"NAS-only-usage" should be fine temperature-wise (only little writing+reading) ?
I think so. You can check temperatures anytime via SMART (the SSD has been added to smartmontools' database in a more recent smartmontools version but since OMV updates the database unlike upstream Debian thermal readouts should be available). Personally we don't 'waste' SSDs as OS drive but use SD cards or USB3 thumb drives in USB2 ports (easy offline cloning but you should enable OMV's flashmemory plugin)
And yeah, your SSD is fine.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!