OK, I'm at my wits end here. Stupid me.
I've been reading this site for several years and have converted several zyxel NDA320's and 310's to Debian using the instructions here on this site. I'm now doing another one after the zyxel firmware screwed it up and almost cost me the data on it.
Thinks are going very well as I kept most of my notes. Unfortunately I have it one item that I cannot for the life of me figure out what I did 2 years ago to get it working. Part of my install is converting the two 2TB disks over to md raid arrays.
After making sure everything worked on /dev/sda1 without issue (non-raid), I went through the steps here: Making a RAID1 rootfs to get setup on an md raid array for the root, swap, and data partitions (/dev/sdb1,2,3).
Part of the steps involve creating a new initramfs file so you load the md drivers early enough to boot the root partition off them.
Simply put, if I boot off the non raid /dev/sda1, it all works but the mdadm devices are not started until after the root filesystem starts (as expected). If I boot off /dev/sdb1 which is part of /dev/md0 (1 of 2) using the new initfs I created as part of the link above, I can boot the root filesystem just fine, but I lose eth0.
I have a working NSA320 on kernel 4.2.0 that is completely md raid 100% and has working eth0. This is the working system I built 2 years ago.
I have a new NSA320 on kernel 4.4.0 (feb 2016 rootfs/kernel) that boots the md raid volume but fails to start eth0.
I suspect I have simply missed something and can't for the life of me find it.
Note: if I copy the new uImage and uInitfs that have the md drivers loaded in the initfs from the /dev/md0 partition to the /dev/sda1 (non md) partition and slide them in place, /dev/sda1 will boot but also loses eth0. The core issue seems to be the "new" initfs generated after setting up md does not have the network device driver.
I've done the obvious and verified my uboot parms are good and ethaddr has the right MAC address. The line in /etc/udev/rules.d/70-persistent-net.rules for eth0 has the matching correct MAC listed so *that* isn't it.
I worry that the needed device driver is only in Bodhi's initfs that is provided as part of his kernel builds. When I rebuilt initfs and overwrote his, I may have messed this up. However, I have my working NSA320 that does both the early md array start as well as provide a working eth0 so I got this to work somehow 2 years ago.
Attached are three files, 2 console boot messages with each md/eth situation and one /proc/modules file from the working system as well as each of the md/eth boots.
I've been working this for 3 days now. Someone point me in the right direction in case I've just missed something obvious.
I've been reading this site for several years and have converted several zyxel NDA320's and 310's to Debian using the instructions here on this site. I'm now doing another one after the zyxel firmware screwed it up and almost cost me the data on it.
Thinks are going very well as I kept most of my notes. Unfortunately I have it one item that I cannot for the life of me figure out what I did 2 years ago to get it working. Part of my install is converting the two 2TB disks over to md raid arrays.
After making sure everything worked on /dev/sda1 without issue (non-raid), I went through the steps here: Making a RAID1 rootfs to get setup on an md raid array for the root, swap, and data partitions (/dev/sdb1,2,3).
Part of the steps involve creating a new initramfs file so you load the md drivers early enough to boot the root partition off them.
Simply put, if I boot off the non raid /dev/sda1, it all works but the mdadm devices are not started until after the root filesystem starts (as expected). If I boot off /dev/sdb1 which is part of /dev/md0 (1 of 2) using the new initfs I created as part of the link above, I can boot the root filesystem just fine, but I lose eth0.
I have a working NSA320 on kernel 4.2.0 that is completely md raid 100% and has working eth0. This is the working system I built 2 years ago.
root@jaynas03:~ # lspci
00:01.0 PCI bridge: Marvell Technology Group Ltd. 88F6281 [Kirkwood] ARM SoC (rev 03)
root@jaynas03:~ # ifconfig -a
eth0 Link encap:Ethernet HWaddr fc:f5:28:08:ac:b3
inet addr:172.19.100.125 Bcast:172.19.255.255 Mask:255.255.0.0
inet6 addr: fe80::fef5:28ff:fe08:acb3/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:16766 errors:0 dropped:0 overruns:0 frame:0
TX packets:5926 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1423266 (1.3 MiB) TX bytes:647922 (632.7 KiB)
Interrupt:88
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:24 errors:0 dropped:0 overruns:0 frame:0
TX packets:24 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1440 (1.4 KiB) TX bytes:1440 (1.4 KiB)
I have a new NSA320 on kernel 4.4.0 (feb 2016 rootfs/kernel) that boots the md raid volume but fails to start eth0.
root@jaynas01:~ # lspci
root@jaynas01:~ # ifconfig -a
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:28 errors:0 dropped:0 overruns:0 frame:0
TX packets:28 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1680 (1.6 KiB) TX bytes:1680 (1.6 KiB)
I suspect I have simply missed something and can't for the life of me find it.
Note: if I copy the new uImage and uInitfs that have the md drivers loaded in the initfs from the /dev/md0 partition to the /dev/sda1 (non md) partition and slide them in place, /dev/sda1 will boot but also loses eth0. The core issue seems to be the "new" initfs generated after setting up md does not have the network device driver.
I've done the obvious and verified my uboot parms are good and ethaddr has the right MAC address. The line in /etc/udev/rules.d/70-persistent-net.rules for eth0 has the matching correct MAC listed so *that* isn't it.
I worry that the needed device driver is only in Bodhi's initfs that is provided as part of his kernel builds. When I rebuilt initfs and overwrote his, I may have messed this up. However, I have my working NSA320 that does both the early md array start as well as provide a working eth0 so I got this to work somehow 2 years ago.
Attached are three files, 2 console boot messages with each md/eth situation and one /proc/modules file from the working system as well as each of the md/eth boots.
I've been working this for 3 days now. Someone point me in the right direction in case I've just missed something obvious.