Has anyone ever got Debian to install on an SGI Altix?
Tim Cutts
I've been looking into trying to install Debian on an SGI Altix (in
this case, a really baby Altix - one of the new Altix 330 machines).
I realise this is probably a forlorn hope, but we'd like to see just
how difficult it is. With most of the SGI-specific stuff now in the
upstream kernel sources, it seems not beyond the realms of possibility.
I'm netbooting the debian installer from EFI in the standard way, and
initial tests look promising. I didn't expect the default kernel
from the Debian installer to work, so I've built a new TFTP kernel on
another IA64 machine (an HP rx4640), using the kernel.org 2.6.12.5
sources. I had to guess some of the configuration, but I basically
opted for "If it mentions SGI in the help for each config option,
compile it in statically" as a starting position. Booting the Altix
into SuSE and looking at the modules loaded and dmesg output has been
helpful too.
Using this kernel, the machine boots a little way so I must have done
*something* right, but I appear to have a console output problem,
since console output stops after:
Uncompressing Linux... alloc.c(line 132):allocator: AllocatePages(2,
2, 3248, 0x4000000) failed (Not Found)
gzip.c(line 436):gzip_ia64 : AllocatePages(3248, 0x4000000) for
kernel failed
gzip.c(line 461):low_addr=0x4000000 new_addr=0x3010000000
offset=0x3010000000
done
Loading initrd SE/initrd.gz...done
Linux version 2.6.12.5 (tjrc@olympic) (gcc version 3.3.5 (Debian
1:3.3.5-5)) #1 SMP Thu Aug 25 11:09:01 BST 2005
EFI v1.10 by INTEL: SALsystab=0x30027c8df0 ACPI 2.0=0x30027c95c0
Number of logical nodes in system = 1
Number of memory chunks in system = 1
Initial ramdisk at: 0xe0000034f5127000 (2613248 bytes)
SAL 2.9: SGI SN2 version 4.30
SAL Platform features: ITC_Drift
SAL: AP wakeup using external interrupt vector 0x12
No logical to physical processor mapping available
ACPI: Local APIC address c0000000fee00000
ACPI: Error parsing MADT - no IOSAPIC entries
register_intr: No IOSAPIC for GSI 52
GSI 52 (level, low) -> CPU 0 (0x0000) vector 48
2 CPUs available, 2 CPUs total
Increasing MCA rendezvous timeout from 20000 to 49000 milliseconds
MCA related initialization done
SGI SAL version 4.30
Virtual mem_map starts at 0xa0007fffd1a70000
Built 1 zonelists
Kernel command line: BOOT_IMAGE=net0:debian-installer/ia64/SE/vmlinuz
root=/dev/ram init=/sbin/init DEBCONF_PRIORITY=low ramdisk_size=32768
console=ttyS0,38400n8 -- ro
PID hash table entries: 4096 (order: 12, 131072 bytes)
Console: colour dummy device 80x25
The console on these machines is weird, even by SGI Altix standards -
the L2 controller is an embedded Linux system itself, and emulates an
Altix L1 controller in software, as far as I can make out. One
speaks to this controller, which has an external USB interface, by
attaching a USB ethernet adapter, and then connecting to it via telnet.
Judging by what SuSE does, there's some sort of kernel device driver
which presents this as a normal serial port, but it seems that I have
not configured this correctly. Anyone know how to go about doing
this? I'm using the same console= settings as the SuSE boot
parameters. The console should definitely appear as ttyS0, but
perhaps I've missed something when configuring the kernel.
For comparison, the kernel messages when booting the SuSE 2.6.8
kernel are as follows:
I'm alive and well
ACPI: RSDP (v002 SGI ) @
0x00000030027c95c0
ACPI: XSDT (v001 SGI XSDTSN2 0x00010001 0x00000001) @
0x00000030027c9600
ACPI: MADT (v001 SGI APICSN2 0x00010001 0x00000001) @
0x00000030027c9660
ACPI: SRAT (v001 SGI SRATSN2 0x00010001 0x00000001) @
0x00000030027c96c0
ACPI: SLIT (v001 SGI SLITSN2 0x00010001 0x00000001) @
0x00000030027c9750
ACPI: FADT (v003 SGI FACPSN2 0x00030001 0x00000001) @
0x00000030027c9820
ACPI: DSDT (v001 SGI DSDTSN2 0x00010001 0x00000001) @
0x00000030027c97e0
ACPI: DSDT (v001 SGI DSDTSN2 0x00010001 0x00000001) @
0x0000000000000000
ACPI: SRAT revision 0
ACPI: SLIT localities 1x1
Number of logical nodes in system = 1
Number of memory chunks in system = 1
Initial ramdisk at: 0xe0000034f6111000 (3002368 bytes)
SAL 2.9: SGI SN2 version 4.30
SAL Platform features: ITC_Drift
SAL: AP wakeup using external interrupt vector 0x12
No logical to physical processor mapping available
ACPI: Local APIC address 0xc0000000fee00000
ACPI: LSAPIC (acpi_id[0x00] lsapic_id[0x00] lsapic_eid[0x00] enabled)
CPU 0 (0x0000) enabled (BSP)
ACPI: LSAPIC (acpi_id[0x01] lsapic_id[0x01] lsapic_eid[0x00] enabled)
CPU 1 (0x0100) enabled
ACPI: Error parsing MADT - no IOSAPIC entries
register_intr: No IOSAPIC for GSI 52
GSI 52 (level, low) -> CPU 0 (0x0000) vector 48
2 CPUs available, 2 CPUs total
Increasing MCA rendezvous timeout from 20000 to 49000 milliseconds
MCA related initialization done
SGI SAL version 4.30
Virtual mem_map starts at 0xa0007fffd1a70000
On node 0 totalpages: 502599
DMA zone: 502599 pages, LIFO batch:7
Normal zone: 0 pages, LIFO batch:1
HighMem zone: 0 pages, LIFO batch:1
Built 1 zonelists
Kernel command line: BOOT_IMAGE=dev000:efi\SuSE\vmlinuz root=/dev/
sda3 selinux=0 linux console=ttyS0,38400n8 splash=silent elevator=cfq
thash_entries=2097152 kdb=on ro
PID hash table entries: 4096 (order 12: 65536 bytes)
CKRM Initialization
...... Initializing ClassType<taskclass> ........
...... Initializing ClassType<socketclass> ........
CKRM Initialization done
Console: colour dummy device 80x25
Memory: 7952912k/8041584k available (6199k code, 105264k reserved,
2981k data, 400k init)
McKinley Errata 9 workaround not needed; disabling it
kdb version 4.4 by Keith Owens, Scott Lurndal. Copyright SGI, All
Rights Reserved
kdb_cmd[0]: defcmd archkdb "" "First line arch debugging"
kdb_cmd[6]: defcmd archkdbcpu "" "archkdb with only tasks on cpus"
kdb_cmd[12]: defcmd archkdbshort "" "archkdb with less detailed
backtrace"
kdb_cmd[18]: defcmd archkdbcommon "" "Common arch debugging"
Security Scaffold v1.0.0 initialized
SELinux: Disabled at boot.
Dentry cache hash table entries: 1048576 (order: 9, 8388608 bytes)
Inode-cache hash table entries: 524288 (order: 8, 4194304 bytes)
Mount-cache hash table entries: 1024 (order: 0, 16384 bytes)
Boot processor id 0x0/0x0
task migration cache decay timeout: 10 msecs.
I'm alive and well
Brought up 2 CPUs
Total of 2 processors activated (4759.08 BogoMIPS).
checking if image is initramfs...it isn't (no cpio magic); looks like
an initrd
Looking for DSDT in initrd ...No customized DSDT found in initrd!
Freeing initrd memory: 2912kB freed
khelper: max 64 concurrent processes
resid is -1 name is io <NULL>
CKRM .. create res clsobj for resouce <io>class <taskclass>
par=0000000000000000
NET: Registered protocol family 16
ACPI: Subsystem revision 20040326
ACPI: SCI (ACPI GSI 52) not registered
ACPI: Interpreter enabled
ACPI: Using IOSAPIC for interrupt routing
PCI: Using ACPI for IRQ routing
ACPI: PCI interrupt 0000:01:01.0[A]: no GSI
ACPI: PCI interrupt 0000:02:01.0[A]: no GSI
ACPI: PCI interrupt 0000:02:01.1[B]: no GSI
ACPI: PCI interrupt 0000:d0:02.0[A]: no GSI
ACPI: PCI interrupt 0000:d0:02.1[B]: no GSI
ACPI: PCI interrupt 0000:d0:02.2[C]: no GSI
ACPI: PCI interrupt 0000:d1:04.0[A]: no GSI
perfmon: version 2.0 IRQ 238
perfmon: Itanium 2 PMU detected, 16 PMCs, 18 PMDs, 4 counters (47 bits)
EFI Variables Facility v0.06 2002-Dec-10
PAL Information Facility v0.5
perfmon: added sampling format default_format
perfmon_default_smpl: default_format v2.0 registered
Initial HugeTLB pages allocated: 0
VFS: Disk quotas dquot_6.5.1
Initializing Cryptographic API
EFI Time Services Driver v0.4
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
RAMDISK driver initialized: 16 RAM disks of 128000K size 1024 blocksize
loop: loaded (max 8 devices)
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
SiI680: IDE controller at PCI slot 0000:d1:04.0
PCI: Found IRQ 63 for device 0000:d1:04.0
ACPI: PCI interrupt 0000:d1:04.0[A]: no GSI
SiI680: chipset revision 2
SiI680: BASE CLOCK == 133
SiI680: 100% native mode on irq 63
ide0: MMIO-DMA , BIOS settings: hda:pio, hdb:pio
ide1: MMIO-DMA , BIOS settings: hdc:pio, hdd:pio
hda: MATSHITADVD-ROM SR-8178, ATAPI CD/DVD-ROM drive
Using cfq io scheduler
ide0 at 0xc0000008c0400080-0xc0000008c0400087,0xc0000008c040008a on
irq 63
ide-floppy driver 0.99.newide
mice: PS/2 mouse device common for all mice
input: PC Speaker
i8042.c: i8042 controller self test timeout.
md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
NET: Registered protocol family 2
IP: routing cache hash table of 131072 buckets, 2048Kbytes
TCP established hash table entries: 4194304 (order: 12, 67108864 bytes)
TCP bind hash table entries: 65536 (order: 6, 1048576 bytes)
TCP: Hash tables configured (established 4194304 bind 65536)
NET: Registered protocol family 1
NET: Registered protocol family 8
NET: Registered protocol family 20
resid is -1 name is cpu <NULL>
CKRM .. create res clsobj for resouce <cpu>class <taskclass>
par=0000000000000000
........init_ckrm_sched_res , resid= 5
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem).
Starting udev
Creating devices
Loading kernel/drivers/scsi/scsi_mod.ko
SCSI subsystem initialized
Loading kernel/drivers/scsi/sd_mod.ko
Loading kernel/drivers/sn/ioc4.ko
Loading kernel/drivers/ide/pci/sgiioc4.ko
Loading kernel/drivers/scsi/sg.ko
Loading kernel/drivers/scsi/libata.ko
Loading kernel/drivers/scsi/sata_vsc.ko
Loading kernel/drivers/scsi/qla1280.ko
Loading kernel/drivers/scsi/scsi_transport_fc.ko
Loading kernel/drivers/message/fusion/mptbase.ko
Fusion MPT base driver 3.02.18
Copyright (c) 1999-2005 LSI Logic Corporation
PCI: Found IRQ 62 for device 0000:01:01.0
ACPI: PCI interrupt 0000:01:01.0[A]: no GSI
mptbase: Initiating ioc0 bringup
ioc0: SAS1064: Capabilities={Initiator}
Loading kernel/drivers/message/fusion/mptscsih.ko
Fusion MPT SCSI Host driver 3.02.18
scsi0 : ioc0: LSISAS1064, FwRev=00040200h, Ports=1, MaxQ=203, IRQ=62
Vendor: ATA Model: HDT722525DLA380 Rev: A80A
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB)
SCSI device sda: drive cache: write back
sda: sda1 sda2 sda3
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0, type 0
Loading kernel/drivers/scsi/qla2xxx/qla2xxx.ko
QLogic Fibre Channel HBA Driver
Loading kernel/drivers/scsi/qla2xxx/qla2300.ko
Loading kernel/drivers/scsi/qla2xxx/qla2200.ko
Loading kernel/fs/dmapi/dmapi.ko
Loading kernel/fs/exportfs/exportfs.ko
Loading kernel/fs/xfs/xfs.ko
SGI-XFS CVS-2004-10-17_05:00_UTC with ACLs, security attributes,
realtime, large block/inode numbers, dmapi support, no debug enabled
Waiting for device /dev/sda3 to appear: ok
rootfs: major=8 minor=3 devn=2051
rootfs: /sys/block/sda/sda3 major=8 minor=3 devn=2051
XFS mounting filesystem sda3
VFS: Mounted root (xfs filesystem) readonly.
Trying to move old root to /initrd ... failed
Unmounting old root
Trying to free ramdisk memory ... okay
Freeing unused kernel memory: 400kB freed
INIT: version 2.85 booting
[ rest snipped ]
If anyone has any suggestions where to go from here, I'm all ears...
are there any SGI people reading this list, or are the IA64
developers mostly HP bods?
Thanks very much in advance...
Tim
--
To UNSUBSCRIBE, email to debian-ia...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Christoph Lameter
On Fri, 26 Aug 2005, Tim Cutts wrote:
> I realise this is probably a forlorn hope, but we'd like to see just how
> difficult it is. With most of the SGI-specific stuff now in the upstream
> kernel sources, it seems not beyond the realms of possibility.
Its very easy actually some of our engineers run Debian.
> Using this kernel, the machine boots a little way so I must have done
> *something* right, but I appear to have a console output problem, since
> console output stops after:
You need to add console=ttySG0 as a boot parameter. The newer kernels no
longer use ttyS0 as a console.
---
Dr. Christoph Lameter Technical Lead - Linux Kernel Software
Silicon Graphics, Inc. Phone: 1-650-933-8114
Tim Cutts
On 26 Aug 2005, at 5:00 pm, Christoph Lameter wrote:
> Hi Time, have not talked to you in a long time....
Hi Christoph - no, indeed we have not talked for a long long time.
Probably almost 10 years! Back in the heady days that I first
packaged Exim for Debian...
> On Fri, 26 Aug 2005, Tim Cutts wrote:
>
>
>> I realise this is probably a forlorn hope, but we'd like to see
>> just how
>> difficult it is. With most of the SGI-specific stuff now in the
>> upstream
>> kernel sources, it seems not beyond the realms of possibility.
>>
>
> Its very easy actually some of our engineers run Debian.
Somehow I thought that would be the case. Engineers from almost
every hardware manufacturer I ever talk to say that. :-)
>> Using this kernel, the machine boots a little way so I must have done
>> *something* right, but I appear to have a console output problem,
>> since
>> console output stops after:
>>
>
> You need to add console=ttySG0 as a boot parameter. The newer
> kernels no
> longer use ttyS0 as a console.
Well, that's got me some way further, thanks. Care to mail me
your .config so that I can build a kernel that actually, erm,
works? :-)
Tim
Christoph Lameter
> Hi Christoph - no, indeed we have not talked for a long long time. Probably
> almost 10 years! Back in the heady days that I first packaged Exim for
> Debian...
Yes that was when I tried to use exim for the linux-kernel mailing list.
> You need to add console=ttySG0 as a boot parameter. The newer kernels
no
> > longer use ttyS0 as a console.
>
> Well, that's got me some way further, thanks. Care to mail me your .config so
> that I can build a kernel that actually, erm, works? :-)
do a
make sn2_defconfig
and you will be fine.
Here is my build script for a SuSE kernel. Maybe bits an pieces of this
will help.
set -ev
if [ ! -e .config ]; then
make sn2_defconfig
fi
rm -rf install
mkdir -p install/boot/efi/efi/SuSE
rm -f vmlinux*
make -j8
make modules
make INSTALL_PATH=install/boot install
make INSTALL_MOD_PATH=install modules_install
KV=`grep UTS_RELEASE include/linux/version.h |awk '{ print $3 }'`
KVERSION=`expr $KV : '\"\(.*\)\"'`
echo "Kernel version is $KVERSION"
cd install/boot
#rm *.old || echo "no old kernel"
mv vmlinuz vmlinuz-christoph
mv System.map System.map-christoph
cp vmlinuz-christoph efi/efi/SuSE
cd ..
tar czvf ~/k/k-$KVERSION.tgz *
cd ..
Greg Edwards
| On Fri, 26 Aug 2005, Tim Cutts wrote:
|
| > I realise this is probably a forlorn hope, but we'd like to see just how
| > difficult it is. With most of the SGI-specific stuff now in the upstream
| > kernel sources, it seems not beyond the realms of possibility.
|
| Its very easy actually some of our engineers run Debian.
The A330 has an LSI SAS controller (serial attached scsi), and I don't
think the driver is upstream yet. This should be your only hurdle. I
can see if I can scrounge up a patch for you.
Greg
dann frazier
> I've been looking into trying to install Debian on an SGI Altix (in
> this case, a really baby Altix - one of the new Altix 330 machines).
>
> I realise this is probably a forlorn hope, but we'd like to see just
> how difficult it is. With most of the SGI-specific stuff now in the
> upstream kernel sources, it seems not beyond the realms of possibility.
Actually I tried to get this working on an Altix by ending debug d-i
drops to Jesse Barnes a while back. I determined that reading/writing
from /dev/console started to silently fail once busybox init started -
anytime before it worked fine. The standard debian kernel seemed to
work in his Fedora userspace, it was seemingly just a d-i issue.
Unfortunately, the debug cycle was too high latency so I never finished
it.
Its good to hear that d-i can work with the right kernel. I'd love to
know when standard Debian kernels aren't working, especially if someone
can tell me what's wrong (or give me access to a box remotely to fix
it).
Once Altix was known to work, my plan is to add an option to the elilo
graphical menu for an Altix console that will automatically append the
proper console option.
Tim Cutts
On 26 Aug 2005, at 5:59 pm, Greg Edwards wrote:
> On Fri, Aug 26, 2005 at 04:55:28PM +0100, Tim Cutts wrote:
> | I've been looking into trying to install Debian on an SGI Altix (in
> | this case, a really baby Altix - one of the new Altix 330 machines).
>
> Tim, give this patch a whirl. It booted ok for me on one of our lab
> A330s. Your mileage may vary.
Well, it, together with Christoph's recipe for building the kernel,
is getting me steadily further. My only change to the configuration
has been to enable cramfs support, since cramfs is what the Debian
installer uses.
It's detecting all the hardware correctly, as far as I can tell, but
I'm getting modprobe errors on boot, which I think is because the
initrd image just isn't working correctly.
Initially, I thought this was to do with the following error which I
get as soon as the kernel tries to boot:
Uncompressing Linux... alloc.c(line 132):allocator: AllocatePages(2,
2, 3447, 0x4000000) failed (Not Found)
gzip.c(line 436):gzip_ia64 : AllocatePages(3447, 0x4000000) for
kernel failed
gzip.c(line 461):low_addr=0x4000000 new_addr=0x3010000000
offset=0x3010000000
done
But I've tried netbooting with uncompressed kernel and initrd, and I
still end up with error messages which are coming from the kernel
trying to run /sbin/modprobe, and failing.
Did I mess up creating my initrd? I loopback mounted the initrd from
the debian-installer, and copied its contents somewhere else. I
installed the new kernel's modules into the appropriate place, and
then used mkcramfs -b 16384 to create a new initrd from this
directory. Have I missed some crucial step that I should have made?
Greg Edwards
| On Fri, 2005-08-26 at 16:55 +0100, Tim Cutts wrote:
| > I've been looking into trying to install Debian on an SGI Altix (in
| > this case, a really baby Altix - one of the new Altix 330 machines).
| >
| > I realise this is probably a forlorn hope, but we'd like to see just
| > how difficult it is. With most of the SGI-specific stuff now in the
| > upstream kernel sources, it seems not beyond the realms of possibility.
|
| Actually I tried to get this working on an Altix by ending debug d-i
| drops to Jesse Barnes a while back. I determined that reading/writing
| from /dev/console started to silently fail once busybox init started -
| anytime before it worked fine. The standard debian kernel seemed to
| work in his Fedora userspace, it was seemingly just a d-i issue.
| Unfortunately, the debug cycle was too high latency so I never finished
| it.
This may still be happening. About a month ago, I tried booting one of
the daily builds on an Altix:
http://cdimage.debian.org/pub/cdimage-testing/daily/ia64/
and it failed about there. I didn't have time to debug it at the time,
so I just did a minimal install on an HP box, then rsynced the root
over. Interestingly enough, altix works fine with the standard 2.6.12
debian kernel.
| Its good to hear that d-i can work with the right kernel. I'd love to
| know when standard Debian kernels aren't working, especially if someone
| can tell me what's wrong (or give me access to a box remotely to fix
| it).
I'll try to dig into this today and see if I can isolate what's going
on.
| Once Altix was known to work, my plan is to add an option to the elilo
| graphical menu for an Altix console that will automatically append the
| proper console option.
Another thing that would be really helpful is to turn on the
"relocatable" option by default in the installer elilo.conf (and the
system copy once in place). Altix requires elilo to use
relocatable support.
Greg Edwards
| Well, it, together with Christoph's recipe for building the kernel,
| is getting me steadily further. My only change to the configuration
| has been to enable cramfs support, since cramfs is what the Debian
| installer uses.
|
| It's detecting all the hardware correctly, as far as I can tell, but
| I'm getting modprobe errors on boot, which I think is because the
| initrd image just isn't working correctly.
|
| Initially, I thought this was to do with the following error which I
| get as soon as the kernel tries to boot:
|
| Uncompressing Linux... alloc.c(line 132):allocator: AllocatePages(2,
| 2, 3447, 0x4000000) failed (Not Found)
|
| gzip.c(line 436):gzip_ia64 : AllocatePages(3447, 0x4000000) for
| kernel failed
|
| gzip.c(line 461):low_addr=0x4000000 new_addr=0x3010000000
| offset=0x3010000000
| done
This is just elilo spewing out some messages regarding relocating the
kernel. I seem to recall either Jesse or I sent the elilo maintainer
a patch to quiet these down since they are normal on Altix, and I
think it's upstream already.
| But I've tried netbooting with uncompressed kernel and initrd, and I
| still end up with error messages which are coming from the kernel
| trying to run /sbin/modprobe, and failing.
|
| Did I mess up creating my initrd? I loopback mounted the initrd from
| the debian-installer, and copied its contents somewhere else. I
| installed the new kernel's modules into the appropriate place, and
| then used mkcramfs -b 16384 to create a new initrd from this
| directory. Have I missed some crucial step that I should have made?
I'm not very familiar with how the debian installer works, but I can try
to play around with this today and see if I can get something that works.
Greg
dann frazier
> On Mon, Aug 29, 2005 at 07:04:54PM -0600, dann frazier wrote:
> | On Fri, 2005-08-26 at 16:55 +0100, Tim Cutts wrote:
> | > I've been looking into trying to install Debian on an SGI Altix (in
> | > this case, a really baby Altix - one of the new Altix 330 machines).
> | >
> | > I realise this is probably a forlorn hope, but we'd like to see just
> | > how difficult it is. With most of the SGI-specific stuff now in the
> | > upstream kernel sources, it seems not beyond the realms of possibility.
> |
> | Actually I tried to get this working on an Altix by ending debug d-i
> | drops to Jesse Barnes a while back. I determined that reading/writing
> | from /dev/console started to silently fail once busybox init started -
> | anytime before it worked fine. The standard debian kernel seemed to
> | work in his Fedora userspace, it was seemingly just a d-i issue.
> | Unfortunately, the debug cycle was too high latency so I never finished
> | it.
>
> This may still be happening. About a month ago, I tried booting one of
> the daily builds on an Altix:
>
> http://cdimage.debian.org/pub/cdimage-testing/daily/ia64/
>
> and it failed about there. I didn't have time to debug it at the time,
> so I just did a minimal install on an HP box, then rsynced the root
> over. Interestingly enough, altix works fine with the standard 2.6.12
> debian kernel.
The dailies should be using 2.6.12 now, so can you give it another try
(unless the previous version you used was already 2.6.12 - then I expect
to see no difference).
> | Its good to hear that d-i can work with the right kernel. I'd love to
> | know when standard Debian kernels aren't working, especially if someone
> | can tell me what's wrong (or give me access to a box remotely to fix
> | it).
>
> I'll try to dig into this today and see if I can isolate what's going
> on.
Great, thanks. I've been given access to an Altix box as well (thanks
Ian), so I might be able to help.
> | Once Altix was known to work, my plan is to add an option to the elilo
> | graphical menu for an Altix console that will automatically append the
> | proper console option.
>
> Another thing that would be really helpful is to turn on the
> "relocatable" option by default in the installer elilo.conf (and the
> system copy once in place). Altix requires elilo to use
> relocatable support.
I see you filed a bug (#324067) for this - cool. I'd suggest adding a
code snippet/hint that will allow elilo to determine that it should use
relocatable on this system. For instance - how do RH/SuSE make this
determination? (This is what Bdale asked last time we brought it up -
however, elilo was frozen for sarge and we never did get the install
kernel working, so there wasn't much interest in following up).
Greg Edwards
| On Wed, 2005-08-31 at 09:14 -0500, Greg Edwards wrote:
| > I'll try to dig into this today and see if I can isolate what's going
| > on.
|
| Great, thanks. I've been given access to an Altix box as well (thanks
| Ian), so I might be able to help.
console output is stopping when busybox init is run. I added a set -x to
sbin/init and saw:
+ uname -r
+ grep ^2.2.
+ [ = ]
+ mount /proc
+ umount initrd
+ true
+ mount -t tmpfs -o size=100M tmpfs /mnt
+ :
+ umount /proc
+ ls -1 /
+ grep -v \(dev\|lost+found\|mnt\|proc\)
+ cp -a bin etc floppy init initrd lib preseed.cfg sbin sys tmp usr var
/mnt
+ cd /mnt
+ pivot_root . initrd
+ mkdir proc dev
+ [ -x /sbin/udevstart ]
+ /lib/debian-installer/init-udev-devices
+ mount /proc
+ exec /usr/sbin/chroot . /bin/busybox init
[... no more ...]
The box is still up at this point, as I was able to enter kdb (I had
kdb built into a kernel I had shoehorned in). Interestingly, the kdb
output showed on the screen, but I never got the kdb prompt, so something
is messing with the console (ttySG0 is the console on Altix).
| > Another thing that would be really helpful is to turn on the
| > "relocatable" option by default in the installer elilo.conf (and the
| > system copy once in place). Altix requires elilo to use
| > relocatable support.
|
| I see you filed a bug (#324067) for this - cool. I'd suggest adding a
| code snippet/hint that will allow elilo to determine that it should use
| relocatable on this system. For instance - how do RH/SuSE make this
| determination? (This is what Bdale asked last time we brought it up -
| however, elilo was frozen for sarge and we never did get the install
| kernel working, so there wasn't much interest in following up).
SuSE (and Red Hat too, I believe) have relocatable turned on all the ia64
boxes by default. It doesn't have an adverse effect on those platforms
that don't require it. If you need to check for Altix, you could look
for the existence of /proc/sgi_sn. This will be present on any
Altix/Prism system.
Bdale Garbee
> SuSE (and Red Hat too, I believe) have relocatable turned on all the ia64
> boxes by default. It doesn't have an adverse effect on those platforms
> that don't require it.
There are still 2.4.27 kernel image packages for ia64 in Debian unstable
and testing. I'm told having relocatable on breaks 2.4 kernels. So,
the sequence we need to follow is to update debian-installer to no
longer know about 2.4 kernels, then evict the 2.4 kernel image packages
for ia64 from unstable+testing... then I'll be happy to turn relocatable
on by default. If someone really wants to run a 2.4 kernel, they can
learn how to edit the elilo options, too... ;-)
Bdale
Greg Edwards
| On Wed, 2005-08-31 at 16:39 -0500, Greg Edwards wrote:
| build w/ a 2.6.12 kernel?
I couldn't get the d-i (from svn) to build on my box, so I pulled the
initrd apart from the latest daily images
http://cdimage.debian.org/pub/cdimage-testing/daily/ia64/20050820/
which I think was still 2.6.8-based. Anyway, I repopulated with a
2.6.13 + LSI SAS + kdb kernel and modules and saw the same thing.
| > SuSE (and Red Hat too, I believe) have relocatable turned on all the ia64
| > boxes by default. It doesn't have an adverse effect on those platforms
| > that don't require it. If you need to check for Altix, you could look
| > for the existence of /proc/sgi_sn. This will be present on any
| > Altix/Prism system.
|
| Well, I'm told its a problem for 2.4 kernels. Debian still includes a
| 2.4.27 (though we'll drop it before etch).
Ah, forgot about 2.4.x kernels. You're right, it would probably cause
problems there.
I'm leaving on vacation now for a couple weeks, but I'll look at this
again when I get back.
Greg
dann frazier
Yes - this is exactly what I saw w/ 2.6.8. Is this w/ the latest d-i
build w/ a 2.6.12 kernel?
> SuSE (and Red Hat too, I believe) have relocatable turned on all the ia64
> boxes by default. It doesn't have an adverse effect on those platforms
> that don't require it. If you need to check for Altix, you could look
> for the existence of /proc/sgi_sn. This will be present on any
> Altix/Prism system.
Well, I'm told its a problem for 2.4 kernels. Debian still includes a
2.4.27 (though we'll drop it before etch).
Joey Hess
> console output is stopping when busybox init is run. I added a set -x to
> sbin/init and saw:
>
> + uname -r
> + grep ^2.2.
> + [ = ]
> + mount /proc
> + umount initrd
> + true
> + mount -t tmpfs -o size=100M tmpfs /mnt
> + :
> + umount /proc
> + ls -1 /
> + grep -v \(dev\|lost+found\|mnt\|proc\)
> + cp -a bin etc floppy init initrd lib preseed.cfg sbin sys tmp usr var
> /mnt
> + cd /mnt
> + pivot_root . initrd
> + mkdir proc dev
> + [ -x /sbin/udevstart ]
> + /lib/debian-installer/init-udev-devices
> + mount /proc
> + exec /usr/sbin/chroot . /bin/busybox init
> [... no more ...]
This does not appear to be a current d-i daily build, since it's missing
at least one command that is run in the code block in current versions
of d-i. Just FWIW.
FWIW, the closest match to this problem that I've debugged was an arm
box where devfs didn't know about the serial device being used and
didn't create a device node for it, which does cause busybox init to
fall over like you describe.
If I were you I've use a current daily build, boot it with BOOT_DEBUG=5,
and at the shell it will give you right before the last line above,
investigate the inttab and /mnt/dev.
--
see shy jo
Greg Edwards
| If I were you I've use a current daily build, boot it with BOOT_DEBUG=5,
| and at the shell it will give you right before the last line above,
| investigate the inttab and /mnt/dev.
Where does one locate the most current daily build? I look at:
http://www.debian.org/devel/debian-installer/ports-status
and for ia64, it looks like "netboot" is a broken link and the two CD
images haven't been built since early August.
Greg
Joey Hess
> On Thu, Sep 01, 2005 at 10:31:32PM -0400, Joey Hess wrote:
> | If I were you I've use a current daily build, boot it with BOOT_DEBUG=5,
> | and at the shell it will give you right before the last line above,
> | investigate the inttab and /mnt/dev.
>
> Where does one locate the most current daily build? I look at:
>
> http://www.debian.org/devel/debian-installer/ports-status
>
> and for ia64, it looks like "netboot" is a broken link and the two CD
> images haven't been built since early August.
That page is accurate, the daily builds for ia64 have been down since at
least then.
--
see shy jo