[Inx] INX-lucid-alpha2

Peter Garrett inx-one at optusnet.com.au
Mon Jul 12 21:06:58 PDT 2010


On Wed, 7 Jul 2010 13:52:05 -0700
don williams <williamsdonwalla at gmail.com> wrote:

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

<snip>

Thanks :)

> 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?

No, INX was an independently conceived re-spin of Ubuntu, and I avoided
the -buntu names, as you have seen. Apart from anything else, I think having all 
these "foobuntu" distros gets a bit tedious ;-)

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

Not sure about this, but it may be that as an experienced user you have
the habit of shutting down or rebooting directly from the command line.
In the main 'menu' (which is  /usr/local/lib/inx/menu), I have these
lines under the 'halt' (q) and 'reboot' (r) entries:

# Unmount - needed for 'persistent' to avoid multiple bogus mounts showing... 
sudo umount -a 2> /dev/null # Spits out a lot of stuff -seems harmless...

In theory this should unmount everything before halt/reboot. The 2> /dev/null
suppresses errors of course. Maybe that was a bad idea!

<snips>

> 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 suggest that you try using the menu entries as above, if you haven't been using them.
If you halt or reboot from the prompt directly, try running

sudo umount -a && sudo shutdown -h now

(or 'sudo shutdown -r now' for reboot)

If these methods don't fix the issue, I'm not sure what is causing it...
> 
> 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

O.K. the hack makes sense - as an alternative you could try ejecting the partitions before shutdown (casper-rw etc.)

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

Small screens are an issue with INX of course - if the screen can't do at least 800x600 with frame buffer
the menus will not fit, and anything using fb will fall over (video, graphical browser, fbi image viewing and so forth)

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

One of the ideas I had some time ago (as in, years ago...) was to add a check for screen resolution
and switch to a set of "mini menus" if less than 100x37 columns x lines, for example. I never got around to coding this,
though. Lazy me... ;-)
> 
> Thanks for developing INX to the point that it is.  I really think it is a
> valuable distribution.

Thanks, and apologies for the tardiness of my reply...

Peter



More information about the Inx mailing list