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
Opened by Anonymous Submitter - Sunday, 02 July 2006, 07:51 GMT
Last edited by Aaron Griffin (phrakture) - Tuesday, 01 August 2006, 02:42 GMT
|
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.
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.
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.
>>>>
> 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.
After "Loading UDev events" and before "Activating RAID arrays" in the boot sequence, I get an error creating /dev/md0: File exists.