[conspire] Utility to rescue formatted EXT3 partition & distribution choice?

[Rick Moen]

Quoting Edmund Joseph Biow (biow at bigfoot.com):

> I'm looking for a utility to recover a formatted EXT3 partition. 

I am terribly sorry to have to give you the bad news:

"ext3 No Undeletion" on http://linuxmafia.com/kb/Filesystems 
(item description: "Why undeleting files on ext3 isn't possible, even
though it is on ext2")

Note that quoted poster Stephen C. Tweedie is one of the filesystem
maintainers.

My page explains why ext3's data-handling unfortunately prevents some of
the recovery methods applicable to ext2 from working.  In a couple of
places, it describes some tools and general approaches that may be able
to get some of your data back, anyway.

I am very sorry about your data loss.  I hope you didn't have much work
invested into it.  (When the pain fades, start thinking about
backup/restore.)


> Since I'm already annoying you folks I thought I'd solicit OS comments.
> 
>   Here is what I'd like for this box.
> 1. Normal desktop stuff.  Internet, music, camera, file manipulation.
> 2. I'd like to install MythTV at some point, if I can find a compatible
> TV card that will fit in this little slimline case (my Hauppauge PVR-150
> failed, the antenna aperture needs to be towards the middle or bottom of
> the card). 
> 3. 3D desktop.  What the hey, I've got the muscle.  Not too picky
> between XGL, AIGLX, Beryl, etc.  Really, I just want the mouse
> scroll/keyboard zoom and translucency effects.
> 4. At some point I'd like to play around with virtualization.  The AMD
> X2 apparently has some hardware virtualization support.  Wine is a pain
> and there are some Windows apps I like (curiously, generally NOT
> commercial ones).  I don't care about using an unsupported version like
> 98SE, since it wouldn't be used for surfing, other than, say, CDDB
> access for Exact Audio Copy). 

Some people seem to really like Dreamlinux, Linux Mint, and SabayonLinux
for 3D / "desktop" sorts of things.  You're more than welcome to come to
Saturday's CABAL meeting and make exact media copies of any/all of them, and
of as much of http://linuxmafia.com/cabal/installfest/#distros as you
like.  (Reload that link, if you aren't taken right away to the top of
the distros list.)

One of the nice things about how I maintain that page is the hyperlink
on each distro name -- which takes you to somewhere informative about
each such entry.  Alternatively, just follow the "Distrowatch" link
at the top of that section.

The best platform for playing with Linux virtualisation at this point is
probably the RHEL5 prerelease (included in the CABAL collection, note),
because of the rather nice administrative tools they're developing for
handling Xen virthosts.  (It's nicely abstracted, so it'll work equally
well with the new "KVM" virtualisation design, as that matures and
becomes compelling.)

MythTV?  Before you attempt an installed distribution for that, save
yourself some pain and try the (installable) KnoppMyth live CD, which is
set up to Just Work:  http://mysettopbox.tv/doc.html


> I'm having some second thoughts about installing 64 bit anything. 

If you don't have several gigs of RAM, it doesn't really buy you
anything.  With more modest amounts of RAM, you should still go with
x86_64 distros _unless_ you're feeding a proprietary-software addiction,
which creates problems because those asshats tend to still offer
i386-only binaries -- which still can be supported by pose varying
degrees of hassle.

> I could install the latest MEPIS 64 bit beta or maybe OpenSUSE 10.2 64,
> both of which appear to use 32 bit versions of Firefox to get around the
> plugin problem. 

For example, _that_ hassle -- which is nonexistent if you eschew crappy
proprietary plugins.

> Also, at this point I'm also wondering about my choice of SIDUX.  I'd
> like to be somewhat closer to the cutting edge than Sarge (which
> periodically updates me to the latest revision of Firefox 1.0.4).  I
> figured this isn't a great time to install Etch, since it is about to go
> stable in a couple of months.  At the beginning of the next release
> cycle Etch will probably become much more like Alpha software, no?  I
> don't really want to experience major breakage every few weeks.  

Um, you're stuck in a very common mental trap -- which is interfering
with your analysing this situation correctly.  You're thinking of 
Debian-branch installion media as endpoints, rather than as initial
mechanisms intended solely to get you onto one of the three moving
(i.e., evolving) development tracks (stable, unstable, testing).
This is an understandable error because (1) most _other_ distros are
release-oriented with huge discontinuities between releases, and (2) 
one of the Debian tracks ("stable") mostly follows those other distros'
example, except with smoothly managed transitions between releases.

That is, the aim of the Sidux installer is to get you onto the evolving
unstable branch.  (Well, not precisely.  See where I resume discussion
of Sidux, further down.)  The aim of the (current) Etch/4.0 installer is
to get you onto the evolving testing branch.  The aim of the (current)
Sarge/3.1 installer is to get you onto the evolving stable branch.  None
of those is intended to dump you at a static endpoint.  E.g., using an
Etch/4.0 installer isn't intended to get you glued to Etch as it goes
from testing, to stable, and finally gets mothballed to the
debian-archive collection and ceases to receive updates at all.

When you installed Etch, you didn't get Etch; you got a machine synced
at that moment to the recent contents of the testing branch, and with
/etc/apt/sources.list entries tweaked to easily keep you synced to the
_testing_ track (via apt-get, aptitude, synaptic, whatever), and stay
that way (following "testing") as the "testing" symlink gets re-pointed
to new branch "lenny" (which will probably end up being 4.1).  And
beyond.

"testing" is always an _approximately_ constant degree of beta-ishness
away from the cutting edge.  Presumably, you installed using the Etch
installer in 2007 because you _like_ the current tradeoff it gives you
of recent app versions versus beta-ishness.  If so, you should 
_leave sources.list alone_, forget about all the Toy Story names 
(Sid, Buzz, Rex, Bo, Hamm, Slink, Potato, Woody, Sarge, Etch, Lenny), 
and remain comfortably on the gradual ride that is "testing", with the
rest of us.

> When Etch becomes the new Stable I wonder if I could pin my install to
> stable or would I still be in testing?   

Check for yourself.  Look at your /etc/apt/sources.list file.

If someone has been an idiot, it'll say "etch" as the thing to follow,
prospectively.  If not, it'll say "testing".


> Sidux has too short a track record to predict how robust it will be
> over the long haul.

Actually, I think you can _rely_ on it.  The key is to understand what
they're doing, and how.

Here, read this:
http://distrocenter.linux.com/comments.pl?sid=38131&cid=96900

Basically, they provide:

o  An robust installable live CD with a simplified set of screens and 
   good automated hardware detection a la Knoppix, whose installer 
   program puts you in a good position to _either_ follow pure 
   sid=unstable thereafter _or_ follow their lightly filtered, smoothed-out 
   sid+fixes development track.

o  Timely advisories of "sid" bobbles as they arise.

o  An apt repository of fixed packages to semi-automate the avoidance 
   of significant "sid" bobbles and to auto-select their fixed package 
   versions instead.  (Disabling use of that repository after Sidux
   installation means you've used Sidux as an installer for pure
   Debian unstable.)

o  A script called "du-fixes", described as "a general utility script
   that handles the standard system upkeep for debian sid based sidux -
   kernel installs, dist-upgrade etc, package installs, cleanup, and
   graphics install. Has logging options, and will create logs on error
   of key parts." (http://techpatterns.com/forums/about736.html)


Anyhow, revisiting a passage of yours, quoted above:

> At the beginning of the next release cycle Etch will probably become
> much more like Alpha software, no?  I don't really want to experience
> major breakage every few weeks.

Nope.  Etch will become the new _stable_ branch -- i.e., increasingly
archaic and boring, over time.  Unfiltered sid=unstable will for a while 
become a bit rocky.  The upcoming new testing branch (lenny) will
probably be kept from enduring most of that temporary "sid" breakage as
things like new compile toolchains, new Perl, new system libraries, etc.
come in and upset things, because of the buffering effect of the
"testing" package quarantining script.

Current symlinks are:

unstable -> sid  (which is always the case)
testing -> etch
stable -> sarge

"At the beginning of the next release cycle", the Debian
development-track symlinks[1] will get repointed like this:

unstable -> sid
testing -> lenny (newly created branch)
stable -> etch

Get it?



> SIDUX seems to have a rapidly growing community, forum and a friendly
> and helpful IRC channel (particularly if you sprech ein bisschen
> Deutch).  It is KDE & desktop oriented, which is a plus for me (though
> you can add XFCE metapackages during installation).  

It's exactly the people who favour the "desktop" metapackages who will
benefit from efforts like Sidux:  You get the selection of all-cutting edge 
packages all available in coordinated versions at the same time, that is
characteristic of sid=unstable.  You get some of the stabilising effects 
that are available in pure Debian only by following the "testing" track, 
which is a script-quarantined filtered version of "unstable'.

The problem of following the "testing" track, if enamored of the desktop
metapackages, is that related packages may (and often do) clear
quarantine with different delay factors.  So, at any given time, the
huge dependency-hairball thing you want to update that day (e.g.,
Konqueror, KWord, or whatever) may not be installable in "testing"
because libfoo-nnn.i386.deb hasn't yet cleared quarantine.

People on "testing" who want the best of both worlds can give themselves
manually-selectable access to unstable-branch packages as well, by using
the "pinning" technique to specify package priorities.  (There are a
couple of different ways of doing that.)  Once you have your (e.g.) KDE
system set up that way, on the day you can't update KWord because
libfoo-nn.i386.deb isn't yet in "testing", you emit a mild profanity,
then type:

#  apt-get  -t unstable  install kword 

...or whatever.


(I note that Warren Woodford reportedly got into annoying amounts of
trouble trying to converge MEPIS onto Debian-testing.  I don't have
details, but suspect he simply hadn't realised the effect of the
above-described KDE dependency-hairball issue, and how it interacts with
variable quarantine delays.)

[1] You can see those symlinks for yourself if you use a command-line
ftp client (not a Web browser), open a connection to host
ftp.debian.org, and look in directory "/debian/dists".