Red Hat Bugzilla – Bug 542644
guestfish sets filesystem mount time in the "future", guest reports inconsistency at next boot
Last modified: 2013-06-17 00:07:06 EDT
Created attachment 374741 [details]
guest vm booting into maintenance mode
Description of problem:
vm boots into maintenance shell after accessing files from guest disk image (debian gnu/linux sid). It is very much possible that it be an issue with time zones.
Verified date -u is same in both guest and host.
Version-Release number of selected component (if applicable):
always (reproduced twice).
Steps to Reproduce:
1. mount any disk image
2. mount a partition, download some files
3. exit from shell (umount before exiting does not make any difference)
guest vm boots into maintenance mode because the disk is corrupted (only superblock last mount time is in future)
vm runs normally
Created attachment 374743 [details]
fsck inside guest vm
only last mount time needs to be corrected.
(In reply to comment #0)
> 1. mount any disk image
> 2. mount a partition, download some files
> 3. exit from shell (umount before exiting does not make any difference)
This is in guestfish or guestmount? Can you show the exact
sequence of commands that you used? Did you use the --ro option?
Also, was the guest running at the time?
It's unsafe to use libguestfs commands on a running guest,
unless you use the --ro option.
the guest was not running
guestfish -a debian-gnu-linux.img
mount /dev/sda1 /
download /home/pravi/Desktop/some-file.png some-file.png
boot guest vm
I get the message like in the screenshot
I'm inclined to think this is an edge case in
util-linux-ng or e2fsprogs.
See this recent Debian bug report:
The problem in the ^^ report is that the timezone
wasn't being set before the fsck starts. Our case is
slightly different: the appliance clock will always be
on UTC, and so in most cases it will always be different
from the guest's clock when it next boots, so for one
whole hemisphere of the earth they'll always get this
problem after booting.
I'm wondering what the purpose of the error is anyway.
Why does it matter if the superblock last mount/write
time is in the future?
(CC to Eric Sandeen).
Eric, any ideas about comment 6?
Here's another bug that seems related: bug 522969.
cat >> /etc/e2fsck.conf
in guest/debian ignores the last mount time in future error.
Yeah, TBH I don't know why it drops to a full fsck for this; for what it's worth, upstream now accepts up to a 24h discrepancy w/o causing this:
Just to be sure I'm not confused; this is e2fsprogs within the debian image that's finding this error? I guess if so it's not a Red Hat e2fsprogs bug, right?
The workaround in comment #9 should be reasonable in that case.
Yes. The guest is debian gnu/linux and this error is caused by its e2fsprogs. It is not a Red Hat e2fsprogs bug. As mentioned in comment #9, it goes away after adding this option (buggy_init_scripts=1).
But it would be ideal for libguestfs not to update last mount time. It can cause problems with other guest os.
other guest os = windows/non-gnu-linux
i was hitted by this bug on (real) fedora 12, after setting the wrong date in bios: 05/02/2010 instead of 02/05/2010. imho it should just get over it and boot normally.
We think the following patch should fix this:
Fixed in version 1.2.2.
thank you very much.