2015-08-31 3:08 GMT+02:00 Chris Murphy <lists(a)colorremedies.com>:
On Sun, Aug 30, 2015 at 3:09 PM, Samuel Rakitničan
<samuel.rakitnican(a)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(a)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