[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#543443: marked as done (installation-reports: eventual success on QNAP TS-219)

Your message dated Mon, 9 Nov 2009 21:59:50 +0000
with message-id <20091109215950.GA16259@reptile.pseudorandom.co.uk>
and subject line Re: Bug#543443: installation-reports: eventual success on QNAP TS-219
has caused the Debian Bug report #543443,
regarding installation-reports: eventual success on QNAP TS-219
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
543443: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543443
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: installation-reports
Severity: normal

-- Package-specific info:

Boot method: network
Image version: 20090819 daily, http://people.debian.org/~joeyh/d-i/armel/images/20090819-23:51/kirkwood/network-console/qnap/ts-219/
Date: 2009-08-20

Machine: QNAP TS-219
Partitions:

Disks are partitioned as 1GB + the rest:

testament:~# fdisk -l /dev/sda

Disk /dev/sda: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x6e29c273

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1         122      979933+  82  Linux swap / Solaris
/dev/sda2             123      182401  1464156067+  fd  Linux raid autodetect

sdb has an identical layout.

sdb1 is swap, sda1 is currently unused.

sd?2 are combined into md0 with software RAID1:

testament:~# cat /proc/mdstat 
Personalities : [raid1] 
md0 : active raid1 sda2[2] sdb2[0]
      1464155968 blocks [2/1] [U_]
      [=====>...............]  recovery = 26.6% (390349632/1464155968) finish=216.6min speed=82586K/sec

md0 is the only physical volume in a LVM volume group:

testament:~# lvdisplay 
  --- Logical volume ---
  LV Name                /dev/testament/root
  ...
  LV Size                46.56 GB
  ...
  --- Logical volume ---
  LV Name                /dev/testament/srv
  ...
  LV Size                1.32 TB



Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:           [E]
Detect network card:    [O]
Configure network:      [O]
Detect CD:              [O]
Load installer modules: [O]
Detect hard drives:     [E]
Partition hard drives:  [O]
Install base system:    [O]
Clock/timezone setup:   [O]
User/password setup:    [O]
Install tasks:          [O]
Install boot loader:    [O]
Overall install:        [O]

Comments/Problems:

I constructed a serial console cable according to tbm's documentation and
used it with a USB <-> 3.3V serial adaptor, which was useful to get the
thing booted, but may have caused some of the problems it helped me to solve -
the 3.3V power from my laptop's USB was apparently enough to keep the board
running even with the AC adaptor unplugged!

I flashed the daily build kernel/ramdisk by booting into the QNAP firmware
(only the minimal version in flash - I never installed anything from the
supplied CDs to the disks) and using the flash-debian script; however,
I ended up loading them over tftp instead.

Booting with the serial console appeared to stop at the stage of starting
init; I never got a shell on the serial port, and d-i never got as far as
doing DHCP, for some reason (the server's logs indicate that it never received
a request). In the absence of a shell, I couldn't debug this.

I eventually booted from tftp with:

setenv serverip 10.13.0.1
setenv ipaddr 10.13.0.35
setenv bootargs console=ttyS0,115200n8 root=/dev/ram rw initrd=0xa00000,0x900000 BOOT_DEBUG=9
tftpboot 0xa00000 ts219-initrd.gz
tftpboot 0x800000 ts219-kernel
bootm 0x800000

(Changes compared with tbm's instructions: he used the wrong size for the
initrd, causing truncation and boot failure; also, I added BOOT_DEBUG to be
able to get an early shell.)

To work around the failure to run things from init, I exited from the first
shell offered, then ran dhclient, debian-installer-startup and debian-installer
(in that order) in the second (run just before init), and never actually
allowed init to start. With hindsight, running dhclient was probably
unnecessary.

d-i on the serial console eventually told me it was starting the SSH server,
and I switched to SSH for the rest of the installation.

At the "partition disks" stage, no disks were found or offered for
partitioning; dmesg reported that both SATA links were down.

I tried forcing a scan (echo 1 > /sys/class/scsi_host/host2/scan
and the same for host3), which caused the Samsung disk in bay 2 (host3) to
wake up and be detected as sda; the Western Digital disk in bay 1 (host2) was
still not detected. I continued the install onto the Samsung disk only,
configuring it for a degraded 2-disk RAID1 array.

As a result of the strange hacks I'd done to start d-i, exiting from the
main menu with "finish installation" didn't work. I used the "magic sysrq
key" on the serial console (Break S Break U Break O) to shut down wthout
data loss. I now realise that the detailed installation logs were probably lost 
during this process; sorry about that.

I suspected that the serial console providing partial power to the board might
be causing problems, so I disconnected it before the first boot of the
installed system. As I'd hoped, both disks were brought up correctly
in the installed system, so I duplicated the partition layout from the
installed Samsung (now sdb) onto the uninitialized Western Digital (now sda),
and added it to the RAID array.

-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to submit@bugs.debian.org.

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: armel (armv5tel)

Kernel: Linux 2.6.30-1-kirkwood
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Attachment: report-hw.gz
Description: application/gzip


--- End Message ---
--- Begin Message --- 
On Sat, 19 Sep 2009 at 17:49:19 +0100, Martin Michlmayr wrote:
> * Simon McVittie <smcv@debian.org> [2009-08-25 01:50]:
> > Booting with the serial console appeared to stop at the stage of starting
> > init; I never got a shell on the serial port, and d-i never got as far as
> > doing DHCP, for some reason (the server's logs indicate that it never received
> > a request). In the absence of a shell, I couldn't debug this.
> 
> I cannot reproduce this.  I just took a daily image and it boots fine.
> I first see the kernel messages, then "Starting system log daemon:
> syslogd, klogd." and then a black screen with a green cursos and a
> little bit later I get a window with DHCP.
> 
> Can you please boot the installer again and see what happens?

I tried this with the 2009-11-09 daily image and it seems fine.

> > I suspected that the serial console providing partial power to the board might
> > be causing problems, so I disconnected it before the first boot of the
> > installed system. As I'd hoped, both disks were brought up correctly
> > in the installed system
> 
> So you're saying the disk didn't come up in d-i because of the serial
> connector?  So can I ignore this issue?

I think so. In later experiments my homemade serial connector seemed to work
better with the 3.3V line omitted entirely... it might be worth noting in
documentation that the serial console is not only unnecessary (due to the
recovery mode), but possibly harmful!

in any case, I think this bug can be closed, and am doing so now.

Thanks,
    Simon

--- End Message ---
Reply to: