Jensen installation report, aboot
Michael Schwingen writes:
> after not using my Jensen for quite some time, I decided to try debian. I
> used both a ftp install from ftp.de.debian.org (unstable) and a local mirror
> (by nfs) from the same server:
Thanks for your report,
> - boot aboot/kernel from CD, root=/dev/fd0 load_ramdisk=1 (if you don't
> have a aboot-bootable CD, use the jensen stuff from
I will try to put that stuff in the jensen rescue disk. And I planned
for a long time to look at Debian CD generation, to ensure the Alpha
one is aboot-able.
> - use root1440.img (from slink) - what is the purpose of the rescue disk
> from jensen/resc1440.bin? It can't be booted anyway on that
Well, when I made the disks, I was not sure if it was still the case,
thanks for the precision.
Anyway, the disk will still be needed for the "Install Operating
System" step in the installation, to avoid a special case for the
jensen (but this step is not yet completely finished), and my rational
was to put on the rescue disk all that was necessary up to booting the
kernel, so I will add the right stuff for the Jensen one (not that the
Jensen disk is abootable, so currently it might already be possible to
create a bootable Jensen CD by doing a raw copy of resc1440.bin on a
> - install base system (have to use fdisk in BSD disklabel mode on console
> 2, instead of cfdisk, and reboot after partitioning).
> - boot kernel from CD, with root=/dev/sda3 and proceed installation
> Compared to my last RedHat installation, things went quite smooth - no big
> Jensen-specific trouble (except that the automatic gpm configuration crashed
> the whole machine by accessing ttyS1 - seems to be a kernel
I will check, I think there was already a problem report related to
> Now I am running into some dependency problems when using apt-get / dselect
> - that bad thing is that apt reports dependency problems when doing a
> 'upgrade' from the dselect menu, and will not even start downloading
> packages, so I used the local mirror via NFS/dselect. However, I still get
> dependency problems in the form of 'depends on xlib6g',
> xlib6g_18.104.22.168a-8, which is not yet available for alpha?
> I guess this is normal for 'unstable', however: where do I report these?
Yes some dependecies are still in a transient state, this is the right
list to report them.
> Another thing: I merged the debian aboot diff with my internal aboot version
> (now at 0.53), and will update the stuff on azstarnet soon.