User:Tonyr/Journal/Apr07

04Apr07

G3 iBook
Last week a very nice G3 iBook came in, fully functional, with an airport card, 320 MB/6G. Loren refurbished it, upgrading the hard drive, I think, and installing Ubuntu Edgy. I worked on it a little today, finishing up the details:

• added clock and volume control to the top panel
• added window-hider, window-selector and trash-can to the bottom panel

why didn't they get added automatically at installation?

• modprobed snd-powermac to add the sound device.

why wasn't a sound device detected at installation?  modprobe detected a DACA device; volume-control
shows only Master control but it doesn't connect to the panel applet volume control;  

• finished the update

There are a few things that still need to be done.

• I don't think I added the workspace switcher to the bottom panel, and I didn't local-to-panel any of the added applets.
• The CD started skipping when playing a music CD with SoundJuicer, but not right away. I usually install gxine in that case, but didn't get to it yet. I don't remember getting the specs on the CD; maybe it's not 24x.
• I don't know whether or not Loren checked the battery life. That needs to be done.

Loren and I talked about setting a price of $150 for this machine. Loren said he had talked to (Dave?) about it, too.

Artist lady is looking for a machine
An artist stopped by this afternoon to ask some questions about Macs. She is looking for a machine to do what I gather is graphics/animation related. She mentioned wanting to run some specific Mac software, and asked whether the machines we sell would run Mac OS 10.5. My answer was something like 'No/I don't really know'. Later I looked it up and found out that Apple apparently has published statements tot he effect that 10.5 will run on G4 and later models. She left a name and contact number with me, and I taped a notice on the wall. I should probably put the number in Loren's notebook. I told her we would contact her when a likely machine came in, and that we could not provide any Mac OS at all.

Tech support: replacing a Hard Drive
A store customer brought in a G4 box he had purchased. The hard drive was dead (the dreaded click). I replaced the 30GB drive with another 30 GB drive', and left an installation running. There are some interesting issues about this box. It is apparently one of the first towers to go to the store. The customer left his contact information on a yelow post-it on the top of the machine. He had the price sticker, but not the receipt. Martin suggested that the store might be able to find the receipt based on the customer's name.

07Apr07

G3 color depth suggestion'
http://ubuntuforums.org/archive/index.php/t-3723.html says that for X on older G3 machines with ATI/R128 graphics, Depth 16 works better, fps-wise. The article is three years old, but the suggestion is worth looking into.

10Apr07

Zip drives
Some G3 (and G4?) towers have ZIP100 drives. At some point I started testing these by writing to and reading from. Loren has acquired some ZIP250 drives and plans to replace the 100 drives with 250 drives as long as they last.

What is apparently missing is auto-mounting of Zip media. I would have thought that auto-mounting Zip media would be about the same as automounting a floppy. That does not seem to be the case. In Ubuntu 6.10(Edgy) installed onmy PC that has a floppy drive, this entry appears in /etc/fstab:

/dev/fd0   /media/floppy0   auto   rw,user,noauto   0   0

That is probably about the best that can be done, and I expect that it works for mount DOS formatted floppies. I think there may be an underlying assumption about the partition table on floppies, something on the order of "mount the first mountable partition found". I'm not sure how well that translates to Macs. The only references I have seen about Zip drives under Linux so far have assumed either a pre-existing VFAT format on the ZIP media, or creating a partition map and ext2 partition on the media.

It would be nice to provide some minimal level of ZIP support in the MacBuild process, I just don't know what that is yet.

11Apr07

sancube
Sergio brought over a sancube250 and asked MacBuild to test and wipe it. It's a rack of six (IDE?) drives in a box that Mac OS sees as a single 250GB drive. It connects to a Mac via ieee1394 (firewire). There is a special Mac software application that manages it as a RAID device and mediates access for multiple users. I can't find much about this particular model on the web, but there is user's manual for the current model at http://www.sancube.com/support/download.html.

The manual indicates that without the application, a Mac will ignore the scancube completely. that does not mean that the hardware is not recognized. The system profiler sees six drives on the firewire 'bus'. Ubuntu Edgy (6.10), however, sees only five drives. I don't know why. The OS X system profiler reports six devices and two unidentified devices. The Ubuntu startup log (dmesg) shows 5 drives assigned (sda...sde) and two unrecognized devices. (I'm writing this from memory, so I need to go back and examine dmesg again.)

Replication
The HD replication process succeeded for a G4 target today. The G4/533 reported earlier came back around, and I discovered that it had 7 partitions instead of four, as would be the case if a normal installation (or replication) had been done. I think this was a remnant of an experimental time in the development of the replication process.

Matteo offered that he is working on bringing up a new server that may have enough storage to serve all of the root file system images that the replication process currently uses. I told him I believed that it was possible to do a netboot and install that way using an installion CD iso loop mounted. He said getting the images available via remote mount and rsync would be a good start.

12Apr07

sancube
/var/log/messages confirms that only 5 scsi devices are defined. The result of lshw shows that scsi id numbers are assigend to the individual drives starting with id=3. If there are only 7 device ids available per controller, then numbering sequentially starting at three allows for only 5 ids. What happened to the other three ids? Some quirk of the Linux implementation of firewire on top of scsi?

So now the problem is how to get at the sixth drive. One way might be to try and get OS X to deal with it. Another way might be to physically remove the drive and wipe it on another machine.

Replication
Matteo got the server he was talking about working. We used rsync to upload one of the installation image directories, but the ownership/permissions didn't survive the transfer. Dave said the PC process used a more sophisticated arrangement with key authenticated root login. I am looking into this in terms of ssh and rsync documentation. Matteo is going to look at the actual scripts use in the PC installation process. What little research I have already done indicates that keys must be generated and stored in known locations, and modifications made to sshd config files and possibly other files related to key storage. Maybe the keys of interest already exist somewhere, and shouldbe used here. Matteo's take on this whole thing is that the goal is to 'standardize' the installation process as much as possible.

17Apr07

sancube
The sixth drive resists all attempts at access through software. Ubuntu doesn't detect it. OS X detects it but won't access it: the hardware profiler lists it on the Firewire bus, fdisk sees a partition map, but dd won't write anything to it. I have to conclude that the drive is hosed in some way. Sergio said pull the drives and recycle the rest. Maybe something else will come to light when the drives are pulled.

Netboot
I've been looking into it for PowerPC. It's a rocky road. I sort of get the impression that the Ubuntu folks have this way down on the priorities list.

There is a set of netboot network installation files for Dapper (6.04) at http://archive.ubuntu.com/ubuntu/dists/dapper/main/installer-powerpc/20051026ubuntu36/images/powerpc/netboot

Thee are several ways to implement the network boot process. I did it at home where my Linksys router is the DHCP server and a Desktop Ubuntu system has a TFTP server. All of the netboot files from the Ubuntu archive site are in a designated tftp directory. An iMac booted into OpenFirmware an then issue the command

boot enet:192.168.1.100,yaboot

and get right into the network installation process, which early on asks for a URL from which to get the installation data. The IP in that boot enet: command is the address of the TFTP server. One recommended arrangement is to have the DHCP server and the TFTP server be on the same machine, in which case the boot command would be

boot enet:0,yaboot

In this case the DCHP is configured to supply the boot files location directly.

There were a couple of problems that appeared while I was exploring this.

• The OpenFirmware version that is on the iMac I am using limits TFTP transfers to <=6MB. The initrd files for edgy and feisty are both >6MB, so the boot process fails for those Ubuntu versions at the initrd.gz TFPT transfer step. One solution for this that I saw suggested that several drivers can be removed from the initrd file (a cpio archive) to get the size down. I tried that a couple of times, but was never able to get it to work: the transfer succeeded, but the initrd fs wouldn't mount. I blame that on my current lack of understanding about initrd file generation. It may be that later versions of OpenFirmware, or even updated current versions, allow larger transfers, but I have found no evidence to support that at this point.

• The yaboot.conf files in the netboot file sets use absolute path names /vmlinux and initrd.gz. Something there is that does not like that very much, and the first TFT transfer, boot.msg, fails saying that it cannot find the file. Modifying yaboot.conf to remove the leading / from all file names fixes that.

There is a bug at Launchpad about the TFTP transfer size dating back to Hoary, but nothing I could find about the absolute path names. Maybe it only applies to the method I'm using (separate DHCP and TFTP servers).

More about netboot
The current stable version of yaboot is the source of the 6MB tftp transfer limit. The reported problem has to do with inadequate malloc behavior, and there seems to be some small effort in the greaqter community to address the problem. Here are a couple of relevant threads

• http://lists.infradead.org/pipermail/fedora-ppc/2007-March/000962.html
• http://penguinppc.org/bootloaders/yaboot/index.shtml

The first one is recent (Mar 07?). I'm not really sure how old the second one is. The copyright date says 2004.

The PC build process uses PXE to boot off the network. PXE is specific to Intel architectures, and requires support on the server, not the least of which is a dedicated directory with config information. The multiple options presented when a PXEboot floppy boots represent load configurations stored on the server in the dedicated PXE directory. This link

• http://www.tnpi.biz/computing/freebsd/pxe-netboot.shtml

is a pretty nice overview, even if targeted to the FreeBSD environment. I can't imagine that it is much different for the Debian environment. There are gobs of PXEboot HowTos out there.

The point is that PXE is not for PowerPC.

18Apr07

Xorg bug, PCI bus
Jason started working on a G4; replaced an AGP video card with a PCI video card. X wouldn't come up, and dpkg-reconfigure didn't fix it. The boot splash is there, and text consoles are there, so it's not a matter of the card not working. lspci finds the PCI video card. Xorg -scanpci does not. Xorg startup uses the same code to scan the PCI bus to locate the video card, so does not find the video device, reports that fact, and quits.

It turns out that there is an unresolved Ubuntu bug, #54880, at Launchpad about this very thing.

• https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/54880

So the ramification here is that currently, under Ubuntu Edgy, and probably Dapper, too, it is not possible to substitute a PCI graphics card in a Mac that expects an AGP card. I don't know about Feisty (7.04). If there is a fix, it would probably show up there first and then be backported to Edgy and Dapper. Dave said he wanted to look at the possibility of using Feisty (7.04) for the PC build process, so if that works out and the fix really is there, this problem may be solved sooner rather than later.

21Apr07

DHCP/TFTP and Mac netboot
An exceedingly interesting diversion. Here are some random things I have learned so far.

• tftpd-hpa is used because it talks PXE. Reg'lar tftpd does not. Macs do not use PXE for netboot. Implication: Macs do not require tftpd-hpa, but if the same DHCP server is used to support both PC and Mac clients, it doesn't matter.
• options used in dhcp.conf are defined in RFC2132
• dhcp.conf primarily defines network topology, and it's statements can be used to define subsets of clients that are dealt with in different ways. Subsets may be defined several ways, a couple of examples being by subnet or by class. subnet is subset based on IP address. class is a subset based on some attribute that a set of clients shares. An example attribute is vendor-class-identifier, which could contain a string taht differentiates between PCs and Macs. I grokked all of this from reading the dhcp.conf man page.

What this means is that the modifications that Matteo mad to dhcp.conf on (chasm? schist?) and reviewed by Martin are probably inadequate, and a better rewrite might be to use class to separate Macs from PCs.

Bad News
Gorm Norkle Frag Sollings! It looks like early iMacs and some B&W towers do not provide vendor-class-identifier in the DHCPDISCOVER request. There is a passing reference to this in man bootp(8), although the reference is to NetBoot service, not DHCP in particular. The association is speculation on my part. I did, however, manage to get my home network to show me the DHCPDISCOVER conversation between an iMac and a DHCP server (using wireshark), and vendor-class-identifier is nowhere to be seen therein. The dhcpd.conf examples I have seen on the net seem to be for G4 generation (or later) Macs, and accompanying tcp dumps clearly show a vendor-class-identifier in the DHCPDISCOVER packet. Here is one such example. The man page for dhcpd.conf says something like "some vendors might include vendor-class-identifier information" (emphasis mine), so I guess there is no guarantee that anything is there at all. So it goes.

28Apr07

Netinstall
I got the Feisty netinstall files whipped into shape, at least for my iMac. I expect this set will work for most Macs at FG, too. Here's a copy of the my post to the Apple PPC Users forum at ubuntuforums.org:

Maybe, someday, five thousand years from now, aliens digging through the remains of human
civilizations will be interested in this information, so I'll leave it lying around here.

To make initrd.gz smaller, using a hint from a post out there whose location I neglected to
save, I took the following steps:

   1. Become root (sudo -s)
   2. Extract the contents of initrd.gz with gunzip and cpio into a directory, say, initrd_dir
          * gunzip initrd.gz ; mkdir initrd_dir ; cd initrd_dir ; cpio -i < ../initrd
   3. Remove all unnecessary network drivers from lib/modules/2.6.20-15-powerpc/kernel/drivers/net . I sort of guessed at what was 'unnecessary'. I left the airport driver and everything starting with 'sun', since most modern Macs use the sungem interface
   4. Remove all references to the removed driver files from the modules.<whatever> files in lib/modules/2.6.20-15-powerpc
   5. Recreate the initrd.gz file with cpio and gzip
          * cd initrd_dir ; find . -depth -print | cpio -oc > ../newinitrd ; cd .. ; gzip newinitrd


The resulting newinitrd.gz file was something over 6200000 bytes, which is apparently small
enough for tftp to swallow. I moved newinitrd.gz to initrd.gz in the tftp server directory
 
That was not all of the story, however. It still didn't work. Persevere, dear reader.

The netinstall process got into vmlinux startup and died trying to mount the initramfs
(initrd.gz), which it didn't think was anything recognizeable.

And here is why:

Through Dapper, I believe, initrd was constructed as a cramfs filesystem.
Beginning with Edgy, initrd became a cpio archive. The powerpc versions
of netinstall files didn't make the transition, however (maybe one of those issues
contributing to powerpc being relegated to the ports pile). cramfs versions of
initrd look something like the name initrd.img. cpio versions of initrd look
something like the name initrd.gz. Somewhere in the netboot version of vmlinux,
I guess, is the expectation that initrd will be exactly one or the other form. The initrd
file is specified in yaboot.conf. In the Dapper netboot files, yaboot.conf
uses initrd.img. The Edgy version has initrd.img commented out and a line
containing initrd.gz added. Starting to get the picture? The Feisty versions (remember
I'm talking powerpc here) have not been adapted. yaboot.conf references initrd.gz,
the cpio version, but vmlinux apparently expects the cramfs version initrd.img.
What happens is that the netinstall process dies in a kernel panic unable to recognize/mount
the initial ram file system.

Sooooo...go back and make a cramfs image with the modified initrd extraction:

  1. As root...
  2. Install mkcramfs:
         * apt-get install cramfsprogs
  3. Use mkcramfs to create a cramfs version of initrd:
         * mkcramfs initrd_dir newinitrd.img
  4. Move newinitrd.img to initrd.img in the tftp server directory
  5. Edit yaboot.conf to comment out the initrd line using initrd.gz and adding a line using initrd.img, in each boot stanza.


Then the netinstall boot succeeded.

This is a bothersome workaround. I suspect that the real solution is to rework the
netboot files to use the newer cpio initrd convention, and to fix the 6MB limit in
tftp. They (the powerpc team) didn't get to it for Edgy, although the workaround
was released. I don't see any attempt to deal with it in Feisty yet. (28 April 2007)

Dual Processors
Several of the G4 Towers that came in (Thursday?) are Dual Processor 450GHz machines. The regular installation of Edgy does not seem to recognize use the second processor, at least from what I can see. lshw reports the second cpu to be DISABLED. SMP support is supposed to be included by default in the generic kernel and recognized at run time. I've seen a couple of posts that indicate that yaboot.conf may need a modification, and/or ybin -v rerun. That would be true, I think, if there were new or different kernel boot files in /boot, which I do not believe to be the case. Martin suggested Feisty might deal with the issue better, so I left an alternate CD install going last night. We'll see. Another post said that if /proc/cpuinfo reported two cpus then smp was working. That doesn't explain why lshw reports the second cpu to be DISABLED.

None of this may matter. The prevailing belief around FG is that patrons buying Macs are going to install some version of Mac OS anyway. I sure would like to see Ubuntu SMP running on the machines, though.

29Apr07

Dual Processors
The Feisty alternate CD install that I left running yesterday finished, not without problems, but more on that anon. I installed (using apt-get) the linux multi-processor image linux-image-powerpc-smp, and when that was done, ran ybin -v to refresh the yaboot information. This seemed to me to be the most reasonable set of steps. On reboot, both processors were recognized and used. lshw and /proc/cpuinfo both reported two processors, and top showed both processors actually doing stuff (top requires the interactinve command 1 to show both processors).

This process may actually work for Edgy also, but since FG (according to Martin) is headed for Feisty anyway, I'm not going to pursue that. I think the way I went about trying to get smp to work in Edgy earlier was flawed, but it's a moot point now.

Radeon R200 video support
The installation problem alluded to earlier involved the video card. The card in that particular machine was an ATI Radeon QL R200 (AGP). Xorg's radeon driver didn't recognize it, so X didn't start up (and so neither did gdm). Reconfiguring xserver-xorg didn't do any good, either. This is all very strange, since the card is recognized successfully in Edgy. I can only surmise that support for that particular card was dropped in the ATI video driver released with Feisty.

FWIW, here is a thread with an xorg.conf that is reported to work for this particular 
card in Feisty.

note: 13may07
It turns out that ATI dropped R200 support from it's video driver some time back.  The Ubuntu
user community raised heck about it.  In the final release of Feisy (7.04), the installation
process figures out which version of the driver is required for the installed video card
and does the right thing.

Netinstall/netboot
Matteo installed my modified Feisty powerpc netinstall files in the tftp server directory on machine schist, and then we successfully got a Mac to boot into the net install process by using the OpenFirmware boot enet: syntax. That was enough for proof-of-concept. The next step appears to be to get ltsp involved to somehow provide the configured installed image via rsync. I don't know how to do that, but Matteo said he did. Martin is looking to have both i386 and ppc images provided via ltsp.

PowerBook repair
Some laptops came in last week. A couple of them were PowerBooks of recent vintage. Loren is working on several of them. There is one that powers up but won't boot for love nor money: not from HD, not from CD (finnix nor Mac OS 9, didn't have a PowerBook CD to try). Here are a couple of links for opening/repairing Powerbooks that might be useful:

• http://www.xlr8yourmac.com/systems/PB_G4_15_AL_takeapart/AL_PB_G4_take-apart.html
• http://www.powerbookmedic.com/xcart1/files/G4aluminum15.pdf

30Apr07

Sample dhcpd.conf courtesy of cliebow in irc channel #ltsp

authoritative;

subnet 10.10.0.0 netmask 255.255.255.0 {
  range 10.10.0.20 10.10.0.250;
  option domain-name "cliebow.com";
  option domain-name-servers 10.10.0.1;
  option broadcast-address 10.10.0.255;
  option routers 10.10.0.1;
  option subnet-mask 255.255.255.0;
  if substring( option vendor-class-identifier, 0, 9 ) = "PXEClient" {
    filename "/ltsp/i386/pxelinux.0";
  }
elsif substring (option vendor-class-identifier, 0, 9) = "AAPLBSDPC" {
        filename "/yaboot";
	option vendor-class-identifier "AAPLBSDPC";
option vendor-encapsulated-options 01:01:02:08:04:01:00:00:01:82:
         05:                                    # length
         69:6d:61:63:34;                           # hostname
	 option root-path "/opt/ltsp/powerpc";
    }


  else{
    filename "/ltsp/i386/nbi.img";
  }
if substring (option vendor-class-identifier, 0, 3) = "d-i" {
   option root-path "/opt/ltsp/powerpc";
}
else {
  option root-path "/opt/ltsp/i386";
 }

# option root-path "/opt/ltsp/powerpc";
}