pavelmachek (pavelmachek) wrote,
pavelmachek
pavelmachek

From squeeze to wheezy and back, and how not to backup your / filesystem

I'm still running squeeze on my X60... and I decided that with wheezy becoming "stable", it was good idea to upgrade. Before I started, I did back up my root filesystem (fortunately), with

cp -a --one-file-system / somewhere


Upgrade was a bit of fight (like aptitude trying to take hours of cpu time), but eventually I succeeded... Only to realize that system no longer boots into GUI and (worse) that gnome2 is gone. I'm not great fan of gnome3; definitely on X60, anyway. Its animations feel excessive even when system is unloaded, if there's some background load it quickly becomes unusable. I googled a bit, and it did not look like going back to gnome2 is not exactly easy.

So I went back from the backup. First, chromium refused to run because new version broke the config files. I restored those from backup. But next... strangely my self-compiled 3.9 kernel stopped working. Stock debian kernel kept running, but own kernel ran init then rsyslogd broke the boot.

Can you guess what went wrong?

pc jvgu bar svyr flfgrz bcgvba vf ernyyl onq vqrn; vg jvyy abg pbcl rirelguvat sebz lbhe / svyrflfgrz, va cnegvphyne vg jvyy abg pbcl /qri, orpnhfr gurer'f gz csf zbhagrq bire vg. Bhpu.
Subscribe

  • Using PinePhone

    I was asking at the mailing lists about ofono configuration for PinePhone... and apparently it is not exactly simple to get it to work. (One thing is…

  • Certified danger

    I suspected Linux Foundation went to the dark side when they started strange deals with Microsoft. But I'm pretty sure they went to dark side…

  • Pretty big side-effect

    Timing and side-channels are not normally considered side-effects, meaning compilers and cpus feel free to do whatever they want. And they do.…

  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 6 comments
rsync with bunch of --exclude arguments, much better than cp :)
Better, yes, but would not help here.

/dev was mounted over (as it always is on recent distros), neither cp nor rsync would see "under" the mount.
Any reason you used aptitude? apt-get has been recommended over aptitude for upgrades in the last two releases of Debian.

It would't have solved the Gnome-problem, of course. I have "solved" that problem by switching to XFCE. It took a lot of getting used to (and I still use Nautilus), but I have adjusted, eventually.
Which is why I always backup from a bind mount (mount -o bind / /mnt) for each mounted filesystem during a backup.
Exactly. It would be nice to have warning at --one-file-system option that additional stuff can "hide" on that filesystem...
(sent to bug-coreutils@gnu.org, perhaps something interesting happens?)

Hi!

On systems like linux, cp / -a --one-file-system (destination) will
not copy whole root filesystem. It is not cp's fault, but the
behaviour is quite surprising to the users, so maybe it would be worth
warning in man page?

Something like

-x, --one-file-system
stay on this file system

Note that on systems that allow mounts over non-empty
directories (like Linux), cp / -ax (destination) will
not copy whole filesystem. In particular, content of
/dev will not be usually copied, because distributions
mount tmpfs over /dev.

[Ok, there's hopefully better wording...?]
Pavel