Bug 1282244
| Summary: | Bootable USB Fails Testing on Startup | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Adam Stewart <ajstewart426> | ||||||
| Component: | lorax | Assignee: | Brian Lane <bcl> | ||||||
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 29 | CC: | 1p8g33ljh9si, anaconda-maint-list, bcl, fabio.porcedda, fedorabugs, Frodox, jim.cromie, jimmy, krellan, mark, pjones, pzbowen, ralph.katieb, robinlee.sysu, surya_prabhakar | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Mac OS | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2019-08-21 16:37:59 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: |
|
||||||||
Another comment I would like to make on this issue. If I instead choose the first option, "Start Fedora Live", it successfully boots. But when it starts up, I get the following error message: Oops! We're sorry, it looks like BOOT_IMAGE=/isolinux/vmlinuz0 crashed. Please contact the developer if you want to report the issue. Aside from that, everything looks fine after booting. I confirm this is still an active bug.
I burned the latest Fedora 23 Workstation ISO to a brand new 128GB Lexar USB3 device (after confirming downloaded checksums) and my USB boot with "verify" attempt on the media produced EXACTLY the same response as above (attempting to install on an ASUS ZenBook).
My attempt also failed at exactly the same point ("004.8%" into the verify process).
I can confirm I am getting this problem as well, I've tested it on two difference devices (Macbook Air 2015 and HP Pavilion) and with 2 different USBs. I would really like to switch to Fedora 23 but I'm concerned to install it without 100% success confirmations, given that older versions of Fedora have caused severe problems on Macbooks. Would somebody please advise on the best course of action? Is there a workaround that will register a success? Is it a problem with my device/stick? Do I have to wait till another ISO is released? What do I do? I confirm that I receive the exact same message at exactly 4.8% on a mid 2012 macbook pro and a dell desktop computer, using a USB stick. It would be very nice to have some feedback and maybe possible fix. You are encountering this bug because of the way OSX handles USB devices. You run the dd command, which wipes the drive and does all it's fun stuff. Now, what Fedora is looking for is the drive to just be as is once it finishes writing it. Unfortunately, OSX finishes the dd command and then immediately automounts the drive. This, of course, triggers a whole bunch of system indexing tools, writing countless amounts of hidden .whatever files. This, in turn, changes the drive as the dd command saw it. Therefore, the data sum that the Fedora media checker is expecting is not the same, as the drive's contents have been changed. Truthfully, you are safe to just go to town without verifying the drive. Either that, or install Disk Arbitrator to block drive automounting and then run dd again....will work without a hitch. I created an email account just to post this reply. Sad, huh? @Tim Thank you! This fixed my issue. What I did: 1. To dual boot, use disk utilities to repartition the drive. 2. Run disk arbitrator and then run the dd commands on your USB device. 3. Restart computer and press alt/option. 4. Choose Fedora, choose test media. Passes. Fedora boots. 5. Install Fedora, choose the partition you created and delete it and reclaim its space. 6. Install. 7. Reboot. Mac cannot be booted from GRUB, you must press alt/option key at boot and select Mac to boot Mac. 8. You are all set, other than the fact you won't have WiFi and a bunch of hardware/driver stuff will be wonky. But that is for separate issues. Thank you, Tim. Confirmed on F-24 workstation live image passes check when burnt to DVD (and boots sucessfully), but fails check when rawritten to USB stick. LXDE fails from USB too (didnt try burning) LXDE image wont boot either, so unsure its not actually corrupt. I met the same issue with Fedora WS 24 x86_64: Fedora-Workstation-Live-x86_64-24-1.2.iso My device is MS Surface 3. I used dd to make a bootable USB disk. I ran it with another usual notebook under Legacy boot and mediacheck succeeded. So the USB disk is OK at the beginning. Then I tried to run it on Surface 3 and mediacheck failed at 4.8%. And then if I tried to boot the USB disk again on the usual notebook, mediacheck would also failed at 4.8%. So it seems the USB disk was written during the boot on Surface 3. I moved the issue to Fedora 24. The issue still persists in https://download.fedoraproject.org/pub/fedora/linux/releases/test/25_Alpha/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-25_Alpha-2.iso I expire the same issue on Fedora 25 stable release, trying to boot on my ASUS Z170 stationary setup. Hangs on exactly 004.8%, 3 tries out of 4, with double usb storage devices tested, known to be good. The times when i manage to get it, i boot into the system with usb not working correctly, mouse will not move. Hi, long dormant account here, reactivated just to report this bug. I too have this bug happening. USB thumbdrive is Sandisk Cruzer 8GB. Fedora 25 stable release. Version is Fedora Workstation Live x86_64 25 1.3. I use a Mac desktop, normally. On MacOS, using Fedora Media Writer worked nicely, detecting the USB thumbdrive perfectly. No errors there. However, booting the resulting thumbdrive, on a PC (not Mac), failed, at exactly 4.8%, just like the others have reported. It then locks up with some error messages and fails to boot. There's no error on the media, it's a software bug somewhere, because that 4.8% is reproducible consistently. Also tried UNetbootin and that didn't work either, writing a garbled image that failed to boot, a bunch of weird errors, but that's a known issue. UNetbootin doesn't play well with Anaconda, expecting the standard SYSLINUX bootloader instead. Finally, borrowed somebody else's external USB DVD burner, and burned a traditional DVD. That worked perfectly, the first time. So, lesson learned, it appears that USB isn't ready for prime time (at least when burned from a Mac). Traditional DVD media still works great. Josh I can confirm it with last fedora/centos. Could someone change release to RAWHIDE? I test Windows 10 and problem exactly described in comment #5 Unfortunately, Win10 finishes the dd command and then immediately automounts the drive. This, of course, triggers a whole bunch of system indexing tools, restore point tools and so on, writing some data into efi partition and this, in turn, changes the drive data sum as the dd command saw it. Hybrid iso has 2+ partition, for legacy and EFI boot. Like Device Boot Start End Sectors Size Id Type Fedora-Workstation-Live-x86_64-25-1.3.iso1 * 0 2813951 2813952 1,4G 0 Empty Fedora-Workstation-Live-x86_64-25-1.3.iso2 91688 102327 10640 5,2M ef EFI (FAT-12/16/32) Fedora-Workstation-Live-x86_64-25-1.3.iso3 102328 125671 23344 11,4M 0 Empty Device Boot Start End Sectors Size Id Type CentOS-7.3-x86_64-Everything-1611.iso1 * 0 16173055 16173056 7,7G 0 Empty CentOS-7.3-x86_64-Everything-1611.iso2 5328 17895 12568 6,1M ef EFI (FAT-12/16/32) Windows see EFI(FAT) partition and automounts it in RW mode, what causes problems. It creates dir on top level * 'System Volume Information' with file 'IndexerVolumeGuid' with random uid '{70F2BC5F-E867-428F-B8C7-46376907D046}' and this is the reason. #1. I check a trick - manually create empty file 'System Volume Information' on top level of EFI partition (which is from efiboot.img) and implantisomd5 again. And it helps - it prevents windows from creating custom directory and so md5 sum stay unchanged. Do some one know, how to fix lorax template in this way? Looks like there should be some fixes in ('mkefiboot', '--label=ANACONDA', '/build/os-os-rt-lorax-raw/EFI/BOOT', '/build/os-os-rt-lorax-raw/images/efiboot.img') Brian? #2. Another (universal/right) way to fix it - add some attribute for EFI(FAT-12/16/32) partition that it is read-only, so both Win and Mac would stop to write there. But I do not know/not sure, is it possible and how to achieve it. Are all of these failures using UEFI? I'm fairly sure mediacheck has never worked with a UEFI boot (the partition layout that it sees is different than with a BIOS boot so the checksums don't work). We should probably just drop mediacheck from the grub2 menu in lorax. > Are all of these failures using UEFI? No! In legacy BIOS boot. So you could just write iso in linux with dd, insert and eject USB-flash from win10 pc, and it become broken (mediacheck would failed). Both in Leacy and UEFI mode. > I'm fairly sure mediacheck has never worked with a UEFI boot Ugh..? I do not know why do you think so, but mediacheck in UEFI works for me all the time before, both in Fedora-Rawhide and Rhel7.3. > We should probably just drop mediacheck from the grub2 menu in lorax. I think we should never do that. In last way windows' users should remove it manually by editing boot-item. But for other users it is only way to be sure that iso was correctly download and burned (and usb-flash is fine). Created attachment 1284410 [details]
stuff MacOS adds to the USB drive
Created attachment 1284411 [details]
original contents of a USB drive
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle. Changing version to '27'. Still persist with Fedora 29 Beta on Surface 3 Reproduced with Fedora 29 final release (Fedora-Workstation-Live-x86_64-29-1.2.iso as master) with a Macbook Pro running macOS High Sierra. I used Fedora Media Writer. If I removed the USB drive when it finished and immediately booted it on another machine it works. If I reinsert it into the system running macOS, and then try again booting, it fails at 4.8%. It looks like both Windows and macOS are adding files when mounting volumes from the drive. It is unclear if this has any impact on the usability of the media. As far as I can tell this is caused by mounting the USB on an OS that modifies the files. I'm unable to reproduce it myself, using macOS v10.13.6 -- it doesn't recognize the USB written by dd or by mediawriter. The only thing I can suggest is to try not to let it be mounted. |
Description of problem: When booting from a bootable USB, there are three options. The second, and default, option is to "Test this media & start Fedora Live". But when I try testing it, it fails. See the error message below. Version-Release number of selected component (if applicable): Fedora 23 How reproducible: The first time I noticed this problem, I had used Rawrite 32 on Windows 10 to create the bootable USB and booted onto a Lenovo Thinkpad X1 Carbon (3rd gen). I wanted to try it again to make sure I didn't do anything wrong, so the second time I used dd on Mac OS X 10.11.1 to create the bootable USB and booted onto a MacBook Pro w/ Retina Display. Both times, the USB failed testing. Steps to Reproduce: 1. Create bootable USB using one of the programs above. 2. Restart, select the Fedora Live boot media 3. Select "Test this media & start Fedora Live" Actual results: Here is the output of testing: [ 0.040540] DMAR-IR: [Firmware Bug]: ioapic 2 has no mapping iommu, interrupt remapping will be disabled [ 2.364219] irq 17: nobody cared (try booting with the "irqpoll" option) [ 2.364302] handlers: [ 2.364309] [<ffffffffa00ce640>] sdhci_irq [sdhci] threaded [<ffffffffa00cb480] sdhci_thread_irq [sdhci] [ 2.364310] Disabling IRQ #17 [ 2.683926] sd 6:0:0:0: [sdb] No Caching mode page found [ 2.683928] sd 6:0:0:0: [sdb] Assuming drive cache: write through [ OK ] Started Show Plymouth Boot Screen. [ OK ] Reached target Paths. [ OK ] Reached target Basic System. [ OK ] Created slice system-checkisomd5.slice. Starting Media check on /dev/disk/by-label/Fedora-Live-WS-x86_64-23-10... /dev/disk/by-label/Fedora-Live-WS-x86_64-23-10: 7257a195598a8a30f8ac88997ef5b336 Fragment sums: b1d515eea7a1f9a26c89523a74d2a641f4482bf369da989779a9c73973aa Fragment count: 20 Supported ISO: no Press [Esc] to abort check. Checking 004.8% The media check is complete, the result is: FAIL. It is not recommended to use this media. [FAILED] Failed to start Media check on /dev/disk/by-label/Fedora-Live-WS-x86_64-23-10. See `systemctl status "checkisomd5@dev-disk-by\\x2dlabel-Fedora\\x2dLive\\x2dWS\\x2dx86_64\\x2d23\\x2d10.service"' for details. [ 6.226174] dracut-initqueue[517]: Job for checkisomd5@dev-disk-by\\x2dlabel-Fedora\\x2dLive\\x2dWS\\x2dx86_64\\x2d23\\x2d10.service failed because the control process exited with error code. See `systemctl status "checkisomd5@dev-disk-by\\x2dlabel-Fedora\\x2dLive\\x2dWS\\x2dx86_64\\x2d23\\x2d10.service"' and "journalctl-xe" for details. [ 6.246717] dracut: FATAL: CD check failed! [ 6.246761] dracut: Refusing to continue [ 6.357011] reboot: System halted _ Expected results: I would expect the testing process to end successfully and for it to boot into Fedora Live Additional info: I am using a SanDisk Cruzer Micro 16 GB USB flash drive. It was previously formatted to FAT. I have never had problems with the flash drive itself. I noticed what look like checksums in the error message. Before creating the bootable USB, I confirmed the checksums, so that cannot be the problem. Let me know if you need any additional information.