Bug 735035
| Summary: | Yum update on livecd runs out of snapshot space | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Piero Ottuzzi <ottuzzi> | ||||||
| Component: | kernel | Assignee: | Eric Sandeen <esandeen> | ||||||
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | unspecified | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 15 | CC: | gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda, ottuzzi, ovasik | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2011-09-07 14:15:55 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
Piero Ottuzzi
2011-09-01 08:59:30 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. do you have any messages from the kernel ? could you upload an image of the corrupted filesystem somewhere ? Hi, 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 Bye Piero > 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...
Thanks,
-Eric
Hi, 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 :) Bye Piero 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)
Hi, 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. Bye Piero (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 *** |