Bug 1246906

Summary: Automatic mount points using RAID on BTRFS it seems that is not working properly
Product: [Fedora] Fedora Reporter: Bruno Roberto Zanuzzo <brunorobertozanuzzo>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 23CC: anaconda-maint-list, brunorobertozanuzzo, g.kaviyarasu, jonathan, vanmeeuwen+fedora
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-03-23 21:13:51 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
installation logs: anaconda,storage,program
none
grub2.cfg none

Description Bruno Roberto Zanuzzo 2015-07-26 19:59:03 UTC 
Description of problem:
Currently it is possible to 'normal' installation using automatic creation of mount points using btrfs (selecting two disk), but after installation, to start the boot process, the system get stuck and goes into emergency mode.

Version-Release number of selected component (if applicable):
* major components: anaconda-23.17-1.fc23.x86_64, python3-blivet-1.10-1.fc23
* fedora Image: branched 23 Alpha TC2
* kernel: Linux 4.2.0-0.rc3.git4.1.fc23.x86_64 #1 SMP Fri Jul 24 14:24:34 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

How reproducible:
Always

Steps to Reproduce:
1. Select two disks
2. Select "I will configure partitioning"
3. Select Btrfs and finally create mount points automatically

Actual results:
Seems like mount points are not properly setup on this schema because after install and restart system:
"error: can't find command '/dev/vdb1' Press any key to continue...
Boot proceed for a while and get stuck on "Failed to start Switch Root" entering in emergency mode.

"Failed to switch root: Specified switch root path /sysroot does not seem to be an OS tree. os-release file is missing."

Expected results:
Setup raid to works properly with btrfs schema.

Additional info:
Disk type: x2 VirtIO
Comment 1 David Shea 2015-07-27 14:18:34 UTC 
Please attach the logs from the install. They are available in /tmp in the installer environment and copied to /var/log/anaconda in the installed system.
Comment 2 Bruno Roberto Zanuzzo 2015-07-27 23:57:29 UTC 
Created attachment 1056820 [details]
installation logs: anaconda,storage,program

Attached logs: anaconda.log, storage.log, program.log and two images.

Just an update description of the problem you informed:

After install and restart: "error: can not find command '/dev/vdb1'" according to the figure 1.png..

But the system does not automatically goes into emergency mode, it "hangs" during the boot process, figure 2.png. Forcing system restart, then yes goes into emergency mode.
Comment 3 David Shea 2015-08-06 19:09:13 UTC 
I'm pretty confused. The message in 1.png is from grub, and indicates that there's something wrong with the grub.cfg created for your system. Can you attach /boot/grub2/grub.cfg to this bug? What did you do to continue booting?
Comment 4 Bruno Roberto Zanuzzo 2015-08-07 07:47:58 UTC 
Created attachment 1060254 [details]
grub2.cfg

Here is the grub.cfg.

After giving this error grub (1.png), the process of initialization not get to be completed, hangs in one of the processes (2.png).

If you try to restart the system, goes straight to the emergency mode.

About the installation: when the schema was automatically set, /boot is as "standard" partition, but selects two discs. On the other hand, the root Is set as BTRFS and 'RAID' level: "single".
Comment 5 David Shea 2016-03-23 21:13:51 UTC 
This appears to be the same problem as 1214441: the kernel command line was broken into multiple lines due to some problems between grub2-mkconfig and the live environment.

*** This bug has been marked as a duplicate of bug 1214441 ***