Login | Register
My pages Projects Community openCollabNet

Discussions > users > Question on revert

fsvs
Discussion topic

Hide all messages in topic

All messages in topic

Re: Question on revert

Author pmarek
Full name P.Marek
Date 2007-07-23 02:14:58 PDT
Message Hello Simon!

Simon Sprünker wrote:
> Before that command, the permissions for / were drwx------. So recursive
> revert seems to set at least these permissions wrong.
I know that there are problems regarding the root node; subversion does
not send properties for it.

I'm already on the ball; but currently I couldn't find a nice solution.


Thank you for your reminder, though!


Regards,

Phil


--
Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!

Re: Question on revert

Author =?UTF-8?B?U2ltb24gU3Byw7xua2Vy?= <fsvs at semjon dot de>
Full name =?UTF-8?B?U2ltb24gU3Byw7xua2Vy?= <fsvs at semjon dot de>
Date 2007-07-21 14:46:02 PDT
Message Simon Sprünker wrote:
> Hi,
>
> I ran into a problem using the recursive revert using fsvs 1.1.6 (did
> not try with older versions):
>
> I am versioning / on a machine. I uninstalled htop and deleted
> /var/spool/fsvs and /etc/fsvs. Then I did
>
> [HEAD]vm-one:/# fsvs sync-repos
> [HEAD]vm-one:/# fsvs revert -R /

Hi Phil,

short followup on this matter. With your new FSVS version (r980), I did
the above, which worked fine, but then I did my usual stuff and noticed
the following:

[HEAD]vm-one:~# sudo
sudo: can't open /etc/sudoers: Permission denied

FSVS did not change anything related to sudo and it did work before the
revert, so I googled and found something to fix it:

[HEAD]vm-one:~# chmod 755 /

Before that command, the permissions for / were drwx------. So recursive
revert seems to set at least these permissions wrong.

Simon

Re: Question on revert

Author =?UTF-8?B?U2ltb24gU3Byw7xua2Vy?= <fsvs at semjon dot de>
Full name =?UTF-8?B?U2ltb24gU3Byw7xua2Vy?= <fsvs at semjon dot de>
Date 2007-07-21 13:44:07 PDT
Message Ph. Marek wrote:
> Hmmm .. I cannot check ATM, but it's possibly there's a bug related to
> un-removing a directory.
>
> I'll take a look, but that can take a few days until I find time.

Hi Phil,

it's working now! Thank you very much!

Simon

Re: Question on revert

Author pmarek
Full name P.Marek
Date 2007-07-18 09:30:42 PDT
Message Hello Simon,

> Wow, that was fast! I'll try it out, thank you.
please wait until tomorrow, when it's checked in :-)


--
Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!

Re: Question on revert

Author pmarek
Full name P.Marek
Date 2007-07-17 01:32:17 PDT
Message Hello Simon!


> [HEAD]vm-one:/# fsvs sync-repos
> ...
> [HEAD]vm-one:/# fsvs st
> .m.? 0 ./var/lib/apt/lists/lock
> .m.? 6822306 ./var/cache/apt/pkgcache.bin
> D... 0 ./usr/bin/htop
> D... 0 ./usr/share/man/man1/htop.1.gz
> D... dir ./usr/share/doc/htop
> D... 0 ./usr/share/doc/htop/AUTHORS
> D... 0 ./usr/share/doc/htop​/changelog.gz
> D... 0 ./usr/share/doc/htop​/changelog.Debian.gz​
> D... 0 ./usr/share/doc/htop/copyright
> D... 0 ./usr/share/doc/htop/README
> D... 0 ./usr/share/pixmaps/htop.png
> D... 0 ./var/lib/dpkg/info/​htop.postinst
> D... 0 ./var/lib/dpkg/info/​htop.md5sums
> D... 0 ./usr/share/menu/htop
> .m.? 4096 ./var/lib/urandom/random-seed
> .m.? 218355 ./var/lib/dpkg/available-old
> .m.? 218355 ./var/lib/dpkg/available
> .m.? 0 ./var/lib/dpkg/info/htop.list
> .m.? 240354 ./var/lib/dpkg/status
> .m.? 0 ./var/lock/aptitude
> .m.? 240325 ./var/lib/dpkg/status-old
> ..C. dir ./usr/share/pixmaps
> .m.? 0 ./var/lib/dpkg/lock
> ..C. dir ./usr/share/menu
> ..C. dir ./usr/bin
> ..C. dir ./usr/share/man/man1
> .m.? 1668428 ./var/lib/aptitude/p​kgstates.old
> .m.? 1668428 ./var/lib/aptitude/pkgstates
> .m.? 19463 ./var/lib/exim4/conf​ig.autogenerated
> .m.? 4 ./var/lib/nfs/state
> .m.? 45 ./etc/resolv.conf
> .m.? 16 ./etc/network/run/ifstate
> D... 0 ./usr/share/applicat​ions/htop.desktop
> .m.? 349 ./etc/mtab
> ..C. dir ./usr/share/applications
> ..C. dir ./var/lib/dpkg/info
> ..C. dir ./usr/share/doc
> .m.? 0 ./root/.aptitude/config
> .m.? 0 ./lib/init/rw/.ramfs
> .m.. dir .
So, some changes here.

> [HEAD]vm-one:/# fsvs revert -R -C /
> Reverting to revision 5:
> .m.. 0 ./var/lib/apt/lists/lock
> .mC. 6822306 ./var/cache/apt/pkgcache.bin
> D... 73252 ./usr/bin/htop
> D... 1707 ./usr/share/man/man1/htop.1.gz
>
> Warning [id=chown-other, action=stop]:
> Cannot chown "./usr/share/doc/htop" to 0:0
Hmmm .. I cannot check ATM, but it's possibly there's a bug related to
un-removing a directory.

I'll take a look, but that can take a few days until I find time.


> I am not sure, if I understood you correctly: Should the way I tried
> work? I would like that, because it means less work and that I don't
> need physical access to the machine that broke, once the minimal system
> is running :)
It should work, I just wanted to post an outline how it *could* work - ie.
how the recovery should be possible.


Regards,

Phil


--
Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!

Re: Question on revert

Author =?UTF-8?B?U2ltb24gU3Byw7xua2Vy?= <fsvs at semjon dot de>
Full name =?UTF-8?B?U2ltb24gU3Byw7xua2Vy?= <fsvs at semjon dot de>
Date 2007-07-16 18:37:14 PDT
Message Hello Phil,

thanks for your quick and extensive answer (as always)!

Philipp Marek wrote:
> Hello Simon!
>
>
> On Montag, 16. Juli 2007 Simon Sprünker wrote:
>> I ran into a problem using the recursive revert using fsvs 1.1.6 (did
>> not try with older versions):
>>
>> I am versioning / on a machine. I uninstalled htop
> but didn't commit, I think?

Correct.

>> and deleted
>> /var/spool/fsvs and /etc/fsvs.
> Why did you that? To simulate a catastrophic recovery?

Exactly.

> What does "fsvs st" say, just after the "sync-repos"?
> Please try a "fsvs revert -R -C" - the "-C" tells fsvs to check *all*
> directories for missing elements. The sync-repos is not perfect yet, in that
> it (has to) take the current timestamps ... But there I could verify
> something; that's possibly fixed by taking the ctime as a hint only.

[HEAD]vm-one:/# fsvs sync-repos
...
[HEAD]vm-one:/# fsvs st
.m.? 0 ./var/lib/apt/lists/lock
.m.? 6822306 ./var/cache/apt/pkgcache.bin
D... 0 ./usr/bin/htop
D... 0 ./usr/share/man/man1/htop.1.gz
D... dir ./usr/share/doc/htop
D... 0 ./usr/share/doc/htop/AUTHORS
D... 0 ./usr/share/doc/htop​/changelog.gz
D... 0 ./usr/share/doc/htop​/changelog.Debian.gz​
D... 0 ./usr/share/doc/htop/copyright
D... 0 ./usr/share/doc/htop/README
D... 0 ./usr/share/pixmaps/htop.png
D... 0 ./var/lib/dpkg/info/​htop.postinst
D... 0 ./var/lib/dpkg/info/​htop.md5sums
D... 0 ./usr/share/menu/htop
.m.? 4096 ./var/lib/urandom/random-seed
.m.? 218355 ./var/lib/dpkg/available-old
.m.? 218355 ./var/lib/dpkg/available
.m.? 0 ./var/lib/dpkg/info/htop.list
.m.? 240354 ./var/lib/dpkg/status
.m.? 0 ./var/lock/aptitude
.m.? 240325 ./var/lib/dpkg/status-old
..C. dir ./usr/share/pixmaps
.m.? 0 ./var/lib/dpkg/lock
..C. dir ./usr/share/menu
..C. dir ./usr/bin
..C. dir ./usr/share/man/man1
.m.? 1668428 ./var/lib/aptitude/p​kgstates.old
.m.? 1668428 ./var/lib/aptitude/pkgstates
.m.? 19463 ./var/lib/exim4/conf​ig.autogenerated
.m.? 4 ./var/lib/nfs/state
.m.? 45 ./etc/resolv.conf
.m.? 16 ./etc/network/run/ifstate
D... 0 ./usr/share/applicat​ions/htop.desktop
.m.? 349 ./etc/mtab
..C. dir ./usr/share/applications
..C. dir ./var/lib/dpkg/info
..C. dir ./usr/share/doc
.m.? 0 ./root/.aptitude/config
.m.? 0 ./lib/init/rw/.ramfs
.m.. dir .

[HEAD]vm-one:/# fsvs revert -R -C /
Reverting to revision 5:
.m.. 0 ./var/lib/apt/lists/lock
.mC. 6822306 ./var/cache/apt/pkgcache.bin
D... 73252 ./usr/bin/htop
D... 1707 ./usr/share/man/man1/htop.1.gz

Warning [id=chown-other, action=stop]:
Cannot chown "./usr/share/doc/htop" to 0:0



An error occurred: No such file or directory (2)
   in up__set_meta_data

If you need anything else, I will be happy to provide it.

>> You may ask, why I did the above steps. I did not find anything in docs
>> on how to achieve the following use case: You version a machine, it
>> breaks, you install a minimial system and update to the latest revision
>> in the repository. I thought the above steps simulate this process.
> Well, I'd have recommended doing something like
> - Booting with a knoppix or similar
> - Make fsvs available (will get easier as soon as distributions include it)
> - Go to your harddisk-root (here taken as /mnt)
> cd /mnt
> - Do
> fsvs export $URL
> that restores your machine (or at least should); optionally use -rREV.
> - Call "lilo", "grub-install" or whatever
> - Reboot into the machine.
> - Now all you have to do is restore the FSVS' filelist:
> cd /
> fsvs sync-repos

I am not sure, if I understood you correctly: Should the way I tried
work? I would like that, because it means less work and that I don't
need physical access to the machine that broke, once the minimal system
is running :)

Best Regards,
Simon

Re: Question on revert

Author pmarek
Full name P.Marek
Date 2007-07-16 04:33:11 PDT
Message Hello Simon!


On Montag, 16. Juli 2007 Simon Sprünker wrote:
> I ran into a problem using the recursive revert using fsvs 1.1.6 (did
> not try with older versions):
>
> I am versioning / on a machine. I uninstalled htop
but didn't commit, I think?
> and deleted
> /var/spool/fsvs and /etc/fsvs.
Why did you that? To simulate a catastrophic recovery?

> Then I did
>
> [HEAD]vm-one:/# fsvs sync-repos
Yes, that should restore the needed filelist.

> [HEAD]vm-one:/# fsvs revert -R /
> Reverting to revision 5:
> .m.? 0 ./var/lib/apt/lists/lock
> D... 73252 ./usr/bin/htop
> D... 1707 ./usr/share/man/man1/htop.1.gz
>
> Warning [id=chown-other, action=stop]:
> Cannot chown "./usr/share/doc/htop" to 0:0
>
> An error occurred: No such file or directory (2)
> in up__set_meta_data
What does "fsvs st" say, just after the "sync-repos"?
Please try a "fsvs revert -R -C" - the "-C" tells fsvs to check *all*
directories for missing elements. The sync-repos is not perfect yet, in that
it (has to) take the current timestamps ... But there I could verify
something; that's possibly fixed by taking the ctime as a hint only.

> You may ask, why I did the above steps. I did not find anything in docs
> on how to achieve the following use case: You version a machine, it
> breaks, you install a minimial system and update to the latest revision
> in the repository. I thought the above steps simulate this process.
Well, I'd have recommended doing something like
- Booting with a knoppix or similar
- Make fsvs available (will get easier as soon as distributions include it)
- Go to your harddisk-root (here taken as /mnt)
    cd /mnt
- Do
    fsvs export $URL
  that restores your machine (or at least should); optionally use -rREV.
- Call "lilo", "grub-install" or whatever
- Reboot into the machine.
- Now all you have to do is restore the FSVS' filelist:
    cd /
    fsvs sync-repos


I didn't take the time yet, but there should be a "--chroot" parameter for
commands, that would simply go
  fsvs urls --chroot /mnt $URL
  fsvs update --chroot /mnt
and restore the file list and other settings in a single step - by knowing
that /mnt will be the new root.
Currently that doesn't work, because the path is taken to distinguish working
copies - and "/mnt" != "/".
Maybe I'll put that into a single command, "fsvs restore" or something like
that.


> My ignores do not cover ./usr/share/doc/htop.
>
> Did I mess up? Is there a better way to do what I want?
Well, you see how it *should* work ... But I have to admit that I didn't try
the catastrophic recovery yet, only simple mess-ups.


Regards,

Phil


--
Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!

Question on revert

Author =?UTF-8?B?U2ltb24gU3Byw7xua2Vy?= <fsvs at semjon dot de>
Full name =?UTF-8?B?U2ltb24gU3Byw7xua2Vy?= <fsvs at semjon dot de>
Date 2007-07-15 16:42:41 PDT
Message Hi,

I ran into a problem using the recursive revert using fsvs 1.1.6 (did
not try with older versions):

I am versioning / on a machine. I uninstalled htop and deleted
/var/spool/fsvs and /etc/fsvs. Then I did

[HEAD]vm-one:/# fsvs sync-repos
[HEAD]vm-one:/# fsvs revert -R /
Reverting to revision 5:
.m.? 0 ./var/lib/apt/lists/lock
D... 73252 ./usr/bin/htop
D... 1707 ./usr/share/man/man1/htop.1.gz

Warning [id=chown-other, action=stop]:
Cannot chown "./usr/share/doc/htop" to 0:0



An error occurred: No such file or directory (2)
   in up__set_meta_data

You may ask, why I did the above steps. I did not find anything in docs
on how to achieve the following use case: You version a machine, it
breaks, you install a minimial system and update to the latest revision
in the repository. I thought the above steps simulate this process.

My ignores do not cover ./usr/share/doc/htop.

Did I mess up? Is there a better way to do what I want?

Best Regards,
Simon
Messages per page: