Hi Everyone,<br><br>I've just joined the INX mailing list even though I have been using INX off and on since INX 1.0. I feel this is a wonderful distribution, one that's really unique and useful amongst many others that differ little, one from another. I think the menus and tutorials are nice and light in tone and quite a brilliant concept overall. INX was helpful in getting me more comfortable and competent with the command line, and also giving me a better idea of what applications are available for the framebuffer. When the inxtaller script came out on launchpad, I even installed INX 1.15 to the harddrive of my ancient Compac Presario 1210 (150MHz CPU, 80MB RAM 1.3GB HD), on which it run very well. Any distro that uses X (except, perhaps Slitaz) is way too slow on that computer. Before INX arrived on the scene, I was looking for a command line distro and came across mention of clubuntu and clibuntu. Were these former names of INX before Cannonical made everyone drop the -ubuntu in their names?<br>
<br>I have two eeepcs that I have been testing inx-lucid-alpha2 on. One is an eeepc 701 Surf (this has a small 7 inch display, 800x480 native resolution), and the other is an eeepc 1000HA (10 inch display, 1024x600 native resolution). <br>
<br>I successfully used inxusb to install inx to a thumb drive and I can boot from that thumb drive just fine. However, when I halt or reboot after a session I find that the second partition (the persistent filesystem) consistently does not umount cleanly. There appears to be a lot of warnings and/or errors that flash momentarily on the screen just before it goes blank. I don't know how to capture these. I've tried to redirect error messages to a file with "halt &> errors.txt" but there's nothing in the resulting file. Is there a log of shutdown messages in /var/log? Later, when I run fsck on the second partition, fsck isn't the usual quick automatic fix, it always requires manual interaction, as I show below (its an ext2 filesystem):<br>
<br>e2fsck 1.41.12 (17-May-2010)<br>casper-rw was not cleanly unmounted, check forced.<br>Pass 1: Checking inodes, blocks, and sizes<br>Deleted inode 15 has zero dtime. Fix<y>? yes<br><br>Deleted inode 16 has zero dtime. Fix<y>? yes<br>
<br>Deleted inode 17 has zero dtime. Fix<y>? yes<br><br>Pass 2: Checking directory structure<br>Pass 3: Checking directory connectivity<br>Pass 4: Checking reference counts<br>Pass 5: Checking group summary information<br>
Block bitmap differences: -18432 -(18440--18466) -18472 -(18482--18484) -18498<br>Fix<y>? yes<br><br>Free blocks count wrong for group #0 (32144, counted=32177).<br>Fix<y>? yes<br><br>Free blocks count wrong (278107, counted=278140).<br>
Fix<y>? yes<br><br>Inode bitmap differences: -(15--17)<br>Fix<y>? yes<br><br>Free inodes count wrong for group #0 (8128, counted=8131).<br>Fix<y>? yes<br><br>Free inodes count wrong (72531, counted=72534).<br>
Fix<y>? yes<br><br>casper-rw: ***** FILE SYSTEM WAS MODIFIED *****<br>casper-rw: 762/73296 files (1.8% non-contiguous), 14724/292864 blocks<br>don@1000ha:~$<br><br>I have a third partition on the same thumbdrive that INX automatically mounts. This partition also is not umounted cleanly. However fsck just does a quick pass of this partition and all is well. The first partition on the thumbdrive always umounts correctly. <br>
<br>I don't know if this is related to the umount problem above, but I know there is a consistent problem with other distros with the eeepc 701 uncleanly umounting the SD card during reboot or halt. (Because of the small 4GB solid state hard drive on these machines, many users make extra space by mounting their /home directories on an SD card.) Arch Linux has a fix for this problem here<br>
<a href="http://wiki.archlinux.org/index.php/Asus_Eee_PC_701#Unclean_unmount_during_shutdown_when_having_home_directory_mounted_on_SD_card">http://wiki.archlinux.org/index.php/Asus_Eee_PC_701#Unclean_unmount_during_shutdown_when_having_home_directory_mounted_on_SD_card</a><br>
<br><br>I also have some observations and problems, mostly relating to the particularly small size of the 701 Surf screen, which I can include in a later email, if you are interested. I don't know how popular these small machines are these days and whether or not its worth the effort to try to accomodate them in INX, but I find mine perfect for the command line because the screen and mousepad are pretty small for graphical applications.<br>
<br>Thanks for developing INX to the point that it is. I really think it is a valuable distribution.<br><br>Don Williams<br><br>