[Inx] Follow-up/correction re: umount on halt (was Re: INX-lucid-alpha2)

[don williams]

Hi Peter,

Thanks for your reply and helpful suggestions.  And don't worry about
being tardy--it's taken me a while to get back to you because I've
been trying lots of things to figure out what the problem here is.

Your are right that I have been halting and rebooting from the command
line, but that doesn't appear to be the problem.   Lets say that the
usbinx persistent filesystem (casper-rw) is on device /dev/sdb2.  If I
issue the following commands,

# sync;sync;sync;
# umount -a
# shutdown -r now

and then reboot into another operating system, and issue

# fsck /dev/sdb2, I find that sdb2 has not cleanly unmounted.

(In the above series of commands, I find that if I don't issue the
sync command, then I find that other mounted partitions will unmount
ok, but fsck on the next reboot finds them uncleanly unmounted.  This
may be a peculiarity of eeepcs and so isn't the problem here.)

However, this still leaves /dev/sdb2 uncleanly unmounted.

In my previous email, I said that I get error messages appearing on
the screen just before it goes blank:

"end_request: I/O error, dev sdb, sector 862368"
"Buffer I/O error on device sdb2 logical block 75"

These are repeated with slight variations many times, but I think now
that these are caused by bad blocks, or some such thing on my usb
thumbdrive. ( I sometimes have mysterious problems while using usb
flash drives, and I think this is one of them.  Running badblocks on
these devices never finds bad blocks, though.)  Thinking that a
failing thumbdrive might be the problem, I installed usbinx to another
thumbdrive  Using the new thumbdrive, I don't get error messages at
shutdown, but /dev/sdb2 still does not unmount cleanly, as verified by
rebooting into another operating system and issuing fsck.

I had access to a Dell Inspiron 530, but I get exactly the same
results using both thumbdrives, so this isn't just a peculiarity of
the eeepcs.

It might be important to be aware that this situation only happens in
the "persistent"
mode, not in the "non-persistent session", nor in the "toram session".
 In both these latter
modes, /dev/sdb2 unmounts properly and fsck after rebooting to another
operating system finds the /dev/sdb2 to be clean.

For the moment, I've run out of ideas.  Do you have any, especially
considering this is happening on the Dell, as well?

On the subject of small screens, such as the eeepc 701, I found that
in the demo section of the inx menus, the video part of "A New
Computer" won't play.   I think because the video is 720x480 whereas
vesafb supports a resolution of only 640x480 on the eeepc 701.  It
seems a shame to me that the demo, which is supposed to demonstrate
the capabilities of inx and the framebuffer, doesn't work.  The video,
however, will play properly with the command

#  mplayer -zoom -x 640 A_New_Computer.ogg

To get the video working properly on small screens, could you test for
display size and invoke the appropriate command?  This might be
considered an ugly hack, I don't know.  The eeepcs use Intel video
hardware, so I suppose a more elegant method would be to load the
Intel framebuffer driver, inteldrmfb, to give native resolution, which
is 800x480 on the eeepc 701.  I know both Arch Linux and CrunchBang do
this.

Something else I noticed is that ceni is very slow to start up, and to
complete some operations once it is running, such as going BACK from
reconfiguring a network interface.  Ceni seems to grab 100% of the cpu
for 30 seconds or so.  I can't switch to other virtual terminals, or
do anything else until ceni is ready.

I also notice that the directory /home/inx/.mc has root as owner and
group, instead of inx.  This means that midnight commander doesn't
close nicely.

Thank you again for creating such a wonderful distrobution.

Don