I've been using antiX 13.2 on my 1997 vintage laptop (Gateway Solo 2500, 300 MHz Pentium II and 288 MiB RAM) for several months. It runs about as well as Win98 did, and it's safe to use on the Internet -- with a rebuilt battery, PCMCIA wifi card, and with Abiword and Gnumeric replacing Libre Office, it's a useful computer again after years of being just a bedside stereo.

I've been running with a Compact Flash memory card made for a camera, in an adapter that makes it look, electronically, like an IDE hard disk, but I've had trouble with (software) fragility of that setup. The computer occasionally locks on the screen saver (black screen, no cursor, no response to touchpad or keyboard), and the only way I've found to resolve that problem is to power down and restart. The problem is, doing that invariably damages something in the file system; cumulatively, since my last reinstall in May, I've now reached a point where I can't launch antiX Control Centre, IceWeasel, or the shutdown dialog, at least from Fluxbox. I can still shut down in a controlled fashion by issuing"shutdown now" as root from a terminal, but if I lose access to bash, I'll be left with only the power switch.

Reinstalling the failing applications with Synaptic doesn't help, suggesting it's more of an infrastructure failure than actual damage to the apps I can't use. I've concluded I'll need to reinstall (again!), which is an adventure on this machine because neither the CD drive nor the USB ports are completely reliable -- I'll manage, some way; it worked last time.

What I'm concerned about is whether there's a setting, daemon, or utility I can use to improve the robustness of the file system/CF drive combination against unexpected shutdowns. I've seen file damage on platter drives in the past from power drops or lockups, but not generally this pervasive, and almost invariably when the drive was writing at the time of power loss; that's what makes me feel the CF drive is contributing to the problem. However, the CF drive is faster than a platter drive old enough to work in this system (IDE 2.5", no larger than 32 GB capacity, limited by BIOS), and, based on my experience upgrading from the original 4 GB drive, much more likely to work within my price range. I presume the problem is caused by open files, not electronic mayhem (the CF drive appears to work perfectly after each such episode, aside from damaged files). Is there a way to ensure (even at a small cost in performance) that files are closed as soon as possible, even while applications are open? Or am I completely off base in my thinking as to what's causing my problems? Or do I need to give up on the"redneck SSD" and shop for a 16-32 GB platter drive I can afford and, hopefully, works (or maybe a used genuine SSD, if those were ever made with IDE connection)?

The key question is which filesystem are you using? You need to be using a journaling filesystem with journaling enabled. If you want to be really safe use ext4 and set data=journal. This will protect you but it will be slower on writes (I'd guess by a factor of two or so).

If there were a mode that was safer than the default and nearly as fast then it would be the default. Ext4 with the default settings works well here even with a few power outages. If that is not working for you then you need to use data=journal and take the speed hit.

Btrfs might have a feature like this too but I'm not familiar with btrfs.

Aaaah. I've been running ext2, because I understood that the journaling requires extra writes, which wear out the compact flash sooner (and this CF was used when I got it; no way to tell how much life it has left). After posting above, however, I found on eBay that I can get a 32 GB IDE SSD for under $50; that's just about a no-brainer for this situation, if only it'll work with the heads/cylinders/sectors geometry limit my BIOS will accept. I may try contacting the manufacturer (Kingspec) if I can't find a spec sheet online, because my BIOS limit is 15 heads, 65535 cylinders, and 63 sectors/track, which adds up to a speck under 31 GiB (a 32 GB platter drive should work, but I'm not certain about a 32 GB SSD).

Worst case, I can get a 16 GB SSD for about $27, and I know that size will work (that's the size of the CF I'm running now) -- and these are modern SSD hardware, listed with a rated life of decades at 10 GiB write/erase per day, i.e. they'll outlast me. Meantime, I'll use ext4 when I reinstall (I have that on my platter drives on both my desktop systems, which do seem a lot more resilient).

Back when I ran ext2 on my cheapo phison ssd drives on my eeepcs. I fixed file corruption on ext2 by booting my antix live session and running gparted>right click on corrupted drive>check

Let check run while a live session. Then Shutdown. Reboot. Everything was fixed. No need for a reinstall.
Ran that way for years. The price of pcie ssd back then plus mine were 800hz celeron eeepcs was why I sold them
and went with my M&A Atom computers. That and for the price of one eeepc sale. I could buy 2 M&A Companion netbooks.

Hmm. Might be worth trying, though I'll still consider whether I ought to spend the cash for a"real" SSD with an expected life long enough I don't have to worry about wearing it out -- and/or reinstall just to make the change to ext4 (given how little I write on this drive, even an old CF will probably last beyond the usefulness of a PII w/ 288 MiB RAM).

Gparted will give the unmount option 1st before running check.
It is so you do not do a file system check while the file system is mounted.
A big no no.

Pretty much idiot proof really.

IMO, the concern over extra wear due to journaling is mostly theoretical. It is based on the assumption that the flash device has absolutely no wear leveling so logical locations on the"disk" directly correspond to physical memory cells. Since the journal area gets more writes than usual, the theory is that the cells associated with it will wear out sooner. If the device has even a crude form of wear leveling then this is no longer an issue. Yes, the memory cells used for the journal will wear out sooner than average but the device will automatically replace them with others before you notice a problem.

IMO, a bigger deal for reducing wear is to use a device and a file system that have TRIM support and then set up a cron job to periodically run the fstrim program. The ext4 filesystem has TRIM support. The problem is that flash memory has very large"erase blocks". To write to any portion of an erase block, the entire block must be erased and all the data in it must be re-written. This can be massively inefficient, especially when the device has to assume that every byte is precious and needs to be preserved. The TRIM feature lets the filesystem tell the device which locations can be erased without being re-written.

So if you want longevity plus reliability, get an ssd that supports TRIM. Unfortunately, this may not be available for the hardware you have described. The next step down is to get a device that has wear leveling built in. My rough guess is that this is (or should be) the difference between an ssd and a flash stick but I have no idea how much crossover there is. If you have a device with wear leveling then journaling should not cause a problem so you should have journaling enabled for reliability.

If you have a cheap device that does not have wear leveling (I have no idea how to detect this non-destructively) then I suggest you try our Live system with root persistence. Install and delete whatever packages you want (perhaps on a heftier system) and then do a live remaster. After that run it with root persistence. During normal operation, we are not writing to the disc so the system won't be damaged if there is a sudden power outage. If the flash device is removable and you have enough RAM to use the toram feature then you can remove the flash device from the computer and only re-attach it when you want to save you current state (such as at shutdown).

If you have a cheap flash drive and don't want to run live then the choice is between longevity and reliability. I favor reliability over longevity. IOW, my data is important (even though most of it is not).

BitJam wrote:IMO, a bigger deal for reducing wear is to use a device and a file system that have TRIM support and then set up a cron job to periodically run the fstrim program. The ext4 filesystem has TRIM support. The problem is that flash memory has very large"erase blocks". To write to any portion of an erase block, the entire block must be erased and all the data in it must be re-written. This can be massively inefficient, especially when the device has to assume that every byte is precious and needs to be preserved. The TRIM feature lets the filesystem tell the device which locations can be erased without being re-written.

The most recent to TRIM and co:

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://news.siduction.org/"
linktext was:"http://news.siduction.org/"
====================================

Roky, I've used gparted many times, and know that most operations done in that software need the partition to be unmounted (hence why you can't check root or /home for the OS you're running, since they can't be unmounted while they're in use). Unfortunately, running the gparted check the one time I got a good boot from USB today made no change in the problems with applications not starting.

BitJam, it's my understanding that all flash memory other than, possibly, first generation battery-backed devices have wear leveling; I'm reasonably sure any flash new enough to put 16 GiB on a single device has it. It looks like TRIM is mostly a performance enhancement, amounting to giving permission to overwrite blocks without preserving the unaffected portion of the previous contents, and wouldn't affect longevity (the block will be rewritten anyway, and moved if wear leveling decides that's needed, regardless whether old contents are to be preserved). I think there's a lot less write activity on this drive than I originally estimated, anyway; system updates are just about it, so when I reformat (as appears inescapable), I'll format to ext4 and worry about storage wear if it becomes a problem before I can spend $50 on a new SSD.

Of course, by then this laptop may be too unreliable to bother spending money on; with the CD and USB ports already giving boot problems, anything I can't install from the internal storage is going to be impossible to install in a while.

BitJam wrote:If you have a cheap device that does not have wear leveling (I have no idea how to detect this non-destructively) then I suggest you try our Live system with root persistence. Install and delete whatever packages you want (perhaps on a heftier system) and then do a live remaster. After that run it with root persistence. During normal operation, we are not writing to the disc so the system won't be damaged if there is a sudden power outage. If the flash device is removable and you have enough RAM to use the toram feature then you can remove the flash device from the computer and only re-attach it when you want to save you current state (such as at shutdown).

If you have a cheap flash drive and don't want to run live then the choice is between longevity and reliability. I favor reliability over longevity. IOW, my data is important (even though most of it is not).

Looking back at this, after completing the reinstall, including reformatting root and home to ext4, and with the dist-upgrade to testing repo running (on my much faster Athlon XP system -- minimum of about 6 times faster CPU and 1 GiB RAM instead of 288 MiB), CF card connected via USB card reader (it's normally installed in the bay that holds the internal HDD on the laptop; removing it requires pulling the drive bay out of the chassis and then dismounting the adapter from the module) -- I see several solutions here that just won't work on my laptop. As noted, this"redneck SSD" is internally mounted, takes ten minutes or so to remove it and similar time to replace (and can't be hot plugged). The USB ports in the laptop have become unreliable; I spent four hours trying to get anything to boot from USB today, with one successful start to antiX live in VESA (which produced very strange display) and mutiple failures with freshly burned antiX, Parted Magic (the June 2013 version that's the last with"low ram" settings) and Puppy thumb drives. The CD drive works just well enough to start Plop Boot Manager -- it or something very similar is required to boot from USB -- but I haven't had a good full boot from CD on that machine since I started trying to put antiX on it the first time, a year or more ago.

If ext4, coupled with remembering to run an alt-system disk check after every uncommanded shutdown (given the difficulty of getting a USB boot, I might install Puppy in a partition made by shrinking root or home; at under 150 MiB it can run in RAM even on the laptop, but I'd have to find a partition tool that works with it), I may be able to keep the"redneck SSD" running well enough, long enough, to convince me it's worth spending $50 on a 32 GB IDE SSD that'll have to be pulled out of the machine for anything I can't load through the network (it's rather like having a netbook with no usable USB ports).

Sigh.

Reinstalled antiX 13.2 full 32-bit from the CD to the"redneck SSD" connected to my Athlon XP 2000+, after renaming the user folder in home (to preserve stuff in it, like the output of Synaptic's"save markings", my conky customizations, etc.). Got it done, booted to the Athlon system from the CF card (after finding the correct drive designator combination for menu.lst -- which happens to be the same ones I'll need on the laptop), installed the dist-upgrade to testing repos (1200+ packages), all seemed well. Now it won't boot.

I thought it was the old issues with booting a USB storage device from Plop Boot Manager (yes, I have to use that on my Athlon, too; it's got a good CD drive, so I install from that, but it needs help to boot from USB for a situation like this), hanging at"Device Connected", so I connected to my Core2Quad (Kubuntu 14.04.1) one last time and ran a check from KDE Partition Editor (like gparted only a little slicker and a lot faster). Check was clean, so I swapped the user folders so the original was back to the original name (less than 24 hours since I updated the system, same packages installed, there shouldn't be big issues from mismatched config files).

Now it won't boot, but I don't think its mismatched user folder causing it; with the drive back in the laptop, it starts, but hangs shortly after"scanning for btrfs file systems" -- when it gets a bunch of errors trying to read fd0, the floppy drive! The floppy drive on this laptop hasn't been used in years; last time I tried it, it wouldn't read a disk, but I haven't used any other floppy drives in ten years, so I'm not sure whether it was the drive or the diskette. Hopefully, this is a configuration issue; I can pretty readily swap the user folders back they way they were during install/update, if that's what it takes (just makes it a little more work to get my settings all back to where they were), but I doubt that's it; this is too early in boot to even be reading user configuration, I'd think.

Any suggestions how to tell the system there isn't going to be btrfs on the empty floppy drive?

There used to be some floppy drives that were 'wired up' wrong (IBM & some others), maybe you've got one of those. You will have to search to see what the fix was/is, if it is that that is causing your problem.

If you have Linux on the hdd, you may be able to get it to boot by disabling your floppy in BIOS.

fatmac wrote:There used to be some floppy drives that were 'wired up' wrong (IBM & some others), maybe you've got one of those. You will have to search to see what the fix was/is, if it is that that is causing your problem.

If you have Linux on the hdd, you may be able to get it to boot by disabling your floppy in BIOS.

I've run antiX on that laptop for most of the past year; I strongly doubt it's a hardware issue. I think something got mangled in the last couple boot failures on the Athlon machine (booting from USB via a CD boot manager has always seemed like an ugly kludge to me). I've solved the problem (I think) by starting over, running the installer and making the post-install dist-upgrade and final tweaks on my Core2Quad system, which boots from USB without assistance. As a bonus, it's another factor of six or so faster than the Athlon XP (more than 50% faster clock, and four cores vs. one), so the updates take that much less time (and I'm sure the USB ports are 2.0 standard; the ones in the Athlon system are probably 1.2). No kludge startups, no failed boots, no bad shutdowns to potentially corrupt the contents of the"redneck SSD". He said optimistically.

On the bright side, I've just acquired a Compaq Presario 700 laptop for $5; it needs a power supply and the battery is most likely dead, but batteries are still available, it's got more RAM, faster processor, and a bigger hard disk than the Gateway, and looks like a prime candidate for an antiX install. Need to make a trip to the local thrift stores on payday and see if I can't find a 90W power supply that will fit the connector; most of the new ones the right voltage are only 65W.

Okay, on the second try at reinstalling antiX with the drive connected to another machine, it seems to have worked. I'm back up, connected via wifi, and posting from the laptop; the browser wouldn't even open before. I still have to get the sound working again (and I hope I can find the combination that recognized the internal sound hardware again), but everything else seems to be fine, except the wallpaper selector won't open. I'll start another thread on that, since it's pretty specific.

FWIW, it appears to work fine to preserve the old user folder under a different name while reinstalling and updating, then rename it back to the user name once all updates and package installs are completed. Any config files left will be no newer than the installed packages that way -- in this case, no worse than about 36 hours older, since I updated the night before starting to reinstall -- and as long as you save your sources files and restore them before updating, and export the"markings" from Synaptic (full state, not just changes) and read those markings back in after the reinstall, you get the same package installation state as previously. Saves time on configuring some things. I'd have done the same for my sound setup, if I'd remembered it before formatting the antiX partition (and remembered the files I needed to keep).

Now that I'm on ext4 for both root and home partitions, I should have better robustness against uncommanded shudowns -- at least that's the theory. Now, off to finish restoring my settings (GRUB options, sound, and correct the UUID for my CD-ROM, which is still in fstab as the one in my Core2Quad system after the reinstall done on that machine).

except the wallpaper selector won't open

I've found that if the set wallpaper isn't where it was when set, it throws a wobbly.