next »

[teapot]

I guess, I am kinda late to this thread, but I just got a repeatable procedure to produce a usable initial Ubuntu installation, and did it with both Gutsy and Hardy.

1. I have re-traced steps necessary to prepare the file and image archives for Gutsy (OLPCFile.tar.bz2 /OLPCRoot.tar,bz2), except I didn't use emulator but ran the whole system in chroot starting from debootstrap (on a non-Ubuntu Linux, no less). This produced an equivalent of that system, except I didn't end up with files left from initialization of hardware, history and logs like in the original file (if anyone wonders why his wireless adapter is eth3, or what is "bunnyboy" wireless network that shows up as an option in Network Manager, this is where they are from, two first Ethernet interfaces are associated with MAC addresses of the initial installation box and XO used for development). Since I did everything in chroot on the development box, and passed edited files back from XO when I did any testing, I have produced a cleaner, easier to customize system. The problem is, it's just as huge as the original file, so I wonder, where should I place it.

2. Just a few minutes ago I have successfully produced a Hardy image using exactly the same procedure (plus switching back to sysv init from upstart because I initial ramdisk is not compatible with it now). What is especially nice, Hardy version of X is compatible with AMD driver that comes with the original laptop system (even though Geode driver that comes with Hardy does not work on XO, and should be replaced with "native" one). I still have to produce a repeatable build procedure and tweak the initial set of packages, but at this point it works.

3. I have switched to gdm as a way to start X. It's a bit or more bloat, but it means nice login screens, automatic/timed login if necessary, etc. And entirely within the configuration that comes natively with Ubuntu. Most software uses weird default font sizes unless X is forced to assume 100dpi resolution (real resolution is more than 200dpi). In Xfce configuration it's done with command line argument, however since I didn't want to mess with gdm configuration, I just set it in xorg.conf ("DisplaySize 304 228" instead of "DisplaySize 152 114").

4. I made changes to boot scripts to reduce boot-time screen clutter. Basically, I added a script to unfreeze the screen so it shouldn't be unfrozen in bootloader, removed things that never work on XO, set font to Sun console (same as the bootloader) and left it at that, and changed kernel log level to 3, so it won't send messages about progress and autodetection or non-fatal errors that happen in the boot process to the console (they are still available through dmesg or in logs). I have also added Network Manager shutdown after network shutdown and before dbus shutdown, so it won't print a massive meaningless error message on shutdown. I have also noticed that most of boot time is eaten in waiting for udev to process everything, even though most of that time it's doing nothing. I think, I can find a way to get it to do it faster -- initial set of hardware does not change.

Now my question is, where can I put the massive files for that? I can host minor things, like archives of patches and installer scripts, however unless people have time and space to run debootstrap (I guess, it can be done on a laptop itself, never tested it there), it will be easier to post files just like the original configuration.

[Eddie Owens]

When I use Synaptic Package Manager in XFCE/Xubuntu, I can download a package as evidenced by the fact that I can find the files using the file manager, and click on them and they run appropriately.

But how do you make those packages appear in the in the drop-down menus that are part of XFCE, and run them from those menus?

[StewieGriffin]

I guess, I am kinda late to this thread, but I just got a repeatable procedure to produce a usable initial Ubuntu installation, and did it with both Gutsy and Hardy.

1. I have re-traced steps necessary to prepare the file and image archives for Gutsy (OLPCFile.tar.bz2 /OLPCRoot.tar,bz2), except I didn't use emulator but ran the whole system in chroot starting from debootstrap (on a non-Ubuntu Linux, no less). This produced an equivalent of that system, except I didn't end up with files left from initialization of hardware, history and logs like in the original file (if anyone wonders why his wireless adapter is eth3, or what is "bunnyboy" wireless network that shows up as an option in Network Manager, this is where they are from, two first Ethernet interfaces are associated with MAC addresses of the initial installation box and XO used for development). Since I did everything in chroot on the development box, and passed edited files back from XO when I did any testing, I have produced a cleaner, easier to customize system. The problem is, it's just as huge as the original file, so I wonder, where should I place it.

2. Just a few minutes ago I have successfully produced a Hardy image using exactly the same procedure (plus switching back to sysv init from upstart because I initial ramdisk is not compatible with it now). What is especially nice, Hardy version of X is compatible with AMD driver that comes with the original laptop system (even though Geode driver that comes with Hardy does not work on XO, and should be replaced with "native" one). I still have to produce a repeatable build procedure and tweak the initial set of packages, but at this point it works.

3. I have switched to gdm as a way to start X. It's a bit or more bloat, but it means nice login screens, automatic/timed login if necessary, etc. And entirely within the configuration that comes natively with Ubuntu. Most software uses weird default font sizes unless X is forced to assume 100dpi resolution (real resolution is more than 200dpi). In Xfce configuration it's done with command line argument, however since I didn't want to mess with gdm configuration, I just set it in xorg.conf ("DisplaySize 304 228" instead of "DisplaySize 152 114").

4. I made changes to boot scripts to reduce boot-time screen clutter. Basically, I added a script to unfreeze the screen so it shouldn't be unfrozen in bootloader, removed things that never work on XO, set font to Sun console (same as the bootloader) and left it at that, and changed kernel log level to 3, so it won't send messages about progress and autodetection or non-fatal errors that happen in the boot process to the console (they are still available through dmesg or in logs). I have also added Network Manager shutdown after network shutdown and before dbus shutdown, so it won't print a massive meaningless error message on shutdown. I have also noticed that most of boot time is eaten in waiting for udev to process everything, even though most of that time it's doing nothing. I think, I can find a way to get it to do it faster -- initial set of hardware does not change.

Now my question is, where can I put the massive files for that? I can host minor things, like archives of patches and installer scripts, however unless people have time and space to run debootstrap (I guess, it can be done on a laptop itself, never tested it there), it will be easier to post files just like the original configuration.

Fantastic work!

Try rapidshare or megaupload to host your files.  If that doesn't work, I'm sure we can find someone here who can help seed a torrent.  (I can seed, but I am on the road this week)

[teapot]

Update: new version of the tarball is at http://mars.illtel.denver.co.us/~abelits/torrents/OLPCFiles-hardy-20080506.tar.bz2.torrent

Files used in this build are in http://mars.illtel.denver.co.us/~abelits/software/olpc/olpc-ubuntu-hardy-update-files-20080506.tar.gz
End of update

I made a usable Ubuntu 8.04 (Hardy) filesystem -- it's prerelease version, so please test at your own risk:

Old Torrent is: http://mars.illtel.denver.co.us/~abelits/torrents/OLPCFiles-hardy-prerelease.tar.bz2.torrent


Photos of the whole sequence performed on a XO (with all edited parts taken into account): http://mars.illtel.denver.co.us/~abelits/images/olpc-ubuntu/

To install on a blank SD card (what the archive is primarily for):

Edit: The whole installation procedure should be performed as root -- run sudo -s if you are logged in as a normal user.

 If you do that on XO, you may have to disable hal daemon to prevent it from trying to mount the device while you are working on it. Run /etc/init.d/haldaemon stop to disable it (/etc/init.d/haldaemon start to enable it again if you will need it before rebooting).

Note:If you use SD card or USB drive that was previously used as a non-partitioned device, it's possible to create a very confusing partition/superblock structure, where a seemingly valid superblock sits right before just as valid partition table that in its turn points to another, real superblock (I just did that in the course of my experiments with installation on different media types). If you used SD card/disk as a non-partitioned device before, do this:
/etc/init.d/haldaemon stop <- if you haven't done this already
umount /dev/mmcblk0p1  <- most likely fails
umount /dev/mmcblk0 <- it might succeed if filesystem was still readable, so hal picked it up
dd if=/dev/zero of=/dev/mmcblk0 bs=4096 count=1 <- if you do this with a wrong device, you will REALLY hate the result

before running fdisk.
End of edit
Edit #2:
Another installing-on-XO issue: XO may go into a powersaving  mode and disconnect SD card while tar is writing to it. This happened in my test when I was extracting files from a tarball, and destroyed the filesystem. To prevent this from happening. run
touch /etc/ohm/inhibit-suspend
at the same point when you disable hal.

To enable it again later, just delete the file:
rm /etc/ohm/inhibit-suspend

This is only necessary if you are using XO itself to make the boot card/disk.
End of edit #2

1. Unmount SD card if it was mounted.

2. Make sure that SD card has first partition configured. Use fdisk to create a single primary partition number 1, with type 83 (Linux). When working on XO SD card will look like /dev/mmcblk0 device, when working on a desktop it's more likely will be /dev/sda or /dev/sdb (be careful not to format your hard drive instead of the card).

fdisk /dev/mmcblk0  <- please note that this is the whole device, not a partition

At the prompt enter p

fdisk will show partitions -- remove and/or create partitions as needed, change type with t command to 83, save the changes with w.

Edit: On XO you may have to reboot at this point if fdisk will complain about kernel not re-reading the new partition table. After rebooting you will still have to disable hal and unmount the device if it was mounted.
End of edit

3. Create ext3 partition on the first partition, set label name to "OLPCRoot":

mke2fs -j -L OLPCRoot /dev/mmcblk0p1 <- this is a partition device, note the "p1" (or "1" for sda) at the end of device name.

4. Create a directory and mount the filesystem:

mkdir /media/OLPCRoot
mount /dev/mmcblk0p1 /media/OLPCRoot

(or use desktop / file manager's mounting function).

Edit: If you use desktop file manager's mounting function, make sure that the device is not mounted with some reduced permissions, or with remapped users (output of mount does not show any options other than "rw" for that device). This may affect how files are created on it when tarball is extracted.
End of edit

5. Download the tar archive. Place it on the same, or other drive (it's large, 236M, and it expands into 712M). You can put it on another USB disk that will be mounted, say, at "/media/disk".

6. Change to the root directory of the mounted filesystem and extract the tar file:
cd /media/OLPCRoot
tar xvjf /media/disk/OLPCFiles-hardy-prerelease.tar.bz2 (or whatever its location is).

For safety reasons, please note that all further copying/editing operations have target relative to the current directory,  so destination never starts with a slash. Source is relative to the root filesystem of XO (so source always starts with a slash), or a copy of it (if so, substitute the leading slash with an appropriate path).

7. Copy /security directory with developer key (on XO, or from a copy):

cp -a /security .

8. Copy boot directory, preserving the olpc.fth file:

cp -ia /boot/* boot/ </dev/null <- it will show the question about overwriting olpc.fth, /dev/null at the input will not confirm.

9. Copy kernel modules and firmware

cp -a /lib/modules/* lib/modules/
cp -a /lib/firmware/* lib/firmware/

10. At this point you may have to edit etc/fstab and boot/olpc.fth files to match your actual boot device. If the device is a USB disk, replace /dev/mmcblk0p1 in etc/fstab and boot/olpc.fth with /dev/sda1, and sd:\ with disk:\ in boot/olpc.fth. For SD card leave the names alone, even if you actually used different device name while installing on a non-XO box (say, with a USB SD adapter).

11. Change to the root directory and unmount the card:

cd /
umount /media/OLPCRoot

(or use whatever mounting interface you have on a Linux desktop that you used to mount it).

Wait for unmounting to complete -- flash cards take time to flush all data from buffers, so most likely umount utility will not exit instantly, and desktop will keep the message on until the drive is safe to remove.

12. Boot XO with the card inserted.

It should boot into gdm login screen and show "OLPC User" as the only entry in the user list. Select it or enter "olpc", pasword is "olpcolpc" (change it before enabling any networked services such as ssh server).

If you keep using this system, don't forget to run system upgrade once Hardy is released -- packages are still being updated on Ubuntu servers. In terminal:

sudo aptitude

Update is u (downloads lists of packages), actual upgrade is U (capital) then g

Technical notes:

This set of files was produced from debootstrap with the current Ubuntu Hardy packages. It includes changes made in files mentioned in http://olpcnews.com/forum/index.php?topic=1435.0  , plus more updates and a different set of packages (Gutsy dependencies don't translate cleanly into Hardy for such a minimal set of packages). SysV init is restored in place ot upstart for now -- this makes it compatible with OLPC ramdisk images. Geode driver is from OLPC binaries as well.

[JoeMac]

Teapot - thanks for putting up the Hardy torrent and for working on the fine tuning.  Would you be willing to put up a Gutsy torrent, too?

[teapot]

Yes, I can make the same installation configuration for Gutsy. I just thought, it's more important to let people test Hardy changes and debug/polish/provide packaging for it, because Hardy will be released in two days, becoming new LTS, including sugar in universe, and other nice things. Then I can issue completely compatible backport to Gutsy, just to see how small it can get, but avoiding any Gutsy-specific things that I would have to support separately.

Right now I can rebuild and upload a Gutsy configuration, but I can't promise to support it in the form it exists now.

[Eddie Owens]

I am having the same problem as ritibelle (April 16) with the failure of Synaptic to run ("...unable to copy user's authorization file"), and  when I do "xauth generate $DISPLAY .trusted", the feedback indicates that it is trying to create an .Xauthority file, but I got:

"SecurityBadAuthorizationProtocol (invalid authorization name or data) xauth: (argv):1: couldnt generate authorization"

And "sudo xauth generate $DISPLAY .trusted" generates the same error message.

As I indicated earlier, I can do "sudo Synaptic", and Synaptic opens and I can download the chosen programs, but they do not appear on any of the XFCE menus.  If one then finds them with the file manager and clicks on a file, the chosen program runs.

Anyone know how to get the missing file ".Xauthority" or the program that generates it?  It would be very helpful for the downloaded programs to appear in a dropdown menu or as an ikon on the desktop.

[JoeMac]

I didn't realize Hardy was that far along.  I'll give the current Hardy torrent a try.  Thanks again, teapot. 

[teapot]

I am having the same problem as ritibelle (April 16) with the failure of Synaptic to run ("...unable to copy user's authorization file"), and  when I do "xauth generate $DISPLAY .trusted", the feedback indicates that it is trying to create an .Xauthority file, but I got:

"SecurityBadAuthorizationProtocol (invalid authorization name or data) xauth: (argv):1: couldnt generate authorization"

And "sudo xauth generate $DISPLAY .trusted" generates the same error message.

There should be a space between dot and "trusted". Dot is an abbreviation for "MIT-MAGIC-COOKIE-1" protocol, so xauth sees ".trusted" in its place and treats it as a protocol name. Obviously such a protocol does not exist, therefore "SecurityBadAuthorizationProtocol" error.

As I indicated earlier, I can do "sudo Synaptic", and Synaptic opens and I can download the chosen programs, but they do not appear on any of the XFCE menus.  If one then finds them with the file manager and clicks on a file, the chosen program runs.

Anyone know how to get the missing file ".Xauthority" or the program that generates it?  It would be very helpful for the downloaded programs to appear in a dropdown menu or as an ikon on the desktop.

I just sacrificed some space to run gdm, that takes care of this by itself, plus provides a nice-looking login screen. You can install it from Synaptic.

[teapot]

Hardy is released.

My XO, that was running Hardy prerelease installed from the same files that I have posted, now is updated to Hardy release version without problems. I am going to post updated files, and a rebuilding kit, however it won't be any different from what installs from prerelease tarball plus updates.

Unless, of course, someone is going to contribute patches or report bugs. In particular, my configuration so far does not have full keyboard support or global desktop defaults for multiple users, mail client, and convenient way to run Sugar along with Xfce. My attempts of combining/configuring desktop themes can use some help, too -- so far I think, I have succeeded with readability and speed, but visual consistency is lacking. I merely combined font, icons, gtk and window manager themes that seem to be most readable on XO screen, and set Xfce panel to keep important things on the screen.

[Eddie Owens]

Thanks teapot, for detecting that missing space...I inserted it and things went well.

I also tried to add gdm, but Synaptic could not fetch it because of "could not resolve 'us.archive.ubuntu.com'"

[JoeMac]

teapot,

Were you able to to map the screen brightness and sound level keys within your Hardy distribution?  Also, any luck with screen rotation?  I wasn't able to get that working in Gutsy.

[teapot]

Thanks teapot, for detecting that missing space...I inserted it and things went well.

I also tried to add gdm, but Synaptic could not fetch it because of "could not resolve 'us.archive.ubuntu.com'"

You have chosen a really bad time for update -- huge numbers of systems are being upgraded to Hardy, each downloading hundreds of megabytes from that site or its mirrors. I usually avoid this by installing prereleases, then doing the last upgrade either before or after the crowd, when the sanity is restored.

It's also possible that your network has a problem with DNS -- I can resolve that host, but can't get any response from it.

Edit: Now it responds. Veeeeery sloooooow.

[teapot]

teapot,

Were you able to to map the screen brightness and sound level keys within your Hardy distribution?  Also, any luck with screen rotation?  I wasn't able to get that working in Gutsy.

Brightness and sound keys work using the same scripts as in Gutsy. Screen rotation works from command line, but without remapping the keys it's not yet practical -- you need USB mouse to operate the laptop in portrait mode.

It can be easily added.

[JoeMac]

Thanks teapot.  I will be working on the Hardy Heron installation tonight.  I have one last question before I get started.  When I installed Gutsy, I downloaded a separate package to install backported video drivers (xserver-xorg-video-amd_2.7.7.6-1ubuntu2_i386.deb from https://launchpad.net/~q-funk/+archive

The video drivers noticeably accelerated streaming video content.  Will I need to do the same after I install Hardy?