| View previous topic :: View next topic |
| Author |
Message |
ICannotStandXorg
n00b
Joined: 02 Jun 2016
Posts: 9
|
 Posted: Mon May 22, 2017 1:47 am Post subject: [SOLVED] Troubles booting with RAID. |
 |
|
Hello.
I am currently attempting to boot with four partitions that are conjoined into one RAID0 device. However, when I boot I get an error while booting up: | Code: | | [ 10.269054] EXT4-fs (md3): unable to read superblock |
This is what my lsblk looks like:
| Code: | sdd 8:48 0 3.7T 0 disk
├─sdd1 8:49 0 22G 0 part
└─sdd4 8:52 0 3.6T 0 part
└─md3 9:3 0 14.5T 0 raid0 /home
sdb 8:16 0 3.7T 0 disk
├─sdb4 8:20 0 3.6T 0 part
│ └─md3 9:3 0 14.5T 0 raid0 /home
└─sdb1 8:17 0 22G 0 part
loop0 7:0 0 2.5G 1 loop
sdc 8:32 0 3.7T 0 disk
├─sdc1 8:33 0 22G 0 part
└─sdc4 8:36 0 3.6T 0 part
└─md3 9:3 0 14.5T 0 raid0 /home
sda 8:0 0 3.7T 0 disk
├─sda4 8:4 0 3.6T 0 part
│ └─md3 9:3 0 14.5T 0 raid0 /home
├─sda2 8:2 0 128M 0 part /boot
├─sda5 8:5 0 21.4G 0 part /
├─sda3 8:3 0 512M 0 part [SWAP]
└─sda1 8:1 0 2M 0 part
|
Here is my /etc/fstab:
| Code: |
/dev/sda2 /boot ext4 defaults,noatime 0 2
/dev/sda5 / ext4 noatime 0 1
/dev/sda3 none swap sw 0 0
/dev/md3 /home ext4 defaults 0 0
|
Every time I search up this issue, it seems as if people are having failing disks or something similar. None of them can mount drives and fsck gives bad superblock or something.
I can mount it just fine and fsck on /dev/md3 gives:
| Code: |
e2fsck 1.43.3 (04-Sep-2016)
/dev/md3: clean, 3613099/485478400 files, 3620456320/3883816448 blocks
|
On top of that when it's mounted, all data is perfectly easily accessible.
Steps I have taken to try to fix:
I added this to /etc/default/grub:
| Code: |
GRUB_CMDLINE_LINUX_DEFAULT="md=3,/dev/sda4,/dev/sdb4,/dev/sdc4,/dev/sdd4"
|
This part does seem to be working, as I can see it assembling the drive in the boot log I believe:
| Code: |
May 22 02:59:47 vector kernel: [ 8.394539] md: bind<sdd4>
May 22 02:59:47 vector kernel: [ 8.395060] md: bind<sdc1>
May 22 02:59:47 vector kernel: [ 8.395605] md: bind<sdb4>
May 22 02:59:47 vector kernel: [ 8.404553] md: export_rdev(sdb1)
May 22 02:59:47 vector kernel: [ 8.404796] md: export_rdev(sdb1)
May 22 02:59:47 vector kernel: [ 8.405160] md: bind<sdc4>
May 22 02:59:47 vector kernel: [ 8.428838] Error: Driver 'pcspkr' is already registered, aborting...
May 22 02:59:47 vector kernel: [ 8.436062] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
May 22 02:59:47 vector kernel: [ 8.436087] iTCO_wdt: Found a Cougar Point TCO device (Version=2, TCOBASE=0x0460)
May 22 02:59:47 vector kernel: [ 8.436155] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
May 22 02:59:47 vector kernel: [ 8.672407] i801_smbus 0000:00:1f.3: SMBus using PCI interrupt
May 22 02:59:47 vector kernel: [ 8.942579] [drm] Initialized
May 22 02:59:47 vector kernel: [ 9.497131] md: bind<sda4>
May 22 02:59:47 vector kernel: [ 9.498360] md/raid0:md3: remove inactive devices before converting to RAID0
May 22 02:59:47 vector kernel: [ 9.498361] md: pers->run() failed .
|
I am very concerned about those final 3 lines there. I do not believe that there is any inactive devices, /proc/mdstat has
| Code: |
Personalities : [raid1] [raid0]
md3 : active raid0 sda4[0] sdd4[3] sdc4[2] sdb4[1]
15535265792 blocks super 1.2 512k chunks
unused devices: <none>
|
I enabled the kernel options and started the openrc service shown on this page: https://wiki.gentoo.org/wiki/Complete_Handbook/Software_RAID#Installing_the_Tools
EDIT: I'm thinking this could potentially be fixed by simply making it such that the partition doesn't automatically mount, remove it from fstab and remove all mentions of raid in configs, as it does mount in the live system, but hopefully I can get it to automount like thi.
Thanks for your time, if any more information is needed I'd be happy to provide.
Last edited by ICannotStandXorg on Tue May 23, 2017 2:13 am; edited 1 time in total |
|
| Back to top |
|
 |
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54244
Location: 56N 3W
|
| Posted: Mon May 22, 2017 9:04 am Post subject: |
|
|
ICannotStandXorg,
There are two ways to start your raid set at boot.
The kernel can auto assemble the raid set but only if it uses version 0.90 raid metadata.
With version 1.2 metadata, you must use mdadm.
With this method, you add mdadm to the boot runlevel, so that the raid is assembled before the localmount service starts.
Check your raid metadata version.
| Code: | $ sudo mdadm -E /dev/sda1
Password:
/dev/sda1:
Magic : a92b4efc
Version : 0.90.00 <---------------------
UUID : 9392926d:64086e7a:86638283:4138a597
Creation Time : Sat Apr 11 16:34:40 2009
Raid Level : raid1
Used Dev Size : 40064 (39.13 MiB 41.03 MB)
Array Size : 40064 (39.13 MiB 41.03 MB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 125
Update Time : Sun May 21 12:35:28 2017
State : clean
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0
Checksum : b654a80 - correct
Events : 40
Number Major Minor RaidDevice State
this 0 8 1 0 active sync /dev/sda1
0 0 8 1 0 active sync /dev/sda1
1 1 8 17 1 active sync /dev/sdb1
2 2 8 33 2 active sync /dev/sdc1
3 3 8 49 3 active sync /dev/sdd1 |
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
ICannotStandXorg
n00b
Joined: 02 Jun 2016
Posts: 9
|
| Posted: Mon May 22, 2017 3:55 pm Post subject: |
|
|
I appear to have 1.2 metadata.
I did add 'mdraid' to boot as described in the wiki article I linked about the steps I took to, that is what you mean by addming mdadm to the boot runlevel? |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54244
Location: 56N 3W
|
| Posted: Mon May 22, 2017 4:20 pm Post subject: |
|
|
ICannotStandXorg,
What is in your mdadm.conf file?
Somehow you need to tell mdadm how to assemble the raid set.
Looking at the wiki page | Code: | | [*] Autodetect RAID arrays during kernel boot |
is only useful for version 0.9 raid metadada and you have version 1.2
So we can rule out kernel auto assembly.
I don't use grub2 so I'm not sure what | Code: | | GRUB_CMDLINE_LINUX_DEFAULT="md=3,/dev/sda4,/dev/sdb4,/dev/sdc4,/dev/sdd4" |
does.
Sight of all of dmesg would be good.and tell the URL.
Do you use an initrd?
mdadm can be in the initrd (and must be for root on raid) or in the boot runlevel.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
frostschutz
Advocate
Joined: 22 Feb 2005
Posts: 2977
Location: Germany
|
| Posted: Mon May 22, 2017 7:14 pm Post subject: |
|
|
https://www.kernel.org/doc/html/v4.10/admin-guide/md.html
For this (new) method to assemble RAID w/o initramfs, it seems to be happening quite late in the boot process (8+ seconds?), that seems slightly odd to me. That's about when my initramfs assembles my RAID and it deliberately sleeps a few seconds.
Could it be a timing issue?
Since your root partition is not even on the RAID, you could get rid of that kernel option and have your regular bootup scripts take care of RAID assembly.
(These kernel options are interesting, they're adding the same for device mapper so it'll be possible to boot LVM w/o initramfs too.) |
|
| Back to top |
|
|
ICannotStandXorg
n00b
Joined: 02 Jun 2016
Posts: 9
|
| Posted: Tue May 23, 2017 2:12 am Post subject: |
|
|
Hello.
Thank you all for your replies, however I seem to have found a fix. In /etc/mdadm.conf I initially just had the line: | Code: | | ARRAY /dev/md3 metadata=1.2 name=rescue:3 UUID=130c3047:9e1498f0:b27764ce:5ab7ed89 |
and I added in | Code: | | DEVICE /dev/sda4 /dev/sdb4 /dev/sdc4 /dev/sdd4 |
and now it appears to be booting just fine with | Code: | | EXT4-fs (md3): mounted filesystem with ordered data mode. Opts: (null) |
at the very bottom of boot log. So I'm pretty sure that it is working now. Thank you all.[/code] |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54244
Location: 56N 3W
|
| Posted: Tue May 23, 2017 8:41 am Post subject: |
|
|
ICannotStandXorg,
| Code: | | UUID=130c3047:9e1498f0:b27764ce:5ab7ed89 |
should work.
It must me the UUID of the raid set, not the UUID of the filesystem on the raid set.
| Code: | $ /sbin/blkid
/dev/sda1: UUID="9392926d-6408-6e7a-8663-82834138a597" TYPE="linux_raid_member" PARTUUID="0553caf4-01"
/dev/sdb1: UUID="9392926d-6408-6e7a-8663-82834138a597" TYPE="linux_raid_member" PARTUUID="0553caf4-01"
/dev/md125: UUID="741183c2-1392-4022-a1d3-d0af8ba4a2a8" TYPE="ext2" |
That's my /boot showing the raid UUID and filesystem UUID.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
frostschutz
Advocate
Joined: 22 Feb 2005
Posts: 2977
Location: Germany
|
| Posted: Tue May 23, 2017 2:06 pm Post subject: |
|
|
I remove the metadata= name= etc. conditions from my mdadm.conf. The UUID alone is sufficient, and if some of the other things don't match (the name in particular) it might prevent the array from being assembled.
Providing a list of DEVICE is not a good idea as those device names might change in unexpected ways.
If you do specify it, it should be liberal (/dev/sd* or /dev/vd* in some virtio-VM)
You should add MAILADDR and setup some kind of MTA so you will be notified of RAID failures. Same for smartmontools, regular selftests, disk monitoring, etc. |
|
| Back to top |
|
|
|
Kernel & Hardware
