[Inx] INX-lucid-alpha2

[don williams]

Hi Everyone,

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?

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).

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):

e2fsck 1.41.12 (17-May-2010)
casper-rw was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Deleted inode 15 has zero dtime.  Fix<y>? yes

Deleted inode 16 has zero dtime.  Fix<y>? yes

Deleted inode 17 has zero dtime.  Fix<y>? yes

Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  -18432 -(18440--18466) -18472 -(18482--18484)
-18498
Fix<y>? yes

Free blocks count wrong for group #0 (32144, counted=32177).
Fix<y>? yes

Free blocks count wrong (278107, counted=278140).
Fix<y>? yes

Inode bitmap differences:  -(15--17)
Fix<y>? yes

Free inodes count wrong for group #0 (8128, counted=8131).
Fix<y>? yes

Free inodes count wrong (72531, counted=72534).
Fix<y>? yes

casper-rw: ***** FILE SYSTEM WAS MODIFIED *****
casper-rw: 762/73296 files (1.8% non-contiguous), 14724/292864 blocks
don at 1000ha:~$

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.

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
http://wiki.archlinux.org/index.php/Asus_Eee_PC_701#Unclean_unmount_during_shutdown_when_having_home_directory_mounted_on_SD_card


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.

Thanks for developing INX to the point that it is.  I really think it is a
valuable distribution.

Don Williams
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inx.maincontent.net/pipermail/inx-inx.maincontent.net/attachments/20100707/7be4c1ce/attachment.htm>