next »

[markhadman]

[PROBLEM (mostly) SOLVED, see bottom of post]

I'd like to add a new user with sudo privileges (because my name isn't olpc!). The first time around, I tried to be clever and used the command line tools to change the user olpc to myname and I ended up trashing my installation by losing all access to sudo, even though I made sure my 'new' user was in the group sudo.

Second time around I've installed the graphical users-admin (part of the gnome-system-tools package). The thing is, user olpc doesn't even show up in users-admin, and there's no sudo or admin group to add my new user to. Why doesn't the user olpc appear in users-admin? By what magic does olpc have access to sudo? And how do I give sudo privileges (which group)?

In short, why doesn't it work like it should? Waaaah!


Other than that, I'm glad I finally tried Ubuntu on my XO! For comparison - OLPC/8.2.0 is an improvement but it's still got that stupid sugar journal filename hashing (yeah, it's THAT big a deal), DebXO is effortlessly brilliant except there's no power management or screen rotate, and Fedora 10 was just an epic fail.

EDIT:
OK, I fixed it. I went back to the command line and did :

Code:

sudo usermod -aG sudo myname

The questions remain though - why doen't user olpc or group sudo show up in users-admin? Is this something peculiar to this installation?

[richf]

Mavrothal:

With the OFW q2e24 in place, Ubuntu Intrepid on a 8GB PNY class 6 card failed to boot, with the following error:

   SDHCI :  Error : ISR=8000 ESR=1 Command Timeout,
   Stopping
   <buffer@ffb66ee0>:12:
   Cant open boot device
   OK

Any other thoughts?

Unfortunately, the XO still "doesn't play very well with SD cards"!!

Did you ever get this resolved?  I just tried installing Ubuntu Intrepid following these instructions, onto a Patriot 16 GB Class 6.  Things went mostly fine, although the reboot didn't fully reboot, I'm pretty sure it was hung (I waited a while), so I rebooted by hand with the power button.  The SD card is still in, and now trying to power up for the first time, I get:

---
Type the Esc key to interrupt automatic startup
ext3 journal needs recovery
Boot device: /sd/disk:\boot\olpc.fth  Arguments:
Boot device: /sd/disk:\boot\vmlinuz  Arguments: ro root=/dev/mmcblk0p1 rootfstype=ext3 console=tty0 fbcon=font:SUN12x22 video=fb:1200x900 loglevel=3 splash
SDHCI: Error: ISR = 8000 ESR = 10 Data Timeout,
Stopping
<buffer@ffb9168>:12:
Can't open boot device

Type 'help' for more information.

ok
---

I hope that this SD card isn't another problematic one.  I spent a long time agonizing over which to purchase, based on somewhat conflicting reports.

[richf]

I just tried installing Ubuntu Intrepid following these instructions, onto a Patriot 16 GB Class 6.

I hope that this SD card isn't another problematic one.  I spent a long time agonizing over which to purchase, based on somewhat conflicting reports.

A bit more information...

On both a different laptop (ThinkPad running Debian etch) and the XO running Sugar, I can:
- run fdisk and the output makes sense (one big partition of type 83)
- run fsck on the partition (/dev/sda1) and it (quickly) reports all clean
- Mount the SD card fine using a USB card reader, and see what looks like / from a normal linux install.  Including the following in /boot:

Code:

helsinki:/media/OLPCRoot/boot# ls -alF
total 13104
drwxr-xr-x  2 root root    4096 Nov 29 03:02 ./
drwxr-xr-x 22 root root    4096 Nov 29 01:33 ../
-rw-r--r--  1 root root  925970 Nov  1 21:21 System.map-2.6.25-20080925.1.olpc.f10b654367d7065
lrwxrwxrwx  1 root root       6 Apr  5 21:19 actos.zip -> os.zip
lrwxrwxrwx  1 root root       6 Apr  5 21:19 actrd.zip -> rd.zip
-rw-r--r--  1 root root 1048724 Sep 22  2008 bootfw.zip
-rw-r--r--  1 root root   54763 Nov  1 21:20 config-2.6.25-20080925.1.olpc.f10b654367d7065
-rw-r--r--  1 root root     441 Nov 28 23:06 olpc.fth
-rw-r--r--  1 root root 2697178 Nov  1 21:25 olpcrd-2.6.25-20080925.1-modified.img
-rw-r--r--  1 root root 2711082 Nov  1 21:21 olpcrd-2.6.25-20080925.1.olpc.f10b654367d7065.img
lrwxrwxrwx  1 root root      37 Apr  5 21:19 olpcrd.img -> olpcrd-2.6.25-20080925.1-modified.img
-rw-r--r--  1 root root 1603902 Sep 22  2008 os.zip
-rw-r--r--  1 root root 2710204 Sep 22  2008 rd.zip
lrwxrwxrwx  1 root root       6 Apr  5 21:19 runos.zip -> os.zip
lrwxrwxrwx  1 root root       6 Apr  5 21:19 runrd.zip -> rd.zip
lrwxrwxrwx  1 root root      46 Apr  5 21:18 vmlinuz -> vmlinuz-2.6.25-20080925.1.olpc.f10b654367d7065
-rw-r--r--  1 root root 1603804 Nov  1 21:21 vmlinuz-2.6.25-20080925.1.olpc.f10b654367d7065
helsinki:/media/OLPCRoot/boot#

So I think the card itself is likely fine, but the XO isn't able to boot from it when it's in the SD card slot. 

Can you use the SD card slot as a non-boot device?  Or does it always try to boot from it.  I'm wondering if I can just try mounting the card in there otherwise.  I'm not sure if it's wise to plug and unplug into the slot while the machine is running.  I'm not used to a machine that has a direct SD card slot (as opposed to using a card reader and USB).

- Rich

[richf]

Can you use the SD card slot as a non-boot device?  Or does it always try to boot from it.  I'm wondering if I can just try mounting the card in there otherwise.  I'm not sure if it's wise to plug and unplug into the slot while the machine is running.  I'm not used to a machine that has a direct SD card slot (as opposed to using a card reader and USB).

So I got it to boot from the regular flash with the SD card inserted, by interrupting the boot cycle and by hand specifying the boot location.  Or maybe this could have been as easy as just inserting the SD card after boot; I'm still just not positive whether or not that's safe.

Anyway, I'm typing this now from the XO (Sugar/Opera), and it was able to automount the SD card just fine:

Code:

[olpc@xo-14-32-66 OLPCRoot]$ df -h
Filesystem            Size  Used Avail Use% Mounted on
mtd0                  1.0G  933M   92M  92% /
tmpfs                  35M     0   35M   0% /dev/shm
/dev/mmcblk0p1         15G  1.1G   13G   8% /media/OLPCRoot
[olpc@xo-14-32-66 OLPCRoot]$ ls -alF
total 112
drwxr-xr-x  22 root root  4096 2008-11-29 17:33 ./
drwxr-xr-x   3 root root   100 2009-04-06 15:01 ../
drwxr-xr-x   2 root root  4096 2008-11-29 17:33 bin/
drwxr-xr-x   2 root root  4096 2008-11-29 19:02 boot/
drwxr-xr-x   4 root root 20480 2008-11-29 17:32 dev/
drwxr-xr-x 107 root root  4096 2008-11-29 17:38 etc/
drwxr-xr-x   3 root root  4096 2008-11-29 17:33 home/
drwxr-xr-x  14 root root  4096 2008-11-29 17:33 lib/
drwx------   2 root root 16384 2009-04-06 12:16 lost+found/
drwxr-xr-x   3 root root  4096 2008-11-29 17:33 media/
drwxr-xr-x   2 root root  4096 2008-10-20 20:27 mnt/
drwxr-xr-x   2 root root  4096 2008-11-29 17:33 ofw/
drwxr-xr-x   2 root root  4096 2008-11-29 17:08 opt/
drwxr-xr-x   2 root root  4096 2008-10-20 20:27 proc/
drwxr-xr-x   4 root root  4096 2008-11-29 17:11 root/
drwxr-xr-x   2 root root  4096 2008-11-29 17:33 sbin/
drwx------   2 root root  4096 2009-04-06 13:29 security/
drwxr-xr-x   2 root root  4096 2008-11-29 17:08 srv/
drwxr-xr-x   2 root root  4096 2008-10-14 21:02 sys/
drwxrwxrwt   4 root root  4096 2008-11-29 17:33 tmp/
drwxr-xr-x  11 root root  4096 2008-11-29 17:14 usr/
drwxr-xr-x  14 root root  4096 2008-11-29 17:17 var/
[olpc@xo-14-32-66 OLPCRoot]$ ls -alF boot
total 13104
drwxr-xr-x  2 root root    4096 2008-11-29 19:02 ./
drwxr-xr-x 22 root root    4096 2008-11-29 17:33 ../
lrwxrwxrwx  1 root root       6 2009-04-06 12:19 actos.zip -> os.zip
lrwxrwxrwx  1 root root       6 2009-04-06 12:19 actrd.zip -> rd.zip
-rw-r--r--  1 root root 1048724 2008-09-23 06:06 bootfw.zip
-rw-r--r--  1 root root   54763 2008-11-02 12:20 config-2.6.25-20080925.1.olpc.f10b654367d7065
-rw-r--r--  1 root root     441 2008-11-29 15:06 olpc.fth
-rw-r--r--  1 root root 2697178 2008-11-02 12:25 olpcrd-2.6.25-20080925.1-modified.img
-rw-r--r--  1 root root 2711082 2008-11-02 12:21 olpcrd-2.6.25-20080925.1.olpc.f10b654367d7065.img
lrwxrwxrwx  1 root root      37 2009-04-06 12:19 olpcrd.img -> olpcrd-2.6.25-20080925.1-modified.img
-rw-r--r--  1 root root 1603902 2008-09-23 06:06 os.zip
-rw-r--r--  1 root root 2710204 2008-09-23 06:06 rd.zip
lrwxrwxrwx  1 root root       6 2009-04-06 12:19 runos.zip -> os.zip
lrwxrwxrwx  1 root root       6 2009-04-06 12:19 runrd.zip -> rd.zip
-rw-r--r--  1 root root  925970 2008-11-02 12:21 System.map-2.6.25-20080925.1.olpc.f10b654367d7065
lrwxrwxrwx  1 root root      46 2009-04-06 12:18 vmlinuz -> vmlinuz-2.6.25-20080925.1.olpc.f10b654367d7065
-rw-r--r--  1 root root 1603804 2008-11-02 12:21 vmlinuz-2.6.25-20080925.1.olpc.f10b654367d7065
[olpc@xo-14-32-66 OLPCRoot]$

So it can read the SD card, it just can't boot off of it.  Could this perhaps be as simple as adding some boot option?  Or is that just wishful thinking...

- Rich

[richf]

So it can read the SD card, it just can't boot off of it.

And here I can see that it can read all of the bits off of every file in /boot, since it has to be able to read them all for an md5sum, and I see no evidence of any kind of read errors reported.

- Rich

Code:

[olpc@xo-14-32-66 boot]$ find . -type f | xargs md5sum
a5db3e6e7232855f28725a461ce73179  ./os.zip
abeab3fd42bce62c6c7f4c97021c28c4  ./olpcrd-2.6.25-20080925.1-modified.img
d9c1d76b67c8f1e022c130e73ad9a43f  ./System.map-2.6.25-20080925.1.olpc.f10b654367d7065
dfcaafcf1b8c7a89b89a5e8b12b13d32  ./olpc.fth
87040fe8523c682133c9cbbc28932067  ./olpcrd-2.6.25-20080925.1.olpc.f10b654367d7065.img
925d1572f7c8a92694301878f513dd84  ./config-2.6.25-20080925.1.olpc.f10b654367d7065
11a258bde8d19ff81b38ab5dda3f3531  ./bootfw.zip
77347e02ad3958c5e78c9f01e5dcf2fa  ./vmlinuz-2.6.25-20080925.1.olpc.f10b654367d7065
091a3e0d4d14e4799933a257cccf2e41  ./rd.zip
[olpc@xo-14-32-66 boot]$

[richf]

A little more info (sorry for taking up all of these posts in a running commentary, but I keep thinking I'm giving up for the night and then try one more thing that might contain helpful info...)

Anyway, I tried `test /pci/sd` at boot time, which I got from here:

http://n2.nabble.com/XO%3A-SDHCI%3A-Card-didn't-power-up-after-1-second-tt1379903.html#a1490348

And here's the result:

Code:

ok test /pci/sd
SDHCI: Error: ISR = 8000 ESR = 10 Data Timeout,
Stopping
No selftest method for /pci/sd
ok

So I decided to try again:

Code:

ok test /pci/sd

And now at this point it appears hung ...

[richf]

A little more info (sorry for taking up all of these posts in a running commentary, but I keep thinking I'm giving up for the night and then try one more thing that might contain helpful info...)

One more for the evening...

I searched around a bit and found various other threads for various other purposes that mention similar errors.  Here are a few pointers:

http://en.forum.laptop.org/viewtopic.php?f=2&t=3540&p=594654#p594654
(thread echo'd here: http://lists.laptop.org/pipermail/community-support/2008-January/001517.html)

https://dev.laptop.org/ticket/9147#comment:4
(bug echo'd here: http://lists.laptop.org/pipermail/bugs/2008-December/093472.html)

http://en.forum.laptop.org/viewtopic.php?f=1324&t=170624&p=594664#p594664

http://n2.nabble.com/XO%3A-SDHCI%3A-Card-didn't-power-up-after-1-second-tt1379903.html#a2591885

[richf]

So I decided to try again:

Code:

ok test /pci/sd

And now at this point it appears hung ...

Following this, the previous contents of the card seem to be hosed.  I can no longer mount it, and the partition table is empty:

Code:

helsinki:~# fdisk /dev/sda
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won't be recoverable.


The number of cylinders for this disk is set to 15388.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

Command (m for help): p

Disk /dev/sda: 16.1 GB, 16135487488 bytes
64 heads, 32 sectors/track, 15388 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes

   Device Boot      Start         End      Blocks   Id  System

Command (m for help): 

I'll have to see tomorrow if I've really totally hosed the card, or if I just need to start over.  (I'm assuming the later...)

- Rich

[mavrothal]

Rich

The card is on /dev/mmcblk0 if in the slot, not /dev/sda
Is OK to insert  the card while running but better 'umount' it from the terminal before you remove it.
If you want to boot to sugar with the card in, have the triangle game key press while you power up.
Update to a newer firmware
Try this: press <esc> key while booting to get to the OFW 'ok' prompt. Go get  a coffee. Come back and type 'boot'. If you boot to Ubuntu you have a hope if not (and you are absolutely sure that everything else is OK with the installation-eg do it over cerefully) get a new card... some cards will simply not play on the XO.
Before you "dump" it you may want to try some SD card formatting utility and fully erase (including flash) and reformat it.

[richf]

The card is on /dev/mmcblk0 if in the slot, not /dev/sda

Yes, I realize that.  Some of my testing is using another computer, to verify that the issue is really the card, and not the XO.  In that fdisk output, I had the card in another computer using a USB card reader.

I tried it directly in the XO at /dev/mmcblk0, and there's still no partition table.

Is OK to insert  the card while running but better 'umount' it from the terminal before you remove it.

That's good to know.  (Although currently I can't mount it, to need to umount it.)

If you want to boot to sugar with the card in, have the triangle game key press while you
power up.
Update to a newer firmware
Try this: press <esc> key while booting to get to the OFW 'ok' prompt. Go get  a coffee. Come back and type 'boot'. If you boot to Ubuntu you have a hope if not (and you are absolutely sure that everything else is OK with the installation-eg do it over cerefully) get a new card... some cards will simply not play on the XO.

Well right now it does seem to be hosed, so my immediate next step is going to be just try again starting over, doing the same process with the same card.

I've heard mixed reviews of various cards.  I decided to buy Patriot instead of A-Data based on some positive reviews.  So I wonder if it's just a bit random and that you can't count on any particular card working or not, since there seem to be multiple conflicting pro and con reports.

Before you "dump" it you may want to try some SD card formatting utility and fully erase (including flash) and reformat it.

Unfortunately, that seems to require Windows.  If all else fails I'll try that with someone else's machine.

Thanks for your advice.

- Rich

[richf]

Try this: press <esc> key while booting to get to the OFW 'ok' prompt. Go get  a coffee. Come back and type 'boot'. If you boot to Ubuntu you have a hope if not (and you are absolutely sure that everything else is OK with the installation-eg do it over cerefully) get a new card... some cards will simply not play on the XO.

I tried the instructions again.  This time the only differences were:

- I unmounted the SD card before rebooting.  This time it rebooted cleanly.  I don't know if that was related or not.
- I didn't bother to `touch /mnt/etc/xo-suspend/aggressive` this time, but I doubt that's relevant at this stage.

It also may be worth noting that the instructions `cp /security/* security/` do not copy the subdirectory (I think it's called `state`).  Is this intentional?  Should it be a `cp -a` ?

Anyway, same results.  Same error upon rebooting.  So I tried rebooting again and escaped to the ok prompt.  Let it sit there for 20 minutes.  Same result.

Update to a newer firmware

Before you "dump" it you may want to try some SD card formatting utility and fully erase (including flash) and reformat it.

So I'm trying to decide which of these to try next.  Wrt the firmware, are some versions better than others (like are some beta?)  I see that q2e18 (what I have now) is listed as the 8.2.0 release version (what I have now).  Will q2e39 be any less stable?  And why q2e39 vs. the latest, which as of right now is q2f01?  Is just any *01 considered more risky, or is there some incompatability that would require 8.2.1?  And other than specific notes on the page like "Once you upgrade to the Q2Cxx series of firmware do not downgrade to Q2Bxx!", is there any danger of upgrading?  Can I always go back to q2e18 if things don't go well?

Thanks again for any help anyone can provide.

- Rich

[richf]

What about verifying the data integrity of the install?

I ran an md5sum on the original tar file when copying it to my smaller SD card (that I used via USB for the install), and it matched the md5sum of the file I downloaded via bittorrent:

Code:

77d33469f2ed1175f6f42e5221bf8d62  OLPCFiles-intrepid-20081130.tar.bz2

Is it listed somewhere what that ought to be?

But maybe a next better step would be to verify the integrity of the files copied onto the boot SD card, immediately after untar'ing, but before doing anything else.  Is there any way to do this in a single checksum, and/or anything to compare it to?  I suppose if nothing else, I could untar the file on my desktop and produce a sorted md5sum of all of the files there, then do the same for the untar'd copy on the XO (while still running Sugar and saving the results elsewhere), and then diff the results.

- Rich

[Richard Smith]

So I decided to try again:

Code:

ok test /pci/sd

And now at this point it appears hung ...

Following this, the previous contents of the card seem to be hosed.  I can no longer mount it, and the partition table is empty:

As you may have already found out your partition table is hosed.  Thats because:

Code:

ok test /pci/sd

writes a block of 0xa5's and 0x5a's to block 0 as the test.
The test first reads the data from block 0 and tries to restore it after its done but if you have an error in the middle then your block 0 is trashed.

test /pci/sd is not really what you want to be using as a power up test.

A simple "can I read the card" test would be to just list the directory of the sd card.  This will go through all the same power up sequence that test /pci/sd would but without the destructive write of block 0.
Instead use:

Code:

ok dir sd:

As mentioned in the bug report on dev.laptop.org you should first try q2e39 which is available here:

http://wiki.laptop.org/go/Firmware

Please update the bug with success or failure after you upgrade the firmware to q2e39 and try again.

[richf]

As mentioned in the bug report on dev.laptop.org you should first try q2e39 which is available here:

http://wiki.laptop.org/go/Firmware

Please update the bug with success or failure after you upgrade the firmware to q2e39 and try again.

Trying to upgrade gives:

Code:

ok flash n:\boot\q2e39.rom
Reading n:\boot\q2e39.rom
Got firmware versionL CL1   Q2E39  Q2E
Checking integrity ...
Firmware image has bad internal CRC
ok

This is from two separate attempts.

Fwiw, the md5sum of the file is as follows.  It would be nice if the wiki posted that to be able to ensure data integrity:

Code:

d876055752f134872a72f0610057b08a  q2e39.rom

[mavrothal]

Update to a newer firmware

So I'm trying to decide which of these to try next.  Wrt the firmware, are some versions better than others (like are some beta?)  I see that q2e18 (what I have now) is listed as the 8.2.0 release version (what I have now).  Will q2e39 be any less stable?  And why q2e39 vs. the latest, which as of right now is q2f01?  Is just any *01 considered more risky, or is there some incompatability that would require 8.2.1?  And other than specific notes on the page like "Once you upgrade to the Q2Cxx series of firmware do not downgrade to Q2Bxx!", is there any danger of upgrading?  Can I always go back to q2e18 if things don't go well?

q2e39 IS the latest firmware. q2f series is a currently inactive branch. The dates are a safer bet than the numbers since different branches go with different rates.
You can always go back to a previous firmware of the q2d series.
XO had always problems with SD cards and newer firmware (q2e24+) addresses some of it.
Your installation should be fine. You can try some cheap 2-4GB card and if it works you tar it and then "untar" it in your (formatted) 16GB card and see what happens. In general more problems are observed with bigger cards. 4GB cards (class 4 or 6) seems to be the best for space adequacy, minimal trouble and brand Independence

Trying to upgrade gives:

Code:
ok flash n:\boot\q2e39.rom
Reading n:\boot\q2e39.rom
Got firmware versionL CL1   Q2E39  Q2E
Checking integrity ...
Firmware image has bad internal CRC
ok

This is from two separate attempts.

That's another bug related to os767...
try the usb method instead of the internal NAND for the firmware update. It works fine.