Try the kernel upgrade and see how it goes. Dmesg seems fine, the md array get's detected but not synced, just many hours later when you probably did the manual assembly
[SOLVED]RAID vanishes after reboot
-
- OMV 1.0
- gelöst
- Makosh
-
-
I am gonna run a backup first - given 5TB of content... see you next week!
-
odd.
I get this when I try to install the backport:
Updating...
Install backports 3.16 kernel and headers
Reading package lists...
Building dependency tree...
Reading state information...
linux-base is already the newest version.
initramfs-tools is already the newest version.
initramfs-tools set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 16 not upgraded.
Reading package lists...
Building dependency tree...
Reading state information...
E: Unable to locate package linux-image-3.16-0.bpo.2-amd64
E: Couldn't find any package by regex 'linux-image-3.16-0.bpo.2-amd64'
E: Unable to locate package linux-headers-3.16-0.bpo.2-amd64
E: Couldn't find any package by regex 'linux-headers-3.16-0.bpo.2-amd64' -
Debian changed the name of the backports kernel package. The next omv-extras version will have the fix. A few more tests and I will release it.
-
As 8n today soon tests or next week soon?
-
It is in the testing repo now
Make sure to refresh the page after installing new version. Lots of changes to the user interface. -
okay i am back.
News on the what we did here previously. It did not save the config. I rebooted and the same result - no raid is in the raid management section. I rebuilt it and it is resynching only 445min to go!
-
Kernel upgrade a no luck?
I just want to take a look at the disk geometry can you post fdisk -l
If nothing strange comes out I would recommend you to backup and wipe those disks and make the raid again, you can't live resyncing the array at every reboot
-
no luck having the backport kernel updated yet.
the raid is resynching right now. will the fdisk be a "bad" thing given that?
-
no nothing bad, is just info output
-
root@Caligula:~# fdisk -l
WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util fdisk doesn't support GPT. Use GNU Parted.
Disk /dev/sdb: 4000.8 GB, 4000787030016 bytes
255 heads, 63 sectors/track, 486401 cylinders, total 7814037168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000Device Boot Start End Blocks Id System
/dev/sdb1 1 4294967295 2147483647+ ee GPT
Partition 1 does not start on physical sector boundary.Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 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
Disk identifier: 0x0008169eDevice Boot Start End Blocks Id System
/dev/sda1 * 2048 944068607 472033280 83 Linux
/dev/sda2 944070654 976771071 16350209 5 Extended
/dev/sda5 944070656 976771071 16350208 82 Linux swap / SolarisWARNING: GPT (GUID Partition Table) detected on '/dev/sdc'! The util fdisk doesn't support GPT. Use GNU Parted.
Disk /dev/sdc: 4000.8 GB, 4000787030016 bytes
255 heads, 63 sectors/track, 486401 cylinders, total 7814037168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000Device Boot Start End Blocks Id System
/dev/sdc1 1 4294967295 2147483647+ ee GPT
Partition 1 does not start on physical sector boundary.WARNING: GPT (GUID Partition Table) detected on '/dev/sdd'! The util fdisk doesn't support GPT. Use GNU Parted.
Disk /dev/sdd: 4000.8 GB, 4000787030016 bytes
255 heads, 63 sectors/track, 486401 cylinders, total 7814037168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000Device Boot Start End Blocks Id System
/dev/sdd1 1 4294967295 2147483647+ ee GPT
Partition 1 does not start on physical sector boundary.WARNING: GPT (GUID Partition Table) detected on '/dev/sde'! The util fdisk doesn't support GPT. Use GNU Parted.
Note: sector size is 4096 (not 512)
Disk /dev/sde: 3000.6 GB, 3000592977920 bytes
255 heads, 63 sectors/track, 45600 cylinders, total 732566645 sectors
Units = sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000Device Boot Start End Blocks Id System
/dev/sde1 1 732566644 2930266576 ee GPTDisk /dev/md0: 8001.3 GB, 8001304920064 bytes
2 heads, 4 sectors/track, 1953443584 cylinders, total 15627548672 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 524288 bytes / 1048576 bytes
Disk identifier: 0x00000000Disk /dev/md0 doesn't contain a valid partition table
root@Caligula:~# -
Do you have a backup of your data from that array?
-
indeed. I became fastidious on backup very recently.
-
Ok. Time to destroy the array. The fdisk indicates that the drives have partition leftover and some weird error in the first partition. Could be the ssd side. Mdadm is better with "raw" disk like sda, sdb, etc not sdb1. So if you have your data backed up, stop the array and wipe the disks in the physical disks sections. Run a secure one for 10 seconds and then a quick one for each disk. Again with fdisk check that the drives sdb1, sdc1 and so on become sdb, sdc, etc. After you finish build the array with omv Web interface once the initial sync finishes, mount and reboot to check persistence. Of course don't run the wipe for the system drive, let us know how it goes
-
ok -
From the GUI... when I quick wiped the disk I got:
which kinda scared me. I rewiped it "just to make sure"
fdisk - reports:
-
They look clean now. You can proceed with raid building now, wait for sync finish and mount. Put some little data if you want and reboot. Hopefully this time you'll have persistent array
-
building now. fingers crossed.
-
okay - so it resynched.
I had a problem with OMV "thinking" the original data volume was still there, but the volume persisted after reboot.
I did decide to rebuild the OMV from scratch (takes like 15 min) and the raid is still there.
but I noticed something
I thought I read somewhere 127 is not "normal"
so I dropped the RAID and wiped the disks to make sure... Rebuilding the RAID now. one thing - it did maintain the raid after a couple of reboots prior to me dropping it.
-
raid arrays don't use a partition in omv.
-
Just for the record what the handling for those new hard drives ? did you format them before assembling the initial array or they came pre-partitioned?
did you initialise by any chance those drives in another system?Is important because some people with the same brand drives can have the same problems
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!