FS#4938 - mkinitcpio initramfs(?) tries to start root MD device twice

Attached to Project: Arch Linux
Opened by Anonymous Submitter - Sunday, 02 July 2006, 07:51 GMT
Last edited by Aaron Griffin (phrakture) - Tuesday, 01 August 2006, 02:42 GMT
Task Type Bug Report
Category System
Status Closed
Assigned To Aaron Griffin (phrakture)
Architecture not specified
Severity Low
Priority Normal
Reported Version 0.7.2 Gimmick
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Hi,

The last update / new kernel etc. seems to have fixed the MD/RAID array problems I was having (the previous update wasn't automaticaly starting up all my other MD RAID arrays, containing my /usr, /var, /home etc. file systems).

I'm now getting what could mostly be considered to be a cosmetic bug. It seems that for some reason kinit is trying to start the root MD device, immediately after the RAID module has already started it. Fortunately it seems that the RAID module is robust against this, otherwise I'd think there could have been some corruption of the RAID device superblock.

Here is the snippet of dmesg output showing the error message I get.

--
Uniform CD-ROM driver Revision: 3.20
md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 4.39
md: raid1 personality registered for level 1
md: bind<hda2>
md: bind<hdc2>
raid1: raid set md0 active with 2 out of 2 mirrors
md: kinit(pid 1) used obsolete MD ioctl, upgrade your software to use new ictls.
md: couldn't update array info. -22
md: could not bd_claim hda2.
md: md_import_device returned -16
md: could not bd_claim hdc2.
md: md_import_device returned -16
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
--

And here is the kernel command line I supply to start the root MD device.

--
root=/dev/md0 md=0,/dev/hda2,/dev/hdc2 ro clock=tsc elevator=cfq lapic nmi_watchdog=1
--
This task depends upon

Closed by  Aaron Griffin (phrakture)
Wednesday, 22 November 2006, 07:41 GMT
Reason for closing:  Fixed
Additional comments about closing:  Checking for existing /dev/mdX device in kinit, which a tad "hackey" works just fine.
Comment by Dale Blount (dale) - Friday, 07 July 2006, 12:31 GMT
mine does this too, with additional warnings:

md: starting md1 failed
EXT2-fs warning (device md1): ext2_fill_super: mounting ext3 filesystem as ext2

these come after the last -16 error.
when the system is fully up, / is mounted ext3 though.
Comment by Aaron Griffin (phrakture) - Monday, 17 July 2006, 08:46 GMT
I submitted the following to the klibc mailing list (edited slightly) a while back:

>>>>
> The following is reported by kinit when md0 is already active (this
> was typed by hand so minor textual errors may be present):
> md: will configure md0 (super-block) from /dev/sda1,/dev/sdb1, below
> md: kinit (pid 1 ) used obsolete MD ioctl, upgrade your software to
> use new ictls
> md: loading md0: /dev/sda1
> md: couldn't update array info. -22
> md0: personality does not support diskops!
> md0: personality does not support diskops!
> md: starting md0 failed
>
> A while back I had submitted a patch to simply skip assembly if
> /dev/mdX already existed. This was changed to use an ioctl to check
> if it is assembled instead of checking the dev FS. It appears that
> this produces those errors. What concerns me the most is the
> "obsolete" line.

Okay, this seems that something that could be fixed, but not is probably
not the right time.
- hpa

<<<<
I will go ahead and repatch this at some point in the next few days.
Comment by Anonymous Submitter - Friday, 21 July 2006, 23:12 GMT
Just a thought, and something I might try a bit later today or tomorrow. If kinit/klibc can automatically start MD arrays, then would putting /etc/mdadm.conf (with ARRAY entries) on the initcpio image make kinit/klibc start all the arrays, instead of having a Archlinux boot script do it ? If that is possible I think it would be a slightly better solution than having to add the root array assembly details to the kernel command line.
Comment by Aaron Griffin (phrakture) - Tuesday, 01 August 2006, 02:25 GMT
Added a cheap hackish fix for now in kinit. This has been uploaded to testing. Please let me know if this fixes things. It should skip assembling an md device if /dev/mdX already exists in the filesystem. This is not perfect, but should cover most cases.
Comment by Dale Blount (dale) - Monday, 07 August 2006, 12:50 GMT
Using all the related packages from testing, the errors are mostly gone. The only thing that's left for me is this:

After "Loading UDev events" and before "Activating RAID arrays" in the boot sequence, I get an error creating /dev/md0: File exists.
Comment by Dale Blount (dale) - Monday, 07 August 2006, 13:08 GMT
I should note my / isn't raid and md0 is only defined in mdadm.conf, passing the kernel no md= params.
Comment by Aaron Griffin (phrakture) - Monday, 07 August 2006, 14:45 GMT
I'm confused. If your root isn't RAID, you should have no need for raid assembly via mkinitcpio. If kinit happens to pick up your non-root raid device, adding raid=noautodetect to the kernel params should "fix" this (by preventing kinit from auto-assembling anything it can).
Comment by Dale Blount (dale) - Monday, 07 August 2006, 15:34 GMT
I don't need it on this box, but I was seeing the same errors on boxes where / was raid. Regardless, something tries to mknod twice.
Comment by Aaron Griffin (phrakture) - Monday, 07 August 2006, 17:11 GMT
Ok, so the current issue is in normal userspace? If it's after "Loading UDev events" and before "Activating RAID arrays", then it is an issue with the initscripts. I'll take a peek later if no one else gets a chance...
Comment by Dale Blount (dale) - Monday, 07 August 2006, 17:21 GMT
Yes, normal userspace. I bet it's coming from the "Activating RAID arrays" section of the initscripts.
Comment by Dale Blount (dale) - Wednesday, 23 August 2006, 19:22 GMT
Can we get these fixes pushed into current even if thy're hacks? I forgot that raid+cpio didn't work and found myself running to the datacenter to boot back into initrd.
Comment by Anonymous Submitter - Saturday, 26 August 2006, 05:00 GMT
I've eventually got around to putting mdadm.conf onto the image, and removing the root md device spec from the kernel command line, unfortunately it didn't work. There may be a bit more pressure on getting a solution to this, as I think I've seen fairly recently a patch to the Linux kernel which will remove the ability to start MD raid arrays from the kernel command line, I'm assuming because they're expected to be started by kinit.
Comment by Roman Kyrylych (Romashka) - Monday, 09 October 2006, 09:39 GMT
Isn't this bug fixed in the recent mkinitcpio?
Comment by Aaron Griffin (phrakture) - Monday, 13 November 2006, 23:01 GMT
This was fixed, but I am not sure of the current status. It was not fixed in klibc, but i added my own wonky fix. I will await verification.
Comment by Dale Blount (dale) - Tuesday, 14 November 2006, 13:00 GMT
I'm pretty sure this is fixed, but I'm not sure if the hack to stop it from creating a /dev/mdX that already exists works. No biggie though, that error is only cosmetic.

Loading...