Red Hat Bugzilla – Bug 499149
Fedora 11 Preview LiveCD won't boot from USB stick (ext4_find_entry errors)
Last modified: 2013-01-10 00:12:06 EST
Description of problem:
Fedora 11 Preview LiveCD doesn't boot from USB stick.
Version-Release number of selected component (if applicable):
Official preview LiveCD.
Steps to Reproduce:
1. boot from USB LiveCD
Graphical splash screen appears with countdown message. After that, screen switches to text mode, and the progress bar appears at the bottom. During boot a couple of messages like this
EXT4-fs error (device dm-0): ext4_find_entry: reading directory #30238 offset 0
appear, but progress bar continues until it's completely white. After this, boot doesn't proceed, and USB led keeps blinking repeatedly, indicating activity. Pressing one of the arrow keys shows another screen where the same messages are printed continuously:
sd 8:0:0:0:0: [sdb] assuming drive cache write through
sd 8:0:0:0:0: [sdb] Write protect is off
Fedora 11 would boot.
Fedora 11 Beta LiveCD has been tested on the same USB stick and booted without a problem.
Can you verify the files written to the usb stick match (you can loopback mount the iso and then compare with sha1sum LiveOS/squashfs.img)? This looks like either a bad write or possibly a dying usb stick
Hi Jeremy, sorry for not replying sooner.
Unfortunately, it's not media related AFAICS, sha1sum is the same for both files:
~ sha1sum squashfs.img /media/COSTA\ DRIVE/LiveOS/squashfs.img
948503307b9135521ae2f243ea5e1104ed79f604 /media/COSTA DRIVE/LiveOS/squashfs.img
~ df .
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/loop0 665142 665142 0 100% /tmp/f11
I just saw the same thing on an acer aspire one d150. Verified sha1sum of squashfs.img as well, all is fine.
When I am home later I'll upload a photo of the screen
Created attachment 343504 [details]
F11 preview live image failing to boot on Acer Aspire One D150
USB key was created on F-10 using livecd-iso-to-disk as detailed here:
Should probably run e2fsck on the ext4 image, wherever it's hiding inside the squashfs image?
(In reply to comment #6)
> Should probably run e2fsck on the ext4 image, wherever it's hiding inside the
> squashfs image?
I could try that. Should I expect the e2fsck from F-10 to be ext4 capabale? Also, is the version of squashfs used for the F11 images compatible with the F-10 kernel? If I need an F-11 install to do that... well, it's a bit chicken and egg :)
(In reply to comment #7)
> I could try that. Should I expect the e2fsck from F-10 to be ext4 capabale?
should be, though not totally uptodate. Temporarily installing rawhide's (or koji's?) e2fsprogs might be nice:
> Also, is the version of squashfs used for the F11 images compatible with the
> F-10 kernel? If I need an F-11 install to do that... well, it's a bit chicken
> and egg :)
heh, it may not be, not sure.
(In reply to comment #8)
> > Also, is the version of squashfs used for the F11 images compatible with the
> > F-10 kernel? If I need an F-11 install to do that... well, it's a bit chicken
> > and egg :)
> heh, it may not be, not sure.
It seems not to be:
# mount -t squashfs -o loop squashfs.img /mnt
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
What is a bit perplexing about this is, if it was a corrupt squasfs that was the problem, then noone could install the preview release... and yet (presumably) people are... When I get a bit of time later, i'll try installing to a virtual machine.
Hm, interesting data point. For shits and giggles I tried the KDE spin prerelease, and that boots fine.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.
More information and reason for this action is here:
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '11'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 11's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 11 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.