yaboot-installer should use OF aliases on pegasos

Bug #16737 reported by Sven Luther
6
Affects Status Importance Assigned to Milestone
yaboot-installer (Ubuntu)
Confirmed
Wishlist
Unassigned

Bug Description

in hoary yaboot-installer on pegasos, the boot-device is given using the full OF
path, and not the alias shortcut.

The following code in debian-installer nobootloader does the aliases
reverse-expansion :

                # map theidevice to the OF aliases from /proc/device-tree/aliases.
                if [ -d /proc/device-tree/aliases ]; then
                        for alias in `ls /proc/device-tree/aliases/*`; do
                                device=`grep disk $alias | sed -e 's%@[^/]*/%/%g'`
                                if [ "$path" = "$device" ]; then
                                        path="${alias#/proc/device-tree/aliases/}"
                                fi
                        done
                fi

Please add a similar code fragment to yaboot-installer so it will provide the
shorter OF command.

Friendly,

Sven Luther

Revision history for this message
Colin Watson (cjwatson) wrote :

I'd like to improve this code a bit in nobootloader before merging it into
yaboot-installer: when comparing two OF paths, it should really resolve each
component of the path into a canonical form (e.g. "pci@f2000000") by looking at
symlinks in /proc/device-tree, rather than collapsing "pci@f2000000" down to
"pci" and comparing that. I think that was what bothered me the last time I
looked at merging this code.

Otherwise, yeah, that would be nice for traditional yaboot architectures as well
as for Pegasos.

Revision history for this message
Sven Luther (luther) wrote :

Well, i feel that the full canonical path (@f2000000 and co) is not (at all or
easily) available from the devfs representation of the devices. I don't know how
you handle that with non-devfs hoary and later installer, but it should be
possible to get the full canonical path from /sys or something such.

$ for i in `find /sys -name devspec`; do more $i; done

Gives the canonical device name of all pci devices :

/pci@C0000000/display@8,1
/pci@C0000000/display@8
/pci@C0000000/host@0
/pci@80000000/ethernet@D
/pci@80000000/pci1106,3068@C,6
/pci@80000000/sound@C,5
/pci@80000000/other@C,4
/pci@80000000/usb@C,3
/pci@80000000/usb@C,2
/pci@80000000/ide@C,1
/pci@80000000/isa@C
/pci@80000000/usb@6,2
/pci@80000000/usb@6,1
/pci@80000000/usb@6
/pci@80000000/scsi@5
/pci@80000000/firewire@1
/pci@80000000/host@0

But we need then to match those with the ones where our d-i path is on.

I believe that is you go into /sys/block/<device>/device, and do a :

/sys/block/hda/device$ more ../../devspec
/pci@80000000/ide@C,1

you find the full canonical path.

Naturally, we couldn't do this in debian, since debian was still supporting 2.4
kernels, but this should be no major problem in ubuntu.

Friendly,

Sven Luther

Revision history for this message
Colin Watson (cjwatson) wrote :

(In reply to comment #2)
> Well, i feel that the full canonical path (@f2000000 and co) is not (at all or
> easily) available from the devfs representation of the devices.

I was really just thinking of this:

  lrwxrwxrwx 1 root root 12 2005-05-11 13:00 /proc/device-tree/pci -> pci@f0000000

It's true that working out the proper path to compare against involves more
code. However, I already added Pegasos support to ofpath, so we could use that.

> Naturally, we couldn't do this in debian, since debian was still supporting 2.4
> kernels, but this should be no major problem in ubuntu.

If it's necessary to do 2.6ish things in Debian they can always be guarded by a
simple test.

Revision history for this message
Sven Luther (luther) wrote :

Well, the problem is that we have no real guarantee that the pci of devfs-like
path is the same as the pci alias of the OF.

But then we can check that this is the case with all existing implementations
out there :)

Friendly,

Sven Luther

Colin Watson (cjwatson)
Changed in yaboot-installer:
assignee: kamion → nobody
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.