sf...@users.sourceforge.net wrote:
> bl4:
>> In /var, unmounting had no effect on results. When it failed after
>> remount -ro, it also failed after umount. Currently fsck after remount
>> -ro succeeds.
>
> Hmm, in my test environment, fsck after umount never fail. Even if you
> execute sync(8)
bl4:
> In /var, unmounting had no effect on results. When it failed after
> remount -ro, it also failed after umount. Currently fsck after remount
> -ro succeeds.
Hmm, in my test environment, fsck after umount never fail. Even if you
execute sync(8) and specify "sync,dirsync" mount options, fsc
sf...@users.sourceforge.net wrote:
> bl4:
>> Yes, /etc/default/auplink seems to fix it, not only with /var but with /
>> too. I didn't have to add sync. Which makes me wonder why, because I had
>> /etc/default/auplink all the time on my first virtual machine.
>
> Do you mean that you could succe
bl4:
> Yes, /etc/default/auplink seems to fix it, not only with /var but with /
> too. I didn't have to add sync. Which makes me wonder why, because I had
> /etc/default/auplink all the time on my first virtual machine.
Do you mean that you could succeed fsck BEFORE unmounting?
I think the caus
sf...@users.sourceforge.net wrote:
>> bl4:
>>> For testing, /var can be put on a separate partition and mounted as
>>> aufs. It is always written to and it can be unmounted on shutdown.
>> :::
By the way, I could not find /etc/default/auplink. So I had to create it
manually.
>>> Doe
> bl4:
> > For testing, /var can be put on a separate partition and mounted as
> > aufs. It is always written to and it can be unmounted on shutdown.
> :::
> > > By the way, I could not find /etc/default/auplink. So I had to create it
> > > manually.
> >
> > Does it matter if the scripts ca
bl4:
> For testing, /var can be put on a separate partition and mounted as
> aufs. It is always written to and it can be unmounted on shutdown.
:::
> > By the way, I could not find /etc/default/auplink. So I had to create it
> > manually.
>
> Does it matter if the scripts call auplink man
sf...@users.sourceforge.net wrote:
Here is my current guess.
- qemu or linux-2.6.26 may NOT flush ext2/3 at remounting readonly, but
they may flush at unmounting time.
- your /dev/hda1 is not unmounted. it is remounted ro at shutdown time
too.
- contrastingly /dev/hdb can be unmounted, and it
bl4:
> When it's ready I will send all info in a separate email.
Thanx.
I could reproduce the problem.
But still I am unsure whether the problem is in aufs or not.
So I tried it on /dev/hdb which is a small ext2 image.
$ dd if=/dev/zero of=hdb bs=32M count=1
$ mkfs -t ext2 -q -F hdb
$ qemu -hda
bl4:
> Interesting, if not aufs then what?
>
> Firstly, I can prove it this way: There are two identical copies of root
> partition. Both are mounted read-only in initramfs. One of them becomes
> a branch of aufs. On shutdown, I rsync changes to both copies and only
> the one under control of a
sf...@users.sourceforge.net wrote:
>>> And your log shows
[ 241.753731] EXT2-fs warning: mounting unchecked fs, running e2fsck is
recommended
>>> I am afraid your "mount -o remount,ro /ro" didn't work.
>>> can you check it by /proc/mounts or something?
>> But remount read-only doesn't o
bl4:
> These two logs which you refer to were produced at different times. I'm
> attaching once again outputs of dmesg and fsck from one shutdown procedure.
Oh, different logs!
It had to be wast of time.
> > And your log shows
> >> [ 241.753731] EXT2-fs warning: mounting unchecked fs, running
sf...@users.sourceforge.net wrote:
These "dirtied inode" messages are correct and showed those write are
done expectedly.
Accroding to your full log, I can see several "?" as a filename. They
may be replaced files by rsync. For instance,
[ 269.279952] rsync(2436): dirtied inode 320026
bl4:
> If there were any write operations by other processes during this time,
> they should be listed in dmesg, but there were none.
Ok.
> Then I did:
> echo 1 > /proc/sys/vm/block_dump
> mount -o remount,rw /ro
> rsync --exclude=".wh.*" --exclude=lost+found -aHSx --devices --specials
> /rw/
sf...@users.sourceforge.net wrote:
How about other processes?
Are there any other process which writes to /, /rw or /ro?
Does your rsync write any log to somewhere in aufs?
This script is positioned after umountfs, before umountroot and halt. I
think it's unlikely that any other processes a
bl4:
> Actually the find+rm should not modify /rw because the sed changes all
> paths from /rw to /ro. The purpose of this script is to preserve all
> changes (including removals) after reboot. Anyway, when I run rsync
> only, I also get these errors.
I see.
> > When you restore the find+rm,
Thanks for your reply.
sf...@users.sourceforge.net wrote:
> bl4:
>> And there is a script /etc/init.d/aufs-sync called at shutdown:
>> fsck -nf /dev/hda1
>> mount -o remount,rw /ro
>> rsync --exclude=".wh.*" --exclude=lost+found -aHSx --devices --specials
>> /rw/ /ro/
>> cd /rw
>> find . -name "
Hello bl4,
bl4:
> And there is a script /etc/init.d/aufs-sync called at shutdown:
> fsck -nf /dev/hda1
> mount -o remount,rw /ro
> rsync --exclude=".wh.*" --exclude=lost+found -aHSx --devices --specials
> /rw/ /ro/
> cd /rw
> find . -name ".wh.*" -and -not -name ".wh..wh.*" | sed 's/^\.\//\/ro\/
Hi
I have Debian Lenny (kernel 2.6.26) with aufs 20080719. Root filesystem
is mounted as aufs.
This is more or less what happens in initramfs:
mount -t ext3 -o ro /dev/hda1 /ro
mount -t tmpfs none /rw
mount -t aufs -o dirs=/rw=rw:/ro=ro none /root
mount --move /ro /root/ro
mount --move /rw /roo
19 matches
Mail list logo
