next »

[teapot]

You will need to go download one of the archives:
   jdk-6-doc.zip   jdk-6-doc-ja.zip
(Choose the non-update version if this is the first installation).
Please visit
   http://java.sun.com/javase/downloads/
now and download.  The file should be owned by root.root and be copied to /tmp

This what you should do to install that package, however Sun updated the file, and it's now  jdk-6u10-docs.zip ("Download" link under "Java SE 6 Documentation"). After downloading to desktop directory, run
mv ~/Desktop/jdk-6u10-docs.zip /tmp/jdk-6-doc.zip
and re-run the installer.

[phil4321]

I posted this to Moocapian's Ubuntu thread a few days ago but no reply.  This thread looks to be presently active with a consequent higher liklihood of a response so here it comes again.

I recently purchased and installed XOexplosion's Ubuntu SD card and initially it worked fine out of the box. While I was configuring the desktop display, however (via menus - not via terminal), the toolbar at the bottom of the screen suddenly disappeared and now I can't access my wifi connection to get on line.  XFCE seems to have taken over the desktop and I now have the XFCE mouse logo instead of the initial XOexplosion's Ubuntu logo on the applications menu.  XFXE's "wifi radar" recognizes local "hot spots" but doesn't let me connect to my own or other wifi sources (locked - lock and key symbols on the screen's LHS are greyed out) and I've been through the desktop config. menus several times trying unsuccessfully to find a fix.

Am I the only one with this problem?  Can anyone tell me what I should do to unlock wifi radar or, better still, get the original XOexplosion desktop back

[mavrothal]

I know about that problem -- it happens because of the method wxcam uses to estimate frame rate that it can achieve, so I have to change that.

I don't know if it is a matter of how or of when. When you do not record the estimated FPS is about double of the actual when you do record, maybe because the XO is slowing down under the additional work load. So the speedup is precisely the ratio of FPS-before/FPS-during recording.
Edit. I tested that. Running an application (eg find) before you start the recording so the frame rate will go down to ~10fps and stopping it immediately after you start recoding (where you get ~10fps without anything else running), the movie is OK.
It would appear that the problem is not "how" but "when" it estimates fps. So should come up with  some way to estimate frame rate during recording and not before.End of Edit.
I really have no idea where the relevant "line" is. All the relevant files look to be in binary instead of readable text. Would it be better identifiable if I get the source files?

[teapot]

I tested that. Running an application (eg find) before you start the recording so the frame rate will go down to ~10fps and stopping it immediately after you start recoding (where you get ~10fps without anything else running), the movie is OK.
It would appear that the problem is not "how" but "when" it estimates fps. So should come up with  some way to estimate frame rate during recording and not before.End of Edit.

Yes. The problem is, it assumes that it does not get slowed down by writing, so it tries to record at the rate it can't support, and does not detect the fact that it is actually slowed down. Running find causes enough I/O to slow down estimate, so it does not try to record faster than it can write.

It's too late to estimate the rate once recording is started, so wxcam should either test actual writing speed or accept a configuration option that limits the rate. Possibly both -- measure once, record and use it for subsequent recordings.

[mavrothal]

It's too late to estimate the rate once recording is started, so wxcam should either test actual writing speed or accept a configuration option that limits the rate. Possibly both -- measure once, record and use it for subsequent recordings.

The first one does not look simple... but should be some simple way to make it "obey" the frame rate set in .wxcam file. This would be a solution even if it requires some guessing and manual setting through the terminal.

[Noob-Bob]

Thanks Teapot, for helping me fix my Java problem.

Now I have a different one.  The M$ wireless mouse that I tried using (Laser mouse 6000), works fine for about 4 minutes, then it quits completely.  The light on the USB dongle goes out, and pushing buttons and trying to re-initialize doesn't do anything!  It doesn't matter if I am using it at the time, it just quits. The cursor is still on the screen, and the touchpad still works, but the mouse does not. 
I rebooted into Sugar, and it seems to work fine there, Abiword & Opera both.  Been working with it for a while, and it has not dropped. 
Thanks!  Great job on this build!

[wolf9545]

When the mouse disconnects while in Ubuntu can you unplug and re-plug in the usb adapter to get it to work again?

[mavrothal]

This relays to Intrepid to the extend that happen while I was using it, but I’ll post it here just the same…
While I was extracting an archive, the XO froze and I had to hard reset (after a few minutes waiting). This resulted in 2 problems.
1) The my Kingston 4GB class 6 SDcard got destroyed @:-(
Is not detected by the XO, Mac or PC and any of the recovery utilities, while my camera claims that is “locked” while the tab is at the unlock position. I can only assume that “is gone” but I would be happy to entertain any suggestions.
2) Strangely enough the internal NAND also got corrupted to the point I had to reflash from a (luckily) 5days-old backup image that worked OK.
Unfortunately when I tried to restore my Ubuntu from the 5days-old tar backup to a new SDcard, although I tar xvzif I get
gzip: stdin: invalid compressed data--format violated
tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now
right at my home directory :-(
I went through tar tutorials but couldn’t find anything that could help. Any suggestions would be greatly appreciated.

Some general infos. The card had ~ 300h of use with Hardy and Intrepid and harbored also a swap partition used for both Ubuntu and Sugar(?...). The XO has Firmware q2e27 (?...) and “aggressive” power management was on at the moment of the freeze (?...).

[BruceM]

I am  having a problem with the XO under Ubuntu 8.10 waking up from suspend sometimes (but not always). I open the lid and there is no sign of activity. Can't wake it up with any sort of keyboard input. If I push the power button, then it powers up and boots. This has happened with the power adaptor plugged in and not plugged in. I think it may happen when I have either just plugged or unplugged it before I open the lid, but I cannot swear to this (I am trying to pay more attention to the circumstances). Most of the time suspend/resume works fine, but I'm having this problem once or twice a day.

FWIW, I have the "slow power up" problem with my SD card (Patriot 8GB SDHC, PSF8GSDHC6). But it comes up fine if I tell it to "boot". Could this be related to my resume problem?

Thanks for any suggestions,
Bruce

[teapot]

This relays to Intrepid to the extend that happen while I was using it, but I’ll post it here just the same…
While I was extracting an archive, the XO froze and I had to hard reset (after a few minutes waiting). This resulted in 2 problems.
1) The my Kingston 4GB class 6 SDcard got destroyed @:-(
Is not detected by the XO, Mac or PC and any of the recovery utilities, while my camera claims that is “locked” while the tab is at the unlock position. I can only assume that “is gone” but I would be happy to entertain any suggestions.

You can try to re-format it, and if it fails, something probably is physically wrong with the card (or with its connector).

2) Strangely enough the internal NAND also got corrupted to the point I had to reflash from a (luckily) 5days-old backup image that worked OK.
Unfortunately when I tried to restore my Ubuntu from the 5days-old tar backup to a new SDcard, although I tar xvzif I get
gzip: stdin: invalid compressed data--format violated
tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now
right at my home directory :-(
I went through tar tutorials but couldn’t find anything that could help. Any suggestions would be greatly appreciated.

You have incomplete or corrupt backup file.

Some general infos. The card had ~ 300h of use with Hardy and Intrepid and harbored also a swap partition used for both Ubuntu and Sugar(?...).

Even though swap decreases the lifetime of SD card, it can only cause some sectors to become unreadable after they are written, so it may cause crash but not existing file corruption.

The symptoms look more like the result of backup card being removed or losing contact before system completed writing to it (this is why removable devices have "eject" or "unmount" option in file manager).

The XO has Firmware q2e27 (?...) and “aggressive” power management was on at the moment of the freeze (?...).

It's possible that resume delay was insufficient after something was already wrong with the card, and it did not respond, however I don't think, it is related to the original cause of failure.

[mavrothal]

I am  having a problem with the XO under Ubuntu 8.10 waking up from suspend sometimes (but not always). I open the lid and there is no sign of activity. Can't wake it up with any sort of keyboard input. If I push the power button, then it powers up and boots. This has happened with the power adaptor plugged in and not plugged in. I think it may happen when I have either just plugged or unplugged it before I open the lid, but I cannot swear to this (I am trying to pay more attention to the circumstances). Most of the time suspend/resume works fine, but I'm having this problem once or twice a day.

FWIW, I have the "slow power up" problem with my SD card (Patriot 8GB SDHC, PSF8GSDHC6). But it comes up fine if I tell it to "boot". Could this be related to my resume problem?

Thanks for any suggestions,
Bruce

It happens to me quite often too. I guess is because the script when is in the process of "ignoring" one signal (the power up or down) can not accept another (lid). Is related to timing. If you do it immediately is OK if you wait 3-5 secs the lid is ignored. Has nothing to so with the "slow" card.

You can try to re-format it, and if it fails, something probably is physically wrong with the card (or with its connector).

No luck. mount, fdisk, gparted etc can not open the device (/dev/sda or mmcblk0). I think is zapped to death somehow, but I do not know by what. The hard reset? I doubt it. Has happened many times with no problem.
Also, I agree is not the swap. Few days ago I had run "badblocks" on the card and had 0 (!)
Should be either the firmware (that has improvements to facilitate card behavior under windows) or just "machine revenge" because I do not think that the XO hardware is the best it can be... ;-D

You have incomplete or corrupt backup file.

Any magic command/option to rescue the good parts?

[teapot]

It happens to me quite often too. I guess is because the script when is in the process of "ignoring" one signal (the power up or down) can not accept another (lid). Is related to timing. If you do it immediately is OK if you wait 3-5 secs the lid is ignored. Has nothing to so with the "slow" card.

I have never seen that. The laptop WILL ignore keyboard and trackpad input while suspended unless it's suspended in "aggressive" mode (there is a lot of input that happens when lid is closed, so waking up will be counterproductive), and it waits for the user to unlock the screen before deciding to go back to sleep, however in no case it should get into condition when it reboots on power-up unless the battery is depleted while the box is asleep.

[teapot]

No luck. mount, fdisk, gparted etc can not open the device (/dev/sda or mmcblk0). I think is zapped to death somehow, but I do not know by what. The hard reset? I doubt it. Has happened many times with no problem.

If it can't be formatted either with SD slot or using SD to USB adapter (then it will be /dev/sda), something must be physically wrong. I am not sure what do you mean by hard reset -- there isn't much that can be done with SD card from its interface.

Any magic command/option to rescue the good parts?

Not if backup writing was interrupted, and they never were written onto the card in the first place.

[mavrothal]

I have never seen that. The laptop WILL ignore keyboard and trackpad input while suspended unless it's suspended in "aggressive" mode (there is a lot of input that happens when lid is closed, so waking up will be counterproductive), and it waits for the user to unlock the screen before deciding to go back to sleep, however in no case it should get into condition when it reboots on power-up unless the battery is depleted while the box is asleep.

No it does not reboot. You just open it up and is in the process of going back to sleep. If you press the power button then it wakes up. In my case it has "aggressive" on and "lid-without-password" so does not wait for passwd.
Test case: aggressive on, lid-without-password, power plug on, close lid to suspend. While is suspension, remove the power plug and in 2-3 sec open the lid (timing may vary). It remains in suspension.

I am not sure what do you mean by hard reset -- there isn't much that can be done with SD card from its interface.

Hard reset= Keep the power button pressed till it goes off.

Not if backup writing was interrupted, and they never were written onto the card in the first place.

I always make sure that tarring finishes without errors, but not always validate the backup to make sure... I will now!

[teapot]

Test case: aggressive on, lid-without-password, power plug on, close lid to suspend. While is suspension, remove the power plug and in 2-3 sec open the lid (timing may vary). It remains in suspension.

This is normal. Removing power plug is supposed to wake up but should be ignored, so laptop wakes up, waits few seconds and suspends again. If you open it while it's happening, scripts' limitations won't allow it to notice that something happened while it was awake. I should fix it in the next version (that will be in C, so it will be able to process multiple forms of input simultaneously).

I am not sure what do you mean by hard reset -- there isn't much that can be done with SD card from its interface.

Hard reset= Keep the power button pressed till it goes off.

That's forced power off, it doesn't do anything regular shutdown doesn't (but it does not flush the buffers, so filesystem may need recovery or even be incomplete).

Not if backup writing was interrupted, and they never were written onto the card in the first place.

I always make sure that tarring finishes without errors, but not always validate the backup to make sure... I will now!

Verification does nothing if the card is still in, it just reads the buffer in memory that may or may not actually be on the card. You have to wait for file manager to unmount/eject the card, or run sync in the terminal, or wait for shutdown to complete -- all those things actually wait for physical writing to complete.