Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 1444277

Summary: F26 Alpha 1.7 ARM LXQT starts on emergency mode
Product: [Fedora] Fedora Reporter: Frederico Lima <fredhgl>
Component: mediawriterAssignee: Martin Bříza <mbriza>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 26CC: mbriza
Target Milestone: ---   
Target Release: ---   
Hardware: armhfp   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-05-10 09:52:28 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:
Bug Depends On:    
Bug Blocks: 1310542    
Attachments:
Description Flags
Loop with errors from dracut
none
At last, emergency mode. none

Description Frederico Lima 2017-04-21 03:36:59 UTC
Created attachment 1273143 [details]
Loop with errors from dracut

Description of problem:
I used Fedora Media Writer to burn the image on my sandidsk usb 3.0 cruzer glide 16gb usb stick, I booted it with my raspberry pi 3.
LXQT didn't even started, so I followed steps from raspberry pi 3 official website to allow raspberry boot from usb.
(https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md)

So, after that I could boot up my usb stick.

But a lot of messages was displayed on the Fedora initialization (look at attachment)

And after that, Fedora ARM enters the emergency mode.


Version-Release number of selected component (if applicable):
F26 Alpha 1.7 ARM LXQT
Fedora-LXQt-armhfp-26_Alpha-1.7-sda.raw.xz


How reproducible:

Steps to Reproduce:
1. Download Fedora-LXQt-armhfp-26_Alpha-1.7-sda.raw.xz from getfedora.org
2. Burn on usb stick with Fedora Media Writer
3. Boot from usb stick on raspberry pi 3 (to enable boot on raspberry pi 3 you have to append program_usb_boot_mode=1 to  /boot/config.txt and reboot raspberry with an sd card with already installed raspbian official distro to changes on the firmware be applyied)

Actual results:
Emergency mode

Expected results:
LXQT started

Additional info:

Comment 1 Frederico Lima 2017-04-21 03:40:58 UTC
Created attachment 1273144 [details]
At last, emergency mode.

Comment 2 Frederico Lima 2017-04-21 03:54:25 UTC
I want to state that I used usb stick because I can't burn the image on my sd card for the same problem of this bug #1443981

Comment 3 Martin Bříza 2017-04-24 09:13:24 UTC
Hmm, I don't think this is a problem of Fedora Media Writer.
FMW just takes the data it gets and writes it to the target drive. Please consult the official Fedora ARM documentation on how to boot Fedora images from a USB drive on Raspberry Pi. From what I've read now, it's not mentioned anywhere, so I'm not sure it's a supported use-case with the current releases.

Comment 4 Frederico Lima 2017-04-25 15:25:24 UTC
I can boot from USB drive.
I know how to boot from usb drive on RPi3.
it boots the kernel and after a long time waiting and a lot of debug messages it enters in emergency.
Take a look on my screenshots attached.
If it is not an FMW problem, assign this issue to someone that can fix this.

Thanks

Comment 5 Martin Bříza 2017-04-25 15:32:22 UTC
If writing the image by dd to the USB drive works and writing it by FMW doesn't, it's indeed a FMW problem. If it doesn't, I can't do much about it.
Honestly, I don't know who to contact. I suggest you contact the Fedora ARM mailing list (arm.org) and consult the further approach there.

Comment 6 Martin Bříza 2017-05-10 09:52:28 UTC
Since there's not more information provided and the bug is most likely not related to mediawriter, closing.