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
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.
FS is corrupted and you have non system anymore
FS should never corrupt
Very glad to answer as many question ase needed!
Thanks for your hard work!
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.
do you have any messages from the kernel ?
could you upload an image of the corrupted filesystem somewhere ?
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
> 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...
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 :)
Created attachment 521817 [details]
Buffer I/O error
This is what happens when the FS get compromised (part 1/2)
Created attachment 521818 [details]
EXT-4 fs error
This is what happens when the FS get compromised (part 2/2)
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.
(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 ***