Bug#308565: Installation report
Package: installation-reports
Debian-installer-version: rc3, i386 netinst image from
<http://www.debian.org/devel/debian-installer/>
uname -a: Linux [hostname] 2.6.8-2-386 #1 Mon Jan 24 03:01:58 EST 2005
i686 GNU/Linux
Date: 10 May 2005, about 5:30 PM NZST
Method: Booted from netinst CD in the blade chassis media tray (a USB
CD drive as far as the blade is concerned), most packages retrieved via
local apt-proxy server - no other proxy used
Machine: Intel SBX82 blade server
Processor: 3.0 GHz Intel Xeon
Memory: 1GB
Root Device: partitions on onboard SCSI disks, RAID 1 mirrored
(/dev/md0, made up of /dev/sda1 and /dev/sdb1 after reboot, see below)
Root Size/partition table:
Partition Table for /dev/sda
First Last
# Type Sector Sector Offset Length Filesystem Type
(ID) Flag
-- ------- ----------- ----------- ------ -----------
-------------------- ----
1 Primary 0 19535039 63 19535040 Linux raid auto
(FD) Boot
2 Primary 19535040 23438834 0 3903795 Linux raid auto
(FD) None
3 Primary 23438835 143364059 0 119925225 Extended (05)
None
5 Logical 23438835 25398764 63 1959930 Linux raid auto
(FD) None
6 Logical 25398765 93755339 63 68356575 Linux raid auto
(FD) None
7 Logical 93755340 123057899 63 29302560 Linux raid auto
(FD) None
8 Logical 123057900 143364059 63 20306160 Linux raid auto
(FD) None
/dev/sdb is partitioned identically, and each partition is mirrored to
its corresponding one on the other disk. Mount points:
/dev/md0: /dev/sda1 and /dev/sdb1, mounted as the root filesystem
/dev/md1: /dev/sda2 and /dev/sdb2, mounted as swap space
/dev/md2: /dev/sda5 and /dev/sdb5, mounted as /tmp
/dev/md3: /dev/sda6 and /dev/sdb6, mounted as /var
/dev/md4: /dev/sda7 and /dev/sdb7, mounted as /usr
/dev/md5: /dev/sda8 and /dev/sdb8, mounted as /home
Output of lspci and lspci -n:
0000:00:00.0 Host bridge: Intel Corp. Server Memory Controller Hub (rev
0c)
0000:00:00.1 ff00: Intel Corp. Memory Controller Hub Error Reporting
Register (rev 0c)
0000:00:03.0 PCI bridge: Intel Corp. Memory Controller Hub PCI Express
Port A1 (rev 0c)
0000:00:08.0 System peripheral: Intel Corp. Memory Controller Hub
Extended Configuration Registers (rev 0c)
0000:00:1c.0 PCI bridge: Intel Corp. 6300ESB 64-bit PCI-X Bridge (rev
02)
0000:00:1d.0 USB Controller: Intel Corp. 6300ESB USB Universal Host
Controller (rev 02)
0000:00:1d.1 USB Controller: Intel Corp. 6300ESB USB Universal Host
Controller (rev 02)
0000:00:1d.4 System peripheral: Intel Corp. 6300ESB Watchdog Timer (rev
02)
0000:00:1d.5 PIC: Intel Corp. 6300ESB I/O Advanced Programmable
Interrupt Controller (rev 02)
0000:00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 0a)
0000:00:1f.0 ISA bridge: Intel Corp. 6300ESB LPC Interface Controller
(rev 02)
0000:00:1f.1 IDE interface: Intel Corp. 6300ESB PATA Storage Controller
(rev 02)
0000:00:1f.3 SMBus: Intel Corp. 6300ESB SMBus Controller (rev 02)
0000:01:01.0 VGA compatible controller: ATI Technologies Inc Radeon
RV100 QY [Radeon 7000/VE]
0000:02:01.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030
PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 08)
0000:04:00.0 PCI bridge: Intel Corp. PCI Bridge Hub A (rev 09)
0000:04:00.2 PCI bridge: Intel Corp. PCI Bridge Hub B (rev 09)
0000:05:01.0 Ethernet controller: Broadcom Corporation NetXtreme
BCM5704S Gigabit Ethernet (rev 10)
0000:05:01.1 Ethernet controller: Broadcom Corporation NetXtreme
BCM5704S Gigabit Ethernet (rev 10)
0000:00:00.0 0600: 8086:3590 (rev 0c)
0000:00:00.1 ff00: 8086:3591 (rev 0c)
0000:00:03.0 0604: 8086:3596 (rev 0c)
0000:00:08.0 0880: 8086:359b (rev 0c)
0000:00:1c.0 0604: 8086:25ae (rev 02)
0000:00:1d.0 0c03: 8086:25a9 (rev 02)
0000:00:1d.1 0c03: 8086:25aa (rev 02)
0000:00:1d.4 0880: 8086:25ab (rev 02)
0000:00:1d.5 0800: 8086:25ac (rev 02)
0000:00:1e.0 0604: 8086:244e (rev 0a)
0000:00:1f.0 0601: 8086:25a1 (rev 02)
0000:00:1f.1 0101: 8086:25a2 (rev 02)
0000:00:1f.3 0c05: 8086:25a4 (rev 02)
0000:01:01.0 0300: 1002:5159
0000:02:01.0 0100: 1000:0030 (rev 08)
0000:04:00.0 0604: 8086:0329 (rev 09)
0000:04:00.2 0604: 8086:032a (rev 09)
0000:05:01.0 0200: 14e4:16a8 (rev 10)
0000:05:01.1 0200: 14e4:16a8 (rev 10)
Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
Initial boot worked: [O]
Configure network HW: [O]
Config network: [O]
Detect CD: [O]
Load installer modules: [O]
Detect hard drives: [O]
Partition hard drives: [O]
Create file systems: [O]
Mount partitions: [E]
Install base system: [O]
Install boot loader: [O]
Reboot: [E]
Comments/Problems:
I installed using the "expert26" option; I haven't tried the 2.4 kernel
(though I believe it has drivers for all the hardware), nor non-expert
mode. (I don't see any reason why the latter would have any problems
other than the ones I ran into anyway, though.)
The installer complained several times about hardware for which it
hadn't yet loaded the driver modules. Since most of these were (as the
disclaimer mentions) loaded later in the normal course of the
installation, it would be nice if it didn't complain about things
(particularly network and SCSI drivers) where it knows it probably
hasn't loaded the driver yet. Some drivers were never loaded, however
(probably because the hardware didn't exist) - ide-probe, ide-floppy,
and I think the other two were the regular IDE disk and floppy disk
drivers (but I could be wrong about that). This isn't entirely
unexpected - the machine has no IDE devices, though it does have an IDE
controller. It does have a floppy drive, though; it's USB, like the CD
drive, and was apparently detected as a regular SCSI disk. This caused
problems later on.
I had no problems with the initial installation; the error noted for
the "mount partitions" stage came about while I was setting up the MD
devices described above. I think I managed to confuse the installer
slightly, such that one of the partitions in /dev/md3 (almost certainly
the one on the first SCSI disk, for reasons mentioned below) didn't get
correctly marked as a RAID component, and the array got started in
degraded mode. This didn't prevent me continuing with the installation,
though, and if I hadn't been watching the output fairly closely I might
not even have noticed it.
The problem came after the reboot step. During the installation, USB
devices were probed before SCSI, and the floppy drive on the media tray
was detected at this point. It was treated as a generic disk (I'm not
sure if SCSI floppies are normally treated differently to hard disks -
<http://www.debian.org/releases/testing/m68k/apbs04.html.en> seems to
suggest that they aren't, but I don't know how much of that is
m68k-specific); thus it got assigned to /dev/sda. The hard disks were
detected after the Fusion SCSI driver was loaded, and became /dev/sdb
and /dev/sdc. Unfortunately, after the reboot step, this changed; the
hard disks were then /dev/sda and /dev/sdb, and the USB floppy wasn't
detected by default. (Even if it had been, its presence couldn't be
guaranteed on future reboots; blade servers usually run without access
to the chassis media tray.)
If I'd been performing a normal install, especially if I'd only
partitioned one disk, this would have caused the reboot to fail; GRUB
would have loaded the kernel with root=/dev/sdb1 (which wouldn't have
been valid), and all the /etc/fstab entries would likewise have been
pointing to the wrong devices. As it was, since I had all filesystems
on RAID arrays, I got away with only a little trouble; the root array
thought it was made up of /dev/sdb1 and /dev/sdc1, and while /dev/sdc1
(like the rest of /dev/sdc) was no longer there, that disk was now
/dev/sdb, so /dev/sdb1 was still valid (though on a different physical
disk to the one it was at array creation.) All the arrays came up
(though in degraded mode), and I was able to finish the install and
hot-add the (now) /dev/sda partitions to the arrays using mdadm.
I don't know what could be done to avoid the problem, unfortunately.
While in some cases SCSI devices could be probed first, in this case USB
devices were necessary (the CD was mounted there) in order to load the
driver for the SCSI controller...
On another note, the auto-partitioning tool could use a bit of work.
It created partitions in about the same order as those mentioned above;
however, the root partition was very small (~260MB), and most of the
others were sized to fit what looked like an 18GB disk. Except for the
last one (/home), where the auto-partitioner realised it still had about
60GB of space, and allocated all of it to that one partition. Wouldn't
it make more sense if there's lots of room to just scale up all
partitions (possibly with limits on, say, swap and /tmp) equally?
Still, much easier than the horrible hackery necessary to get stable
installed on the older (SBXL52) blade hardware, and which would probably
also be necessary (slightly modified) for these ones. I imagine testing
would also install on the SBXL52 blades with as little problem; they're
mostly identical, but with a ServerWorks chipset, IDE disks (normally),
and they use OHCI rather than UHCI for the USB devices.
Jonathan Santaana
Systems Administrator
New Zealand Exchange Limited
http://www.nzx.com/
Reply to: