2015-08-31 3:08 GMT+02:00 Chris Murphy lists@colorremedies.com:
On Sun, Aug 30, 2015 at 3:09 PM, Samuel Rakitničan samuel.rakitnican@gmail.com wrote:
I have moved / partition to another partition formed in RAID 0 consisting of two SSDs. I have updated fstab with new partition UUID,
Using blkid, make sure you use the UUID= value for the *filesystem volume*, not PARTUUID=.
I believe I am, but the issue is that it can't even look for it because is not assembled (I think) anyway:
$ blkid /dev/sda: TYPE="isw_raid_member" /dev/sdb: TYPE="isw_raid_member" /dev/sdc1: LABEL="gedora" UUID="24d33c42-c8d5-4351-a89c-08cfa70b3115" TYPE="ext4" PARTUUID="c35c32fe-01" /dev/sdc2: LABEL="swap" UUID="50ba9ee0-2e73-4d89-8997-024a0d4b91da" TYPE="swap" PARTUUID="c35c32fe-02" /dev/sdc3: LABEL="homie" UUID="9946e484-fe87-403b-8b79-1ff15214f262" TYPE="ext4" PARTUUID="c35c32fe-03" /dev/sdd: UUID="cc3a22dc-21ea-4081-8b0b-21007c981eb0" TYPE="crypto_LUKS" /dev/sde1: LABEL="Transcend" UUID="A784-A6A0" TYPE="vfat" PARTUUID="c3072e18-01" /dev/sdf1: UUID="E250-35EB" TYPE="vfat" PARTUUID="f6aa9f3a-01" /dev/sdg1: UUID="574B-489E" TYPE="vfat" PARTUUID="000eb8bf-01" /dev/md126p2: LABEL="gedora" UUID="a7a06541-ea6f-42e5-8e95-b7bdcafb33cf" TYPE="xfs" PARTUUID="ccd4b28b-a762-4b0d-b157-9bacd3d8411d" /dev/md126p3: LABEL="homie" UUID="51020653-40f4-44bf-a1f2-a796758fac60" TYPE="xfs" PARTUUID="6c017e9e-1d47-427e-9293-b4ebe368fcc7"
# cat /etc/fstab
# # /etc/fstab # Created by anaconda on Wed Feb 4 19:50:51 2015 # # Accessible filesystems, by reference, are maintained under '/dev/disk' # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info # UUID=a7a06541-ea6f-42e5-8e95-b7bdcafb33cf / xfs defaults,lazytime 1 1 #UUID=9946e484-fe87-403b-8b79-1ff15214f262 /home ext4 defaults,lazytime 1 2 #UUID=50ba9ee0-2e73-4d89-8997-024a0d4b91da swap swap defaults 0 0
And sure enough I can see exact same UUID in not found message on boot time.
reinstalled GRUB2 and rebuild initramfs using dracut -f. Now computer boots fine from RAID partition but hangs on when initramfs needs to boot kernel from / partition found on RAID, because it can't find partition with UUID that I've put in fstab.
Dracut should first look for the mduuid (which is either baked into the initramfs via /etc/mdadm.conf; or hinted using rd.md.uuid= as a boot parameter, this uuid is the mdadm uuid), which causes the array to be assembled, and only after that does the fs volume UUID become available which systemd is looking for based on the boot param root=UUID=.
I have no experience with mdadm before, but I tried to create and remade initramfs using "mdadm --verbose --detail --scan > /etc/mdadm.conf".
# cat /etc/mdadm.conf ARRAY /dev/md/imsm0 level=container num-devices=2 metadata=imsm UUID=03afe6a1:b37c71b2:f9b7eb4e:9322a561 devices=/dev/sda,/dev/sdb ARRAY /dev/md/TrancendPowa_0 level=raid0 num-devices=2 container=/dev/md/imsm0 member=0 UUID=1d2f6a80:99e713e3:73601439:2cdb477f devices=/dev/sda,/dev/sdb
But it doesn't work anyway.
Now from what I have understood when it drops me to dracut prompt in initramfs boot process I indeed can't find the RAID assembled BUT I can assemble it manually by using "mdadm -I /dev/sda" and "mdadm -I /dev/sdb". If I boot from old hard drive the RAID is assembled normally in kernel on boot time.
Huh. That's nice but I don't know why it works with a generic initramfs. Is this mdadm metadata v0.9? If so that's kernel autodetect. mdadm v.1.x is initramfs autodetect.
No, I don't know if it assembles in generic initramfs (probably not), but it assembles in normal kernel, the full one.
Anyway, try making changes per above, and if that doesn't work then boot with parameters rd.debug rd.shell and figure out a way to write out the journal somewhere like a USB stick mounted at /sysroot.
journalctl -b -l -o short-monotonic > /sysroot/journal.txt
Here it is: https://www.dropbox.com/s/fnt2r46izuhpbvw/journal.txt.gz?dl=0
The RAID is formed using onboard southbridge Intel controller.
Oh in that case this is imsm metadata, not mdadm metadata, so ignore 0.9 vs 1.x.
I have managed to extract data from initramfs but I am not sure what to look for, in particular what brings up RAID assembly. /etc/udev/rules.d/65-md-incremental-imsm.rules seems like it's responsible to assemble, but I am not sure.
Yep sounds right.
Any thoughts why imsm RAID is not assembled in initramfs on boot?
rd.debug rd.shell post a URL for the journal.
Thank you and everyone else!
-- Chris Murphy -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org