AC-0.9 on UP1500

[Michal Jaegermann]

I tried, eventually, to boot from that distribution CD on UP1500
(Nautilus).  It does boot, even if a graphics mode. :-)  This was
not a complete installation yet although I have no reason not
think that it will succeed at this moment.

I bumped into two things.  One is that in syslog the following
showed up:

<3>drivers/serial/8250.c:1068: spin_is_locked on uninitialized spinlock fffffc00007d9b00.
<4>drivers/serial/8250.c:1068: spin_lock():fffffc00007d9b00) already locked by <NULL>/488917820
<3>drivers/serial/8250.c:1078: spin_is_locked on uninitialized spinlock fffffc00007d9b00.
<3>drivers/serial/8250.c:1049: spin_is_locked on uninitialized spinlock fffffc00007d9b00.
<3>drivers/serial/8250.c:1060: spin_is_locked on uninitialized spinlock fffffc00007d9b00.
<3>drivers/serial/8250.c:1068: spin_is_locked on uninitialized spinlock fffffc00007d9b00.
<3>drivers/serial/8250.c:1078: spin_is_locked on uninitialized spinlock fffffc00007d9b00.
<3>drivers/serial/8250.c:1049: spin_is_locked on uninitialized spinlock fffffc00007d9b00.
<3>drivers/serial/8250.c:1060: spin_is_locked on uninitialized spinlock fffffc00007d9b00.

This smells like a bug in a serial driver. 488917820 is 0x1d244b3c which
does not ring a bell in particular beyond that it fits into 32 bits.

The other one is the following frament from anaconda logs:

....
* moving (1) to step monitor
* moving (1) to step setsanex
* moving (1) to step findrootparts
* running vgscan failed: 1280.  disabling lvm
* isys.py:mount()- going to mount /tmp/hda1 on /mnt/sysimage
* isys.py:mount()- going to mount /tmp/hda3 on /mnt/sysimage
* isys.py:mount()- going to mount /tmp/hda4 on /mnt/sysimage
* isys.py:mount()- going to mount /tmp/hda2 on /mnt/sysimage
* isys.py:mount()- going to mount /tmp/hda6 on /mnt/sysimage
* isys.py:mount()- going to mount /tmp/hdb1 on /mnt/sysimage
* isys.py:mount()- going to mount /tmp/hdb3 on /mnt/sysimage
* isys.py:mount()- going to mount /tmp/hdb4 on /mnt/sysimage
* isys.py:mount()- going to mount /tmp/hdb5 on /mnt/sysimage
* isys.py:mount()- going to mount /tmp/hdb6 on /mnt/sysimage
* isys.py:mount()- going to mount /tmp/hdb7 on /mnt/sysimage
* isys.py:mount()- going to mount /tmp/hdc1 on /mnt/sysimage
* isys.py:mount()- going to mount /tmp/hdc3 on /mnt/sysimage
* isys.py:mount()- going to mount /tmp/hdc4 on /mnt/sysimage
* isys.py:mount()- going to mount /tmp/hdc5 on /mnt/sysimage
* isys.py:mount()- going to mount /tmp/hdc6 on /mnt/sysimage
* moving (1) to step installtype
* moving (-1) to step findrootparts
* moving (-1) to step setsanex
* moving (-1) to step monitor
....

This looks like anaconda searching for existing installations to update.
It even does that in all the right places. :-)  The trouble is that it
should find three (yes, that is correct) and apparently is not finding
any as no update options are offered but only new installation ones.
I thought that it will be checking for a presence of
/mnt/sysimage/etc/redhat-release or /mnt/sysimage/etc/fedora-release;
maybe it want to see also some release names from a hardwired list?
Although the later would be somewhat unexpected.

   Michal