Bug 735035 - Yum update on livecd runs out of snapshot space
Summary: Yum update on livecd runs out of snapshot space
Status: CLOSED DUPLICATE of bug 490245
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 15
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Eric Sandeen
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2011-09-01 08:59 UTC by Piero Ottuzzi
Modified: 2011-09-07 14:15 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-09-07 14:15:55 UTC

Attachments (Terms of Use)
Buffer I/O error (711.21 KB, image/jpeg)
2011-09-07 08:32 UTC, Piero Ottuzzi
no flags Details
EXT-4 fs error (667.18 KB, image/jpeg)
2011-09-07 08:33 UTC, Piero Ottuzzi
no flags Details

Description Piero Ottuzzi 2011-09-01 08:59:30 UTC
Description of problem:
On F15 LXDE Live CD transposed on a USB key with LiveUSB Creator it is possible to corrupt the FS.

Version-Release number of selected component (if applicable):
F15 LXDE Live CD

How reproducible:

Steps to Reproduce:
1. Download F15 LXDE Live/Install CD
2. Use LiveUSB Creator to create a bootable USB key
3. change boot param LIVEIMG with LIVE_RAM
4. once logged in as root run "yum install gcc"
4a. you can see the same effect with "yum update glibc\*"
5. after yum updates glibc your FS is hosed.
Actual results:
FS is corrupted and you have non system anymore

Expected results:
FS should never corrupt

Additional info:
Very glad to answer as many question ase needed!

Thanks for your hard work!

Comment 1 Ondrej Vasik 2011-09-02 13:35:33 UTC
Thanks for the report. filesystem is just a package which owns/creates basic system directories. It has nothing to do with ext4. Reassigning to kernel.

Comment 2 Dave Jones 2011-09-02 16:27:05 UTC
do you have any messages from the kernel ?

could you upload an image of the corrupted filesystem somewhere ?

Comment 3 Piero Ottuzzi 2011-09-05 07:25:24 UTC

   as reported it is the corruption of a root FS loaded in RAM from a Live CD: I really do not know how to dump it (and the upload it) because once corrupted nothing is going to function properly.
I'll reproduce the problem later this morning and I'll let you know kernel messages I'll see.

See you later

Comment 4 Eric Sandeen 2011-09-06 18:50:22 UTC
> 5. after yum updates glibc your FS is hosed.

And how is this hose-ing detected?  oops? kernel message?  weird userspace results?  There's not a lot of info here yet, though I suppose more free time I could try the reproduction steps myself...


Comment 5 Piero Ottuzzi 2011-09-06 20:31:32 UTC

   sorry for the delay but after reproducing the FS crash many times before opening this issue, after your questions I was unable to reproduce the problem again.
Tomorrow I'll try again and if I will not see the problem I'll close this bug.
When I say the FS is corrupted I mean I cannot issue any command: after updating glibc I saw, on console, something related a problem with ext4 (I did not write exactly what was printed... stupid me) and after that nothing was working as expected.

I hope to have news soon... please be patient :)


Comment 6 Piero Ottuzzi 2011-09-07 08:32:39 UTC
Created attachment 521817 [details]
Buffer I/O error

This is what happens when the FS get compromised (part 1/2)

Comment 7 Piero Ottuzzi 2011-09-07 08:33:40 UTC
Created attachment 521818 [details]
EXT-4 fs error

This is what happens when the FS get compromised (part 2/2)

Comment 8 Piero Ottuzzi 2011-09-07 08:40:59 UTC

   this morning I reproduced the problem and here is the list of task:
1) do everything I said when I reported the issue
2) do some writing in root home dir or somewhere else mounted on /dev/mapper/live-rw (sometimes mkdir is enough sometimes write more data)
3) sync (not always needed)

After these steps you get what you see in the very unclear images attached... its is the picture of the top half and bottom half of the same screen. This is a RAM based filesystem (booted with live_ram param) and I can exlude a problem in system RAM as it is reproducible on at least 2 different systems.
I hope they are clear enough to show you the problem.


Comment 9 Eric Sandeen 2011-09-07 14:15:55 UTC
(In reply to comment #6)
> Created attachment 521817 [details]
> Buffer I/O error
> This is what happens when the FS get compromised (part 1/2)

device-mapper: snapshots: Invalidating snapshot: Unable [to allocate exception.]

So, the fs is not at fault here, the dm snapshot went away, and ext4 responded accordingly.

IOW, you ran out of snapshot space in the LIVE_RAM livecd environment.  I don't think it's a bug...

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

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