I just tested it on my 8.11 VM and it fails to build there as well for the reason you mentioned (the lack of initrd)

Nope. Debian 8.11 virtual machine.

@max1e6 Is your build directory on NFS? I had that problem when my build directory was being stored on NFS

And I think the issue I am encountering is different. I am trying to build without pulling any additional modules...it builds "fine" but fails to build the ISO. I have been researching the issue and found a couple of articles that indicate that the build of the img is "delayed"...not built which is why the copy fails.

@max1e6 I don't think so. I was building on a Jessie VM for a while as well as Docker, and both fail

I have been using Debian 8.11 as my build machine...Could that be an issue?

So, I can reproduce the missing initrd issue now as well, but I have no idea why it happens. It doesn't happen in ci, so I assume some local pacakge or command is missing. I did chroot into the chroot before squashfs is being packed and did a live-update-initramfs, which worked with no issues. So a missing driver can be ruled out here.
but I get then an issued that the arch isn't supported :D.

There are definitely strange happenings.

That looks liek a similar f'up. The correct ddclient version is 3.8.2+vyos2+current1, no idea where lithium6 comes from. The correct pkg is within the repo: http://dev.packages.vyos.net/repositories/current/vyos/pool/main/d/ddclient/ddclient_3.8.2+vyos2+current1_all.deb and the current vyatta-cfg-system has no dependency to vyatta-dhcp3-client (https://github.com/vyos/vyatta-cfg-system/blob/current/debian/control).

I see, I have a look.

Okay, I think I've nailed down what's going on. A fresh build with no modules (git clone, configure, make iso), works fine.

I am still getting an error building the ISO.

I am still having issues building the ISO. I have deleted the vyos-build directory and trying again from scratch.

Actually I spoke too soon. The next run resulted in this, on a 100% fresh build tree.

@hagbard Thanks! I guess I was just running make clean. Removing the build directory and rerunning configure seems to have corrected it.

@kroy please make sure that you do it from a clean build tree. I run it now locally from home and everything is working well. You can also do a ./configure --debug && make iso, which is more verbose.

It's actually failing somewhere else now:

@kroy or @runar
Can please one of you test if the build outside ci is working again too? Shouldn't make any difference, but before I close this bug I'd like to have confirmation (and happy faces) from one of you as well.

I rebuilt the package (vyatta-cfg-quagga) which removed the old one from the repo and re-published the correct version. I tested with apt that the correct packages is being queried/installed. Looks all good now from my point of view.

http://dev.packages.vyos.net/repositories/current/vyos/dists/unstable/main/binary-amd64/Packages contains the wrong package.
faulty one: http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyatta-cfg-quagga/vyatta-cfg-quagga_0.18.172_amd64.deb

This might be related to T1079

@begetan Yeah, very strange. I need to check why this issue re-appeared, hope I'll get it fixed by tomorrow.

Checked in 1.2.0-rolling+201812010337, all works fine.
Vtysh:

root@vyos:/home/vyos# vtysh

In the latest rolling update build for AWS AMI there is no quagga package, because it was replaced by FRR. Should be the same for regular build.

Can you check if we have
https://github.com/FRRouting/frr/pull/3143/files

Unfortunately not corrected in RC9. After 30 minutes the default route fails to distribute.

we bumped frr to the last master in rc9
check there, if still exist we can go ask frr guys

can you retest on rc9
frr was updated to the latest

I confirm this issue at VyOS 1.2.0-rolling+201811290337

This is great an very important feature for AWS since they introduced very cheap and advanced t3 instances.

It's triggered by systemd, so it will happen before the config is fully loaded. It might be better to move that into the cli config and execute with prio 999, that way it will be definitely the last script running.

The problem is not the boot time per se, it is the slowness of the console.

System bootup time is something we should not care, as a router is not rebootet that often. Infact the startup time depends on the amount of configured services or firewall rules. We recently increased the timeout for starting of VyOS to also make it work on slower Intel Atom D525 platforms where a huge firewall config was loaded.

Confirmed that the posted RC9 works now too

confirmed. This rolling release has a working wireguard.

@dmbaturin updated image of rc9,
please check it

@kroy can you please use the rolling release. I checked the module does work in rolling.

I was thinking about swatting. Draws the most attention. (We(s)tcoast Canada)

I know. Please don't contact him by phone :-)

@Line2 He will be in bed right now. It's 11pm in Germany.

maybe contact @c-po for kernel 4.19.4

Well not really, the ones who rebuilt the new kernel didn't know about those. I'm working on IPoE integration (similar like a PPPoE server but without the PPP =), They won't do anything.

As another question, is that a bug that ipoe.ko and vlan_mon.ko are ending up under the old kernel modules?

Hmm, ok I gotta check on that.

That didn't do anything.

Hmm. looks strange. 4.19.0-amd64-vyos isn't required as you are running on 4.19.4-amd64-vyos. Can you load the module manually? (sudo modprobe wireguard).

Umm, that's not what happened. It looks like it needs to be in the 4.19.0 directory to work

Please download http://dev.packages.vyos.net/repositories/current/vyos/pool/main/w/wireguard/wireguard-modules_0.0.20181018-1_amd64.deb and install via 'dpkg -i <pkg name>'.

Kernel module hasn't been rebuilt on our side. The current package will put that under /lib/modules/4.19.0-amd64-vyos/extra/ and your kernel is 4.19.4 and won't find it. I have a look into the package right now.

Linux route-extern.xxx.xx.xx 4.19.4-amd64-vyos #37 SMP Mon Nov 26 10:03:40 CET 2018 x86_64 GNU/Linux

Can you please send me the output of 'uname -a'. Thx.

The script won't accept anything but the detected config file.
/config/config.boot does not actually exist before booting from the installed image (even though it is mentioned when saving the config). As far as I can tell, the configuration is saved in /opt/vyatta/etc/config/config.boot but that is not accepted by the install image script either.

Have you tried specifying /config/config.boot instead?

Problem seems to be coming from there being no queue set on the interface, setting a queue manually resolves the issue till the device is restarted

man strace(1) indicates that it opens several system files until it gets a match for any known distro.

Another way is to check in /etc/os-release, but that is also a changeable file.... Wondering where lsb_release reads it from ( no pc atm, so cannot check)

VyOS ships a serial port interface in the default configuration upon installation.