rust collector wrote:I have to say that mounting things is the most annoying thing I have found with antix.
It is no big problem, but still, when I plug something in, it is because I want to use it, so I would like it to be automounted.
(but this is my personal wiew, and situation)

I did a bit of modifications to the 99-usb-storage udev rule. Here is what the changes consist of
-It adds a link to the from the mount point to ~/Desktop folder for quick desktop access
-made a simple script that uses yad to change the user that has mounting privileges in 99-usb-storage
-added a user variable so only one spot needs to be changed (more useful for the script).
-changed all subsystem==usb to kernel==sd*[1-9]* to allow for sdcards and some phones.
-added 2 lines to unplugdrive.sh to remove the links from ~/Desktop (89-90)

*note auto open filemanager can be added as well.

The changed files can be found at

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://www.daveserver.info/antiX/non-debs/automount.tar.gz"
linktext was:"www.daveserver.info/antiX/non-debs/automount.tar.gz"
====================================

file placement instructions enclosed in README file

hope this helps solve your annoyance.
Dave

Hello Dave!
Thanks a lot for that... And it even works! __{{emoticon}}__

One little thing, in your /etc/udev/rules.d/99-usbstorage.rules file, there are a few places I had to replace David with kberg (my username)

After that, it seems to work great!
I have only tried it with usual usb sticks, but I think I have figured out where the sd cards are, and will test that later.

Ok, Right now, I can not make it mount sd cards, I have to use the mountbox, which works fine.
Otoh, I think the card I have has issues, so I might try some stuff first.... but I would guess it should work, since I can mount them with m-box?


Uh,maybe I shold start a different thread, as this is for something else?

rust collector wrote:One little thing, in your /etc/udev/rules.d/99-usbstorage.rules file, there are a few places I had to replace David with kberg (my username)

I included a script to do this for you.

rust collector wrote:Ok, Right now, I can not make it mount sd cards, I have to use the mountbox, which works fine.
Otoh, I think the card I have has issues, so I might try some stuff first.... but I would guess it should work, since I can mount them with m-box?

How are you using the sd card (internal slot, usb attachement, etc...)? I have an internal slot with an sd card formated to ext3.

Dave wrote:
I included a script to do this for you.

Sorry, but I had a slow moment... yep...you did...

Dave wrote: How are you using the sd card (internal slot, usb attachement, etc...)? I have an internal slot with an sd card formated to ext3.

The cards go in internal slots, and are"vfat"

I will dig out my wifes usb card reader, and test that too

Ok, a little update on the sd card issue...
I bought 2 new cards today, a kingston 32g class 10, and a generic 8g something.
None will automount, but show up in the list of connected devices in mountbox

They are both listed as"vfat"?
In gparted, they show up as fat32???

Just to try it, I got a new usb stick too, and it also show up as"vfat"

Formated the 8g card to ext3, and...nope...

Hmm, I wonder, does your mods work with just usb devices? as I think the card readers use some other bus(I think it is called bus?)

Ok, I finally found the wife's usb card reader, and the cable too!
The cards mount fine in that.
I have a feeling my internal card readers are somehow"different"

I found some stuff online

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://wiki.debian.org/DebianAcerOne"
linktext was:"http://wiki.debian.org/DebianAcerOne"
====================================

I cut the card reader parts, and posted here.

I don't know if you can make sense of this, but maybe?

And I guess I should say that it is not really a big issue anyway, as my cards are not swapped around a lot, so mounting them myself is fine. If it works on other machines, that is...


Card reader

Follow the relevant section depending on your BIOS version. To check your BIOS version, reboot your Aspire One and enter the BIOS before the OS boots to display the version string. (Press the F2 key right after boot to enter the BIOS.)

Pre-BIOS v.3309

The card reader is a J-Micron device. The left hand port (marked as storage expansion) exists as PCI ID 197b:2382, and the multi-reader on the right occupies PCI IDs 197b:2381, :2383 and :2384.

The card reader is hidden on power up and cold reset. There is no way to unhide the device without inserting a card into it (despite any claims elsewhere). The device appears to the host system when a card is inserted into either of the slots, at which point both left hand and right hand slots appear.

Many guides suggest using"setpci -d 197b:2381 AE=47" to unhide the device. This will ordinarily not work, because if the device does not appear to the host system, then the command will fail.

A script to poll the card reader for power events (AC unplugged, etc.) is included on the recovery DVD shipped with the machine within the"hdc1._.tar.bz2" archive as /usr/sbin/jmb38x_d3e.sh. This script runs once every 5 minutes and adjusts the power level depending on the system power state.

The simplest way to activate both card slots is to create a file /etc/modprobe.d/aspire-fix-sd-slots.conf with the following contents:

options pciehp pciehp_force=1 pciehp_slot_with_bus=1
install sdhci for i in 2381 2382 2383 2384; do /usr/bin/setpci -d 197b:$i AE=47; done; /sbin/modprobe --ignore-install sdhci

Then add the following line to /etc/modules:

pciehp

The 'pciehp' module will allow the card slots to appear as hotplug devices. Once a card is inserted, the 'install' line in the modprobe configuration will set the controller up to behave appropriately, and then load the sdhci driver. hal should spot the cards being inserted, and either GNOME or KDE should automatically mount the cards when inserted.

BIOS v.3309 and later

(This text may apply to earlier BIOS versions - as I recall, this was working in this fashion in BIOS v.3308, possibly earlier revisions. Ensure you are running the latest BIOS Acer have provided.)

This Aspire One BIOS no longer requires the above hacks to reprogram the SD controller's register 0xAE to 0x47, nor does it require the pciehp module to hotplug the controller when a card is inserted. In fact, they reveal the controller during system startup and set the register to support SDHCI mode during the system boot process.

As such, if you're running this BIOS version or newer, you can go ahead and ignore everything above and even back out the changes you made if you're already using Debian on your Aspire One.

Memory stick disabling

The current testing and unstable kernels have trouble with memstick modules causing a soft lockup (related to the memory stick part of the multi-reader). It is advised that the modules for this are blocked. Debian bug 500058 has been raised for this issue.

This issue will cause your system to lock up during udev startup if you have an SD card in the slot.


========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://www.nabble.com/Debian-netbook-aspire-one-td1914 1623.html"
linktext was:"http://www.nabble.com/Debian-netbook-as ... 41623.html"
====================================
gives a solution to repair the situation. Modifying the path so that it does not cause configuration file conflicts with module-init-tools, create a file /etc/modprobe.d/aspire-blacklist-memstick.conf with the following contents:

blacklist jmb38x_ms
blacklist memstick

There is no need to adjust the udev configuration, contrary to the instructions at nabble.com.

I noticed that Wallpaper.py chrashes when one uses backgrounds with names that contains white spaces, like Sakasa's 'Antix in Ice Glass' (very nice, by the way). It's hard to get Wallpaper.py going again, it gets stuck.

Hannes Worst - you are right. And I don't know how to fix this either. I guess I should advise users to make sure there is no white space in the name of the wallpaper.

I can't get Wallpaper.py going again either.

I have just tried this, and yes there is for sure a problem.
I think I may have fixed it in the newer version I have been working on, if you would like to give it a try you can download it at

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://www.daveserver.info/antiX/development/"
linktext was:"http://www.daveserver.info/antiX/development/"
====================================

The login-background.sh and wallpaper.py replace the current wallpaper.py, login_background.sh, and randwallpaper.sh.
The deb file is the same as the one in the repository with the above change. I hope it will install just as the one in the repository.

Dave - your newer version does fix the white space issue, but there are other issues.

1. You use antix-session/wallpaper whereas the old script uses /.wallpaper
2. The fluxbox/icewm startup files expect login_background.sh rather than the new login-background.sh
3. When setting a different wallpaper to rox-fluxbox and fluxbox, returning to a fluxbox desktop still keeps the rox pinboard.

I suggest, for now, to include the code that fixes the white space to the older wallpaper.py script and we can test the newer version after release.

The whitespace problem is from a lack of ("" ).
If your wallpaper.py is locked from opening edit,
~/.wallpaper/saved
from the image with whitespaces to one that contains no white spaces.

Problem patched on the older version (I think)
here is the download link

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://www.daveserver.info/antiX/development/wallpaper.py.orig"
linktext was:"http://www.daveserver.info/antiX/develo ... er.py.orig"
====================================

Dave

- just a quick message that the new script has issues when opening rox-wm. Gives an error about"failed to open /usr/share/wallpaper/Fancy" (File is called Fanchy Sky) ie the issue is now with rox and white space.

Added: The new wallper scripts do not have this issue, just the patched original and the original.

OK, should be fixed.
Same download location / file.