I cannot find how it might be related, but we are seeing massive filesystem
corruptions in virtual guests on kvm in Lucid.
Host was running several kernels, from stock Lucid up to 3.0.0-14-server.
Guests were booted with several different kernels as well. We also changed
storag backen form
I too have experienced disk corruption following suspend to ram, which I
use on my NAS storage server in conjunction with PowerNap. I have
observed this working in both Lucid and Natty over the last year. In my
experience, this problem is not limited to external drives. I have
observed
Seeing this exact problem in Ocelot. The filesystem on the external
storage device is extremely upset that the device was ripped out from
under it, and wasn't there yet (due to delay in the drive spinning up /
enumerating) when the system was resumed. The system needs to delay
suspending until all
Seeing this exact problem in Ocelot. The filesystem on the external
storage device is extremely upset that the device was ripped out from
under it, and wasn't there yet (due to delay in the drive spinning up /
enumerating) when the system was resumed. The system needs to delay
suspending until all
Any chance this might be related to disk image corruption issues when
running Hardy in VmWare Fusion?
I have lost numerous VmWare Fusion images with what seems to be a
similar problem. Typically in the middle of a large project build,
everything will come to a grinding halt with (something like)
Most comments here allude to the FS not being sync-ed; however
/usr/lib/pm-utils/bin/pm-action (pm-suspend) in pm-utils does sync. I'm
reassigning to pm-utils for now, but I rather suspect that this is a
driver/hardware issue as we got a relatively low number of such reports.
These logs also
** Changed in: acpid (Ubuntu)
Importance: Undecided = Low
Status: New = Confirmed
--
suspend and hibernate may cause data corruption because it doesn't syncs nor
umounts external drives previously
https://bugs.launchpad.net/bugs/198125
You received this bug notification because you
I've found a workaround for this problem by passing the iommu=soft to the
kernel!!! Amazing, everything works!
it is something that has to do with AMD iommu module and kernel
incompatibilities.
--
suspend and hibernate may cause data corruption because it doesn't syncs nor
umounts external
Confirmed on an ACER Ferrari 5000 with Hardy. Suspend does suspend the machine
properly; however, upon resume it fails--the screen stays blank and a hard
power off is required to reboot. Upon normal reboot I receive a GRUB error 17,
indicative of a file system corruption. Even after an
Probably related to bug:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/203537
Does this bug still exist on release Hardy?
If so this is *VERY* dangerous people
--
suspend and hibernate may cause data corruption because it doesn't syncs nor
umounts external drives previously
It is still not fixed.
Removable media is mounted asynchronous and there is no sign of any
attempt to umount/remount it upon suspend/resume.
--
suspend and hibernate may cause data corruption because it doesn't syncs nor
umounts external drives previously
https://bugs.launchpad.net/bugs/198125
This is a serious problem, and it applies to the internal disks as well.
I am using JFS on LVM and have been testing suspend-to-RAM lately.
Every time it failed, I ended up with really bad disk corruption (often
couldn't boot or couldn't touch /forcefsck).
Puhleeeze fix it. The cost is so low
Please, it's getting worse and worse ! Last day, I noticed my externel
hard drive was mounted to /media/WD Passport and there was three
empty folders starting with WD Passport. All my bookmarks are disabled
and rhythmbox can't find my music.
Also, I don't understand why there aren't more
This bug may be related to bug #108854.
I said there :
Hardy amd64 on a Lenovo 3000 N200 laptop (Core 2 Duo)
My external hard disks aren't switched off either.
What is more problematic to me is that they seem not to be unmounted, so
when I unplugged a drive before resume, there still was its
Given the I/O errors reported by the user, the filesystem was probably
very badly damanged before the power loss event. Normally ext3 recovers
from power failures without a hitch. Enabling laptop mode may increase
the amount of files whose data might be lost, but power failures will
not result
I assume that a 500 GB drive has a wall-wart for power. Loss of power
to the drive with the laptop still running could be problematic. I'm
going to plug mine into a spare UPS that I have lying around. You can
track the problems by following the timestamp in the syslog file from
when you booted
16 matches
Mail list logo