I have installed the latest rolling release and the r8152 driver does seem ok (interface now comes up) however, eth0 now disappears. It is being renamed to eth5 (the r8152). This is eerily similar to T1066 I was involved in back in 2019. Turned out to be a kernel bug. Was not working with kernel 4.19.52 and was fixed in kernel 4.19.54
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
Oct 14 2024
Oct 13 2024
Oct 12 2024
Yes, that‘s correct behavior.
Hi c-po
@SteveP you need to install the MOK, see https://docs.vyos.io/en/latest/installation/secure-boot.html
Hi c-po
The above gives that it will be somewhat tricky to add your own module afterwards unless you do a full recompile since the key used to sign the kernel lives in the /tmp and is lost once the ISO have been created.
Oct 11 2024
Im guessing this one is behind that all modules must now be signed in VyOS:
Oct 10 2024
I'm afraid it didn't work.
It should already be in the latest rolling release.
@SteveP could you re-check?
Oct 9 2024
Looking at the igb module from latest vyos, it is getting signed. Why is this one not signed?
It needs to sign the modules somehow
example
https://github.com/vyos/vyos-build/blob/910eece6d3dede212a0f6172272d248601ab1090/scripts/package-build/linux-kernel/build-intel-ixgbe.sh#L83
6.6.51
sudo find / -name config-uname -r
/usr/lib/live/mount/rootfs/1.5-rolling-202409250007.squashfs/boot/config-6.6.51-vyos
sudo grep MODULE_SIG /usr/lib/live/mount/rootfs/1.5-rolling-202409250007.squashfs/boot/config-6.6.51-vyos
CONFIG_MODULE_SIG is not set
Oct 8 2024
I have been getting headers from http://dev.packages.vyos.net/repositories/current current main" 6.6.52 is the latest there.
Hi, I have upgraded to latest rolling. That is how I know you are now on 6.6.54. I get the error modprobe: ERROR: could not insert 'r8152': Key was rejected by service.
In T6713#201597, @SteveP wrote:Hi,
It is not working I'm afraid.
modprobe: ERROR: could not insert 'r8152': Key was rejected by service
It is a signing error. I am getting the same thing now with 6.6.52 (I just tried it) but 6.6.51 (one I am running) is fine. I can't try 6.6.54 as the headers are not there.
SteveP
I don't think it is related to secure boot.
Could it be related to this: https://portal.productboard.com/vyos/1-vyos-roadmap/c/67-secure-boot-uefi
It is not working I'm afraid.
Driver added to the latest rolling release
vyos@r14# run show version all | match realtek ii vyos-drivers-realtek-r8152 2.18.1-1 amd64 auto-generated package by debmake [edit] vyos@r14#
Oct 7 2024
Oct 6 2024
Oct 4 2024
Technically according to IEEE autoneg is mandatory when doing 1Gbps and above using RJ45.
Oct 3 2024
Hi, Yes I get the same if I try that but mine is already 2500 full.
Oct 2 2024
The fix is still work in progress, I need to dig deeper into accel-ppp history that predates the github repo. Not sure why some code was commented out over 10 years ago, IPV6CP restart timer is not stopped and disconnects in 3 seconds. Looking at older history in sourceforge but not sure if the answer is even there, sourceforge seems to have lost old history before 2011 (broken links).
Sep 30 2024
reproduced on:
Version: VyOS 1.5-rolling-202409160007
Version: VyOS 1.4-stable-202409170309
Sep 29 2024
I can not immediately recreate the issue:
Sep 28 2024
SteveP - Even when using 2.18.1 - when I try to force the speed of the USB interface to 2500 (and duplex to full, as then required), I see error messages on the commit. See below. This happens with multiple 2.5G capable interfaces.
Sep 27 2024
i retested this issue
actual for:
Version: VyOS 1.3-stable-202409270542 (DHCP Relay Agent 4.4.1)
Sep 26 2024
This PR https://github.com/vyos/vyos-1x/pull/3311 has fixed the issue.
Tested in 1.4.0 and latest rolling release. 1.5-rolling-202409250007
Sep 25 2024
Sep 24 2024
Yes I am overloaded (who isn't), and yes I plan to make a PR but want to test it a bit more first, to be reasonably sure it causes no regression (potential resource leak if something allocated by the incomplete IPv6 configuration is not freed - not sure enough about accel-ppp internals). I'm working to rebuild replacement accel-ppp package (based on the same commit as in equuleus with just my patch applied, no other changes) and run it for a week or two while watching memory usage. Testing a fairly complex config in production environment, so not brave enough to try rolling or even sagitta just yet.
@jmaslak It's been a while since you reported this bug and we've been through multiple FRR updates since then. Could you check if the issue is fixed in the latest nightly build, or attach a config that triggers that behavior if it still exists?
I've merged this into the feature request because the real issue is that we don't have dynamic hairpin NAT yet, while this behavior for "static" NAT is not wrong. We'll get to it.
@marekm Do you plan to make a PR?
If you are overloaded, we can import a patch ourselves, but a PR would be nice.
Sep 20 2024
I am currently using 2.18.1 with kernel 6.6.51-vyos
I am currently using 2.18.1 with kernel