Re: What do you do when your sid development system stops working?
On Sun, May 11, 2014 at 09:33:58PM -0500, Paul Elliott wrote:
> I like to do my packaging under sid, because
> that is where the packages will first have to run, so
> I can test them there.
>
> But what do you do when your sid system stop work
> after doing an apt-get dist-upgrade? X11 stopped working
> no screens found.
When running unstable, you really want some way to restore the system to a
working state quickly. Ie, backup with convenient means of restore,
preferably ones that work when the system became unbootable.
I'd heartily recommend a btrfs based scheme here. A traditional filesystem
plus a recovery partition can do the trick, but restore with a single
command is just too nifty to not have if, say, your X relies on nvidia
drivers[1], or some folks upload broken init systems that switch without
warning.
I for one use this set of subvolumes[1]:
boot /boot
sys-current /
home /home
In cron, there is:
btrfs subv snap sys-current sys-`date +%Y-%m-%d`
When shit happens, you snapshot sys-2001-09-10 back onto sys-current and
reboot. If the system is too broken to give you a shell, you append
"subvol=2001-09-10" to the kernel's cmdline in grub.
This way, you can use unstable without fear.
[1]. They stay broken for weeks whenever a new kernel comes, xorg gets a new
ABI, etc. But unlike nouveau, they don't crash on my box.
[2]. Plus "cache" for /var/cache, plus "kb-cache" for /home/kilobyte/.cache
(especially a big ccache), plus SSD/HDD micromanaging, plus tens of chroots,
etc, etc. I'd recommend these three for a start, though. And you must not
split /usr from /var /bin /sbin /lib /etc or you'll risk them going out of
sync.
--
Gnome 3, Windows 8, Slashdot Beta, now Firefox Ribbon^WAustralis. WTF is going
on with replacing usable interfaces with tabletized ones?
Reply to: