Linux v4.15.8 available for experimentation

[Neil Brown]

I have the latest stable version of Linux - v4.15.8 - running on my gnubee-pc1.

The source is available in my linux project on github, in the gnubee/v4.15 branch so you can get a copy with "git clone git://github.com/neilbrown/linux -b gnubee/v4.15". There is a README.gnubee file which explains how I build a gnubee.bin firmware image.

All the devices seem to work: SATA, USB, ethernet, sd-card.  However I only got the ethernet working a couple of hours ago so I haven't done much testing - hence the suggestion that it be for experimentation.

If you try it out, please report your success of otherwise.

[xmikol...@gmail.com]

Please share your gnubee.bin image.

[Tom Hunt]

Just tried this out. Build process went fine. It works with the root image on SD, though the readme says it won't; may want to update that.

For some reason the ethernet isn't working (using the same userspace configuration that worked with the 3.10.14 kernel). I can see the devices, but dhclient doesn't give them IPs and there's no network connection. Can work on this some more later.

[Neil Brown]

Thanks for testing!

I've just pushed out an update which

• updates the README as suggested
  
• adds support for all the SATA slots (only 2 worked before)
• Correctly handle "halt" - it doesn't reboot now, it just halts
  
• updates the base to 4.15.12

Networking works for me, but the config might be a bit different to 3.10.14.
I think the 3.10 kernel provided two interface (eth0 and eth1) - one on each port.
4.15 doesn't support that yet.  The internal bridge is configured as a simple bridge and only eth0 is available. Packets sent on eth0 can go out either physical port.
It'll be a while before we get proper bridge/vlan support and can support multiple subnets.
However your description of the problem doesn't suggest it is related to that difference.
One other network issue is that hot-plugging cables doesn't work very well.
So if you boot with the cable plugged in and run dhclient on eth0 it *should* work.

[Tom Hunt]

I've got a PC2, with three ports. The setup that came on the default card's /etc/network/interfaces has eth0.1 and eth0.2, somehow bridged or something. By default one of the ports gets a statically assigned 192.168.1.1 and can be used for PC-to-PC linking, I guess? But that setup broke the other interface, so I took it out of the file.

Maybe next I'll try getting rid of /etc/network/interfaces completely and trying for a full manual setup. I'm not sure what's responsible for creating the eth0, eth0.1, eth0.2 arrangement.

[Tom Hunt]

Update: after pulling your latest update and trying to build again, 'make O=O gnubee1_defconfig' fails with:

***
*** Can't find default configuration "arch/x86/configs/gnubee1_defconfig"!
***

This is after building the prior version already, so I'm not sure what kind of cleanup operation may or may not be needed in between.

[Brett Neumeier]

On Thu, Mar 22, 2018 at 11:56 AM, Tom Hunt <tomdick...@gmail.com> wrote:

Update: after pulling your latest update and trying to build again, 'make O=O gnubee1_defconfig' fails with:

***
*** Can't find default configuration "arch/x86/configs/gnubee1_defconfig"!
***

​The "x86" in th​at directory name suggests you have not set the ARCH environment variable; perhaps recheck that? And the CROSS_COMPILE environment variable, as well, just in case.​

--

Brett Neumeier (bneu...@gmail.com)

[Tom Hunt]

Okay, I'm dumb. Was typing in the wrong shell.

With the environment correct, builds fine. I'll try it on the machine once I get home.

[Neil Brown]

The kernel I provided is focused on the PC1 (the only one I have).  It should mostly work on the PC2, but only 2 of the network ports will be enabled.  Once I know which internal switch port the 3rd external port is connected to, I can easily make a gnubee2_defconfig which adds that port, but it will just be another port on the transparent switch.

[Neil Brown]

Was typing in the wrong shell.

I did that a few times.  Now I have a shell script called "gbmake" which runs "make" with the right environment and extra command line arguments.  When I do "gbmake modules" it also runs the required "modules_instlal",
and when I do "gbmake uImage", it also copy the uImage to  /srv/tftpboot/GB-PCx_uboot.bin so I can do a tftp-boot.

[Brett Neumeier]

On Thu, Mar 22, 2018 at 3:36 AM, Neil Brown <ne...@brown.name> wrote:

Thanks for testing!

I've just pushed out an update which

• updates the README as suggested
  
• adds support for all the SATA slots (only 2 worked before)
• Correctly handle "halt" - it doesn't reboot now, it just halts
  
• updates the base to 4.15.12

​Hi Neil!

Thanks so much for doing all this work and sharing it! I am delighted to be able to upgrade to a latest-stable kernel with relatively few patches, and I really appreciate you setting up a minimal initramfs userspace -- that makes a great starting point.

I have both a PC1 and a PC2; if I can help at all to improve support for the PC2 by doing any testing, please just let me know.

My initial testing with commit 772503432ecda3cb4790d765211d6f19eec14d34 seems successful; one minor infelicity is that the /init script doesn't load the ahci module and it's therefore unable to find my GNUBEE-ROOT partition on /dev/sdc1. I'll tweak that and try with an updated initramfs in a bit. (I'm not using a cross-toolchain, just building the kernel natively on the gnubee, so everything takes a while.)

Cheers,

Brett

--

Brett Neumeier (bneu...@gmail.com)

[Brett Neumeier]

On Fri, Mar 23, 2018 at 3:23 PM, Brett Neumeier <bneu...@gmail.com> wrote:

My initial testing with commit 772503432ecda3cb4790d765211d6f19eec14d34 seems successful; one minor infelicity is that the /init script doesn't load the ahci module and it's therefore unable to find my GNUBEE-ROOT partition on /dev/sdc1. I'll tweak that and try with an updated initramfs in a bit. (I'm not using a cross-toolchain, just building the kernel natively on the gnubee, so everything takes a while.)

​Update -- ​after adding ahci to the set of modules loaded by /init, the PC1 boots successfully. The network configuration I have, that works fine with the 4.4.87 kernel, doesn't work -- I have "iface eth0.2 inet dhcp" in /etc/network/interfaces, for what that's worth. If I disable the debian network configuration, I can then "dhclient eth0" and that works, so maybe it's okay? I don't really understand how the network hardware on the gnubee works. Something about "transparent switch"? "internal switch ports"? IDK.

I enabled some additional kernel modules, including the XTS dm-crypt mode, so LUKS works with the default cipher mode now; that's kind of cool!

One of my goals is to have the kernel that lives in the firmware be a kind of second-stage bootloader -- that is, I'd like its job to be to find the real kernel and root filesystem on hard drive partitions, and then uses kexec to boot a kernel that resides on the hard disk. So I'm going to try to bundle the kexec tools into the initramfs as well and see if I can get that to work.

--

Brett Neumeier (bneu...@gmail.com)

[Tom Hunt]

I don't know how the Gnubee's hardware works, but my setup is just to replace "eth0.2" with "eth0" everywhere in the default /etc/network/interfaces (so the relevant stuff is just "auto eth0<newline>iface eth0 inet dhcp") and remove the stuff about eth0.1 that sets a static IP. Once I found the right network port on the PC2 (the middle one, I think?) this worked fine.

I'm also getting a periodic network crash since I've been working with it, that seems to break the connection to everything on the switch the PC2 is on. But I haven't even definitively traced this to the PC2, so no real comment there yet.

[Brett Neumeier]

​I found a couple of minor infelicities in the README.gnubee and put in some suggested revisions, as well as adding the ahci module, in the attached.

--

Brett Neumeier (bneu...@gmail.com)

[Tom Hunt]

I've now basically verified that the network crash problem I mentioned earlier is in fact due to the PC2. Details:

 - I've got three or four devices on a switch, including desktop, PC2, a Raspberry Pi (currently what the PC2's serial output is plugged into)
 - Switch is connected to the household router
 - Intermittently, network access through the switch fails for no obvious reason; devices that are on the router directly still work fine, but can't access anything that's on the switch; devices on the switch can still talk to each other for a while, only until ARP fails (or whatever) and the switch stops forwarding packets
 - This only happens while the PC2 is on
 - Powering off the PC2 (directly, via the power switch) fixes the problem immediately

I think this only happened since I've been working with the 4.15 kernel, but couldn't swear to it.

I have no idea what is causing it specifically, nor any immediate thoughts about how to debug. The router is running an ancient version of OpenWRT, which I'm planning to upgrade today or tomorrow; conceivably the upgrade will fix it.

[Tom Hunt]

I have a patch here that makes cryptsetup/dm-crypt work, and also includes support for an encrypted root partition. (Creating this encrypted root partition is still a bit of a pain.)

Patch changes:

 - Update gnubee1_defconfig to include a bunch of crypto options as modules. This includes the algorithms and modes dm-crypt needs, plus the userspace APIs so 'cryptsetup benchmark' can work.
 - Add the cryptsetup binary to the initramfs
 - Mount devtmpfs on /dev, rather than just tmpfs. The mdev hotplug wasn't working for me for some reason, so I needed this for manual work in the initramfs. Probably not strictly necessary now that the script is done.
 - Add ahci per Brett's patch above
 - On boot, scan for a partition with partition label 'GNUBEE-CRYPT-ROOT' (needs to be GPT for this to work); if found, decrypt it, prompting for passphrase on serial console, and use it as root; if not, scan for GNUBEE-ROOT and use that; if that's not found, do rescue shell

[Tom Hunt]

Now with the actual patch file.

[Neil Brown]

On Sunday, March 25, 2018 at 7:35:56 AM UTC+11, Tom Hunt wrote:

Now with the actual patch file.

Thanks. I applied Brett's patch and then yours, checked that I could still build and boot the firmware, and pushed the result to github.