Re: a cautionary tale w/ successful recovery
Paul E Condon mesanetworks.net> writes: > My suggestion is: > > # aptitude -F "%p %M" search '~i' |tr -s ' '|sed 's/ A$/+M/' > package-list > > followed by (without change except for fixing the missing "k" > > # aptitude install $(cat package-list) > > I haven't actually tested this. It is just what I think would work > from reading the aptitude documentation. By later today I may be able > to do some tests without trashing one of my systems. The theory is [...] > > Question: Where would be a good place for the file, package-list, > within the Debian way? In /etc/apt/ ? Or /var/backups/ ? Elsewhere? I think it should go in /etc/apt. Also, Aptitude should save an up-to-date copy of the file every time you run an "aptitude install" or "aptitude upgrade" command. It would be wonderful if someone could test that: it'd be difficult for me to test, so I don't volunteer. And then if someone could file a feature request against aptitude asking them to implement this, or better yet, write a patch. -Jason -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: a cautionary tale w/ successful recovery
On 20091103_114547, Boyd Stephen Smith Jr. wrote: > On Tuesday 03 November 2009 10:38:41 Johannes Wiedersich wrote: > > Andrew Sackville-West wrote: > > > On Sun, Nov 01, 2009 at 07:08:00PM -0500, Andrew Reid wrote: > > >> For the sysems I back up at work, we do the dpkg --get-selections > > >> thing, but I've never kept a copy of the boot sector -- that's an > > >> excellent idea. > > > > I guess the 'state of the art' way of recording a list of installed > > packages, nowadays is > > > > # aptitude -F "%p" search '~i!~M' > package-list > > > > You can then just install like > > > > # aptitude install $(cat pacage-list) > > > > dpkg --get-selections does not distinguish between packages installed > > manually or automatically, so that information is lost on the reinstall. > > The search pattern just looks for packages that were installed > > manually. The install will automatically install all dependencies. > > However, because of OR dependencies (i.e. using the '|' character), it might > install *different* packages to satisfy dependencies. Your saved > configuration files won't work with those packages. > > Some combination of dpkg --get-selections and aptitude search '~M' should be > able to save both "all installed packages" and "all automatically installed > packages", and some combination of dpkg --set-selections, aptitude markauto, > and aptitude install should be able to restore them. My suggestion is: # aptitude -F "%p %M" search '~i' |tr -s ' '|sed 's/ A$/+M/' > package-list followed by (without change except for fixing the missing "k" ;-) # aptitude install $(cat package-list) I haven't actually tested this. It is just what I think would work from reading the aptitude documentation. By later today I may be able to do some tests without trashing one of my systems. The theory is that aptitude install understands that appending '+M' to a package name is an indication that it is to mark the package as having been installed to satisfy a dependency. The rest of the magic incantation follows. Question: Where would be a good place for the file, package-list, within the Debian way? In /etc/apt/ ? Or /var/backups/ ? Elsewhere? -- Paul E Condon pecon...@mesanetworks.net -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: a cautionary tale w/ successful recovery
On Tuesday 03 November 2009 10:38:41 Johannes Wiedersich wrote: > Andrew Sackville-West wrote: > > On Sun, Nov 01, 2009 at 07:08:00PM -0500, Andrew Reid wrote: > >> For the sysems I back up at work, we do the dpkg --get-selections > >> thing, but I've never kept a copy of the boot sector -- that's an > >> excellent idea. > > I guess the 'state of the art' way of recording a list of installed > packages, nowadays is > > # aptitude -F "%p" search '~i!~M' > package-list > > You can then just install like > > # aptitude install $(cat pacage-list) > > dpkg --get-selections does not distinguish between packages installed > manually or automatically, so that information is lost on the reinstall. > The search pattern just looks for packages that were installed > manually. The install will automatically install all dependencies. However, because of OR dependencies (i.e. using the '|' character), it might install *different* packages to satisfy dependencies. Your saved configuration files won't work with those packages. Some combination of dpkg --get-selections and aptitude search '~M' should be able to save both "all installed packages" and "all automatically installed packages", and some combination of dpkg --set-selections, aptitude markauto, and aptitude install should be able to restore them. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: a cautionary tale w/ successful recovery
Andrew Sackville-West wrote: > On Sun, Nov 01, 2009 at 07:08:00PM -0500, Andrew Reid wrote: >> For the sysems I back up at work, we do the dpkg --get-selections >> thing, but I've never kept a copy of the boot sector -- that's an >> excellent idea. I guess the 'state of the art' way of recording a list of installed packages, nowadays is # aptitude -F "%p" search '~i!~M' > package-list You can then just install like # aptitude install $(cat pacage-list) dpkg --get-selections does not distinguish between packages installed manually or automatically, so that information is lost on the reinstall. The search pattern just looks for packages that were installed manually. The install will automatically install all dependencies. > If I had managed to understand what was going on between the part > where the MBR got munched and other bits started flying out to the > disk, it would have worked to just rewrite the MBR and reboot. There is also testdisk to help recover the mbr for you... Worked for me once. -- Johannes Three nations have not officially adopted the International System of Units as their primary or sole system of measurement: Burma, Liberia, and the United States. http://en.wikipedia.org/wiki/Si_units -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: a cautionary tale w/ successful recovery
>> I am truly grateful that I had > > good ones and the recovery went well. For those of us not as Debian educated, you know like me who use Arno-iptables- firewall instead of Shorewall, I like Terabyte's image for Linux v.2. and if you're squeamish about paying a fee for this you can have the v.1.99 with less options for free. You can run it from its own partition or a CD as a boot disk for imaging any partition including the MBR on your choice of detachable or internal storage, the network version (v.2x) goes beyond the local host. -- C. -- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: a cautionary tale w/ successful recovery
On Sun, 1 Nov 2009 14:57:49 -0800 Andrew Sackville-West wrote: ... > 3) is just a convenience really. I have a pretty good idea of what > packages I use on a daily basis are, but there are always random > things one forgets and they'll probably crop up routinely over the > next couple of months. Yeah, you'll remember wpasupplicant the first time that you're at a location that requires access to an encrypted network ... (Been there, done that :/) > Anyway, I just wanted to share that. And for all those who think they > don't need backups... you're so wrong. I am truly grateful that I had > good ones and the recovery went well. AOL! Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: a cautionary tale w/ successful recovery
On Sun, Nov 01, 2009 at 07:08:00PM -0500, Andrew Reid wrote: > On Sunday 01 November 2009 17:57:49 Andrew Sackville-West wrote: > > > > > So here is the real success part of the story: my backups worked! I > > had weekly backups of /etc and daily backups of /home. Since I'd not > > done any work of consequence in about 24 hours, I had not lost data! > > Restoring was a simple matter of copying over from the backup server, > > fixing up a couple of permissions and moving on. > > > > Lessons learned: > > 1) don't do risky things in DOS 6.22 when tired... you can't trust > > DOS to behave in a consistent manner (maybe) > > > > 2) keep a copy of the boot sector lying around (on another machine!!) > > 3) keep a copy of dpkg --get-selections lying around > > > Congratulations! > > If it were within my power, I'd award you the Order of the Clue, > the one with the *nice* ribbon. :) > > For the sysems I back up at work, we do the dpkg --get-selections > thing, but I've never kept a copy of the boot sector -- that's an > excellent idea. It turns out it would not have really helped in this situation because of writes in other parts of the disk, but in other, slightly less catastrophic situations, it would have been useful. If I had managed to understand what was going on between the part where the MBR got munched and other bits started flying out to the disk, it would have worked to just rewrite the MBR and reboot. A signature.asc Description: Digital signature
Re: a cautionary tale w/ successful recovery
On Sun, Nov 01, 2009 at 07:20:23PM -0500, Rob Owens wrote: > On Sun, Nov 01, 2009 at 02:57:49PM -0800, Andrew Sackville-West wrote: > > Hi all, mildly off-topic, perhaps. > > > > Due to a cascading series of errors on my part yesterday, I managed to > > not only wipe over my partition table, but also overwrite enough data > > in the actual disk to prevent reasonable recovery of the partitions > > with such tools as gpart. > > > > I could recover /boot, and /swap, but the lvm-hosted remaining portion > > of the system was hosed, mostly because I couldn't accurately locate > > the partition. Maybe if I'd been a little smarter about it, I could > > have, but I didn't know, until too late, what exactly to look for. So, > > after much gnashing of teeth and rending of clothing, I decided to > > reinstall. [...] > A couple good utilites I've used in situations like these are testdisk > and photorec. Photorec can recover files even if there is no partition > table (it won't know the filename, but it will tell you the file type). to be clear, I was able to see portions of file systems and actually found all of / using gnu-fdisk's "Rescue" feature. I was able to mount and fsck it and it checked out okay. But that fs was buried in an lvm partition *and* it couldn't find other filesystems. Since I run multiple lv's in lv to hold the system, it wasn't much use... having / without /usr and /var is not really that great. gpart found /boot and /swap(not much use), but /boot was corrupted pretty badly. It did *not* find anything in the lvm partition, though I got tired of waiting for it, so maybe it would have eventually. This has caused me to rethink the use of lvm on this system. Although I like the flexibility, I'm not so sure it's not just better to use one large partition for everything. What I discovered is that though it might have been possible to recover, it was certainly easier and ultimately less stressful to just reinstall and restore from backup. A signature.asc Description: Digital signature
Re: a cautionary tale w/ successful recovery
On Sun, Nov 01, 2009 at 02:57:49PM -0800, Andrew Sackville-West wrote: > Hi all, mildly off-topic, perhaps. > > Due to a cascading series of errors on my part yesterday, I managed to > not only wipe over my partition table, but also overwrite enough data > in the actual disk to prevent reasonable recovery of the partitions > with such tools as gpart. > > I could recover /boot, and /swap, but the lvm-hosted remaining portion > of the system was hosed, mostly because I couldn't accurately locate > the partition. Maybe if I'd been a little smarter about it, I could > have, but I didn't know, until too late, what exactly to look for. So, > after much gnashing of teeth and rending of clothing, I decided to > reinstall. > > Now mind you, this is the first reinstall on this machine (a very loose > description considering it's had three motherboards, two disks and > various and sundry parts swapped) since 2004. > > Installation was, of course, fairly painless using the daily-build > business card image of squeeze. I had a couple of problems when > partitioning, but got it sorted out after a reboot to properly re-read > the partition table. > > So here is the real success part of the story: my backups worked! I > had weekly backups of /etc and daily backups of /home. Since I'd not > done any work of consequence in about 24 hours, I had not lost data! > Restoring was a simple matter of copying over from the backup server, > fixing up a couple of permissions and moving on. > > Lessons learned: > 1) don't do risky things in DOS 6.22 when tired... you can't trust > DOS to behave in a consistent manner (maybe) > > 2) keep a copy of the boot sector lying around (on another machine!!) > 3) keep a copy of dpkg --get-selections lying around > > Now, I know bot 2) and 3), but hadn't really ever bothered to do > it. It's *possible* that 2) could have saved me from reinstalling, but > it still would have required significant work to get everything going > again. > > 3) is just a convenience really. I have a pretty good idea of what > packages I use on a daily basis are, but there are always random > things one forgets and they'll probably crop up routinely over the > next couple of months. > > Anyway, I just wanted to share that. And for all those who think they > don't need backups... you're so wrong. I am truly grateful that I had > good ones and the recovery went well. > A couple good utilites I've used in situations like these are testdisk and photorec. Photorec can recover files even if there is no partition table (it won't know the filename, but it will tell you the file type). -Rob -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: a cautionary tale w/ successful recovery
On Sunday 01 November 2009 17:57:49 Andrew Sackville-West wrote: > > So here is the real success part of the story: my backups worked! I > had weekly backups of /etc and daily backups of /home. Since I'd not > done any work of consequence in about 24 hours, I had not lost data! > Restoring was a simple matter of copying over from the backup server, > fixing up a couple of permissions and moving on. > > Lessons learned: > 1) don't do risky things in DOS 6.22 when tired... you can't trust > DOS to behave in a consistent manner (maybe) > > 2) keep a copy of the boot sector lying around (on another machine!!) > 3) keep a copy of dpkg --get-selections lying around Congratulations! If it were within my power, I'd award you the Order of the Clue, the one with the *nice* ribbon. For the sysems I back up at work, we do the dpkg --get-selections thing, but I've never kept a copy of the boot sector -- that's an excellent idea. -- A. -- Andrew Reid / rei...@bellatlantic.net -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
