Booting on VMware ESX with EFI works as expected.

Is this still an issue? Or does it now work in EFI systems?

Okay, root cause is the extraction script which parses the Kernel source for included source/object files.

@jjakob by a weird coincidence I yesterday received a Thinkpad T420s which shows the exact same error.

You may use dpkg to unpack and install according to the following information:

This is the users dmesg with failed firmware load

[   21.951100] iwlwifi 0000:03:00.0: can't disable ASPM; OS doesn't have ASPM control
[   21.951932] iwlwifi 0000:03:00.0: Direct firmware load for iwlwifi-6000-6.ucode failed with error -2
[   21.951961] iwlwifi 0000:03:00.0: Direct firmware load for iwlwifi-6000-5.ucode failed with error -2
[   21.951982] iwlwifi 0000:03:00.0: Direct firmware load for iwlwifi-6000-4.ucode failed with error -2
[   21.951985] iwlwifi 0000:03:00.0: no suitable firmware found!
[   21.958303] iwlwifi 0000:03:00.0: minimum version required: iwlwifi-6000-4
[   21.967817] iwlwifi 0000:03:00.0: maximum version supported: iwlwifi-6000-6
[   21.975992] iwlwifi 0000:03:00.0: check git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git

In T2594#67314, @jack9603301 wrote:

For driver firmware, it's just a ko file, which can then be used by setting the boot in the configuration directory to automatically load the kernel file, or by using the following command:

depmod
modprobe myko

Considering the general Linux, the path of this driver and kernel component is usually:

/lib/modules/`uname -r`/kernel/driver/mymod/

Okay, the file is correctly installed, the question is, why the firmware is not accepted by the card. So there is no bug in general of the build system.

For driver firmware, it's just a ko file, which can then be used by setting the boot in the configuration directory to automatically load the kernel file, or by using the following command:

@jjakob installing all firmware files will again bload the image. As said - root cause must be determined why that particular file did not end up in the image. The repo holds the firmware in question (https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/iwlwifi-3945-2.ucode) so I'm currently debugging why it's not shipped.

Adding custom install firmware command may be a good way. I tried to manually compile and upload firmware to vyos before.

I suggested to install the firmware-iwlwifi package from the debian repos as part of the debugging process. Of course this isn't a supported way for end users, this is known for a long time, and you must take care to not run apt-get upgrade, dist-upgrade or install a package that conflicts or overrides a vyos package. It is safe to install packages that don't conflict.

There are two main disadvantages to the third-party files and packages installed outside the packaged files of the installed vyos system. You need to determine by yourself that if:
a) does not match the basic debian system of vyos, ABI conflicts may occur.

Although this is not an orthodox solution, it is the fault of artificially installing drivers when there is a lack of drivers. Vyos is based on debian for secondary development, although unorthodox solutions should be allowed to use debian underlying commands to install appropriate firmware packages. Judging from the error message, it appears that the unpacking failed because there are other packages in conflict.

Any rolling ISO generated after vyos-1.3-rolling-202006140117-amd64.iso will have the fix.

Any rolling ISO generated after vyos-1.3-rolling-202006140117-amd64.iso will have the fix.

It now renders to:

The mentioned configuration results into this snippet on VyOS 1.2.5

It is not recommended to install Debian firmware- packages over vyos-linux-firmware. The question is why the firmware file in question is not pulled in automatically.

T2569 did an entire rewrite of the console command in XML / Pyhton. Bugfix for this problem is also tracked in that task.

Non-free firmware was added by default in crux: T15

There's a regression here, I can not 'delete system console' in the current rolling build, I get this:

@daniil it will be fixed in tomorrows rolling ISO.

Just adding that I too am experiencing this same issue with 1.2.5 while sending firewall logs to a remote syslog server. Running the command

sudo systemctl restart rsyslog

will show firewall logging for a few seconds before it stops completely. Issuing the command again will result in the same thing - logs for a few seconds and then stop. It appears that logging outside of the firewall still functions as expected as regular console log entries are still being sent.

First PR https://github.com/vyos/vyatta-cfg-quagga/pull/50 for delete templates for "protocol rip" from vyatta-cfq-quagga
Second PR https://github.com/vyos/vyos-1x/pull/454 for new XML-python style.

Can you share what you did to make it work again? NAT has recently be rewritten which could be the root cause.

A config Syntax is always migratable. Wide also supports scripts, but ISC PD (as I‘ve seen it, and interpret it) seems to have some rough edges. If you find a guide I will definately have a look.

I have no need for PD for now, so this isn't an important issue for me. I just noticed that WIDE didn't run any scripts, so right now it can't set any nameservers obtained from DHCP. If anyone needs that, I guess it would be simplest to write a script (by using the existing dhclient-script hooks as a guide) just for vyos-hostsd, since PD is already done with WIDE. Switching to ISC would mean we'd need to improve that PD script I linked to, since it only supports a single interface, and we need multiple.

@jjakob it was only choosen as it prooved to be "more simple" compared to ISC and that helper script. I have no affiliation with either implementation. I was not aware that it could cause other issue. If you need to change it to ISC you're free to go.

@jack9603301 you're not the one that made the choice so you can't know why it was made.
ISC-DHCP can do prefix delegation too (not by itself, but with a helper script that others already made: https://wiki.debian.org/IPv6PrefixDelegation ) so that's not why WIDE was chosen.

The purpose of choosing wide-dhcpv6 is to achieve DHCPv6 PD.

What was the reason for choosing WIDE dhcp6c and not keeping isc-dhcp? This has now caused T2590 which will require making a new set of dhclient scripts just for WIDE, so we'll be maintaining 2 separate scripts. If it was due to the support for prefix length hint, isc-dhcp has added that too, as I mentioned in this task before https://phabricator.vyos.net/T421#49842

Successfully tested on 1.3-rolling-202006120643

Successfully tested on rolling 1.3-rolling-202006120643

Unfortunately this results in an error:

As a side-note, the kernel reacts correctly to this by rfc6145.

An IPv6 link has to have an MTU of 1280 bytes or greater. The corresponding limit for IPv4 is 68 bytes.