Zyxel NSA-320 - /dev/sdb not detected

[malamis]

Hello Folks,

starting out with both arch and arm with the Zyxel box, worked through most of the guides and issues here with the latest software versions from the arch site. uname -a shows Linux bremen 3.1.10-33-ARCH #1 PREEMPT Sun Apr 27 02:45:06 MDT 2014 armv5tel GNU/Linux

Problem is currently that fdisk -l shows

$this->bbcode_second_pass_code('', '[root@bremen dev]# fdisk -l
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x0b27ae0e
Partition 1 does not start on physical sector boundary.
Partition 2 does not start on physical sector boundary.

Device Boot Start End Blocks Id System
/dev/sda1 63 48194 24066 83 Linux
/dev/sda2 48195 1953520064 976735935 83 Linux

')
when there are in fact 2 drives in the machine.

this thread indicated something about GPIO not being set correctly, but given the fragility of the system (and because the disk has meaningful data on it) i'm wary of running anything for the 325 on a 320, if that is in fact the problem.

Running fdisk -l after booting to_stock gives:
$this->bbcode_second_pass_code('', '
Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x0b27ae0e

Device Boot Start End Blocks Id System
/dev/sda1 1 3 24066 83 Linux
/dev/sda2 4 121601 976735935 83 Linux

Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x1cf8aac5

Device Boot Start End Blocks Id System
/dev/sdb1 1 24315 195310206 83 Linux
/dev/sdb2 24316 48630 195310237+ 83 Linux
/dev/sdb3 48631 72945 195310237+ 83 Linux
/dev/sdb4 72946 121602 390831871+ 83 Linux
')
so the drive and physical connection evidently work.

All of them are ext2 formatted.

Please help! Run out of notions as to what it could be.

[WarheadsSE]

That's definitely .. unexpected. Let me go look up the GPIO pin.

EDIT:
Looked. Do NOT whack gpio 47 on a NSA320. But that is odd, because that drive should be getting kicked up. Hrm. What kernel version is this happening on?

[malamis]

Sounded pretty emphatic on 47!

uname -r returns 3.1.10-33-ARCH for the kernel version.
$this->bbcode_second_pass_code('', '
[root@bremen ~]# lsmod
Module Size Used by
nsa3xx_hwmon 389 0
mv_cesa 9362 0
ipv6 272990 10
autofs4 22305 2
')

[WarheadsSE]

I would suggest moving to linux-kirkwood, if only for being much newer.

[malamis]

This seems to indicate the kirkwood specific kernel has been discontinued/merged and pacman Qi linux-mvebu does nothing (cargo cult long shot) - compiling the mvebu branch presently out of limited understanding of alternatives.

[WarheadsSE]

Thats for future kernel versions.

[malamis]

Alright, now I'm pretty stumped on how to replace the kernel image after successful compilation and the installer from here sets the kernel from /dev/sda1 with relevant magic numbers I've spent most of today trying to figure out. Is there a specific guide that's not on the main archlinux wiki which provides instruction on how to compile the image in the correct format and determine the correct entry point?

As an aside, I tried (familiar) Slackware over tftp after compiling their kirkwood with the .dtb for the 320 in the uImage, but that failed as well in that not only the second drive didn't get recognised during setup, but also the network driver didn't load correctly after getting in to setup (even after run to_stock reboot to set the network).

Seriously running out of ideas, had this thing for 2 months now, and it's yet to do anything remotely useful


Edit:
It turns out I was using the 320S, which pretty much explains everything.