Bug 682597 - fedora on USB flash drive is broken on update
Summary: fedora on USB flash drive is broken on update
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: device-mapper
Version: 14
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Orphan Owner
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-03-07 00:39 UTC by Account closed by user
Modified: 2013-01-10 06:30 UTC (History)
9 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2011-07-02 10:19:19 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
call trace - top (3.74 MB, image/jpeg)
2011-03-07 18:19 UTC, Account closed by user
no flags Details
call trace - half left (4.05 MB, image/jpeg)
2011-03-07 18:21 UTC, Account closed by user
no flags Details
call trace - half right (4.08 MB, image/jpeg)
2011-03-07 18:24 UTC, Account closed by user
no flags Details
call trace - half bottom (3.51 MB, image/jpeg)
2011-03-07 18:25 UTC, Account closed by user
no flags Details

Description Account closed by user 2011-03-07 00:39:36 UTC
- put Fedora-14-i686-Live-Desktop.iso in a USB flash drive with liveusb-creator-3.9.3-1.fc14.noarch
- boot from it
- yum -y update
- wait, wait, ...
- crash

[...]
rpmdb: fsync: Input/output error
rpmdb: fsync: Input/output error
[...]

tested with 2 different usb devices:

- OCZ_Rally2_Turbo 4G http://www.ocztechnology.com/ocz-rally2-turbo-usb-2-0-flash-drive-eol.html

- Pico_C 8G http://www.supertalent.com/products/stt_usb_detail.php?type=Pico

something wrong in any file system squash, ext4 ...

Comment 1 Account closed by user 2011-03-07 18:13:02 UTC
 
Upper test was done in a ACER Aspire M1640(workstation).

Redone on a Lenovo ThinkPad T61(laptop) with OCZ_Rally2_Turbo 4G. And it is broken again.

photos attached.

Comment 2 Account closed by user 2011-03-07 18:19:44 UTC
Created attachment 482759 [details]
call trace - top

Comment 3 Account closed by user 2011-03-07 18:21:59 UTC
Created attachment 482760 [details]
call trace - half left

Comment 4 Account closed by user 2011-03-07 18:24:15 UTC
Created attachment 482761 [details]
call trace - half right

Comment 5 Account closed by user 2011-03-07 18:25:59 UTC
Created attachment 482762 [details]
call trace - half bottom

Comment 6 Brian Lane 2011-04-11 16:49:55 UTC
The livecd isn't meant to be updated like this. It uses an overlay system to handle file changes. When this overlay runs out of space it fails and doesn't handle that gracefully. I am not sure if there is anything that we can do to avoid this, but I'll reassign to device-mapper and see what they say.

Either way, I wouldn't expect to be able to run yum update on a live system.

Comment 7 Account closed by user 2011-05-18 00:19:33 UTC
(In reply to comment #6)

> The livecd isn't meant to be updated like this. It uses an overlay system to
> handle file changes. When this overlay runs out of space it fails and doesn't
> handle that gracefully. I am not sure if there is anything that we can do to
> avoid this, but I'll reassign to device-mapper and see what they say.
> 
> Either way, I wouldn't expect to be able to run yum update on a live system.

I did the test again, this time with a USB-hard_drive and the underlying fs was EXT4 instead vfat. And ALL went OK..

space on /, aka /dev/mapper/live-rw, was never full.


Note You need to log in before you can comment on or make changes to this bug.