New Kernel and bug fixes

Is there a reason that pre-up commands will not work in /etc/network/interfaces? They work fine with the debian provided kernel, but not with 2.6.32-13-pve or 2.6.32-14-pve. I thought this was controlled by ifupdown and ifupdown did not get updated when I installed the pve items. First I installed pve-firmware and then pve-headers-2.6.32-14-pve which of course added pve-kernel-2.6.32-14-pve and tested. Then I installed pve-headers-2.6.32-13-pve and tested with 2.6.32-13-pve. Then I switched back to 2.6.32-14-pve and installed proxmox-ve-2.6.32 and tested. So far my settings do not get applied if I have a pre-up command enabled.

I tried adding what I want using a file in sysctl.d and that did not work, but I will look in to that. I need to know if there is an alternate way to implement a pre-up command in the interfaces file that works with the pve kernels.

BTW, you may want to update the wiki for installing Proxmox 2.1 on Squeeze x64 to match the order of package installs that I listed as when I followed the wiki, my bnx2 NICs would not initialize. It seems that the proxmox kernel will not load bnx2 NICs if the initrd is built with the drivers from the firmware-bnx2 package. Installing pve-firmware removes the firmware-bnx2 package and installs drivers that work with bnx2 NICs. So first install pve-firmware and then install pve-headers-<pve kernel version> with will install pve-kernel-<pve kernel version>.
 
Hello,

after booting with the new kernel (pve-kernel-2.6.32-14-pve) the network is unreachable in my server. If I boot again with kernel pve-kernel-2.6.32-13-pve the network works again.

Code: 
pve-manager: 2.1-14 (pve-manager/2.1/f32f3f46)
running kernel: 2.6.32-13-pve
pve-kernel-2.6.32-13-pve: 2.6.32-72
pve-kernel-2.6.32-14-pve: 2.6.32-73
lvm2: 2.02.95-1pve2
clvm: 2.02.95-1pve2
corosync-pve: 1.4.3-1
openais-pve: 1.1.4-2
libqb: 0.10.1-2
redhat-cluster-pve: 3.1.92-3
resource-agents-pve: 3.9.2-3
fence-agents-pve: 3.1.8-1
pve-cluster: 1.0-27
qemu-server: 2.0-49
pve-firmware: 1.0-18
libpve-common-perl: 1.0-30
libpve-access-control: 1.0-24
libpve-storage-perl: 2.0-30
vncterm: 1.0-2
vzctl: 3.0.30-2pve5
vzprocps: 2.0.11-2
vzquota: 3.0.12-3

My server is a Dell PowerEdge 1950 with Broadcom networks cards. I've verified that when booting with kernel 2.6.32-14 network cards are detected Ok and I can't find any errors in syslog related to network, all configured bridges are up with link but I can't access to the network.

What should I look for?

Best Regards,
 
xelkano said:
Hello,

after booting with the new kernel (pve-kernel-2.6.32-14-pve) the network is unreachable in my server. If I boot again with kernel pve-kernel-2.6.32-13-pve the network works again.

Code: 
pve-manager: 2.1-14 (pve-manager/2.1/f32f3f46)
running kernel: 2.6.32-13-pve
pve-kernel-2.6.32-13-pve: 2.6.32-72
pve-kernel-2.6.32-14-pve: 2.6.32-73
lvm2: 2.02.95-1pve2
clvm: 2.02.95-1pve2
corosync-pve: 1.4.3-1
openais-pve: 1.1.4-2
libqb: 0.10.1-2
redhat-cluster-pve: 3.1.92-3
resource-agents-pve: 3.9.2-3
fence-agents-pve: 3.1.8-1
pve-cluster: 1.0-27
qemu-server: 2.0-49
pve-firmware: 1.0-18
libpve-common-perl: 1.0-30
libpve-access-control: 1.0-24
libpve-storage-perl: 2.0-30
vncterm: 1.0-2
vzctl: 3.0.30-2pve5
vzprocps: 2.0.11-2
vzquota: 3.0.12-3

My server is a Dell PowerEdge 1950 with Broadcom networks cards. I've verified that when booting with kernel 2.6.32-14 network cards are detected Ok and I can't find any errors in syslog related to network, all configured bridges are up with link but I can't access to the network.

What should I look for?

Best Regards,
Click to expand...
Hi,
perhaps the devices are renamed by udev? Take a look with
Code: 
ifconfig -a
dmesg | grep eth
Udo
 
udo said:
Hi,
perhaps the devices are renamed by udev? Take a look with
Code: 
ifconfig -a
dmesg | grep eth
Udo
Click to expand...

Thanks for your reply, but this is not the case, the interfaces are not renamed. Under both kernels I have eth0,eth1 and bond0 inteface over them. Same behaviour in all of my nodes, with kernel pve-kernel-2.6.32-14-pve I have no network access.

Best Regards,
 
Rhongomiant said:
Is there a reason that pre-up commands will not work in /etc/network/interfaces? They work fine with the debian provided kernel, but not with 2.6.32-13-pve or 2.6.32-14-pve.
Click to expand...

Why should that depend on kernel version?
 
dietmar said:
Why should that depend on kernel version?
Click to expand...


I have no idea, I thought this is controlled by ifupdown, so I am asking you as maybe it's something in the difference between the redhat and debian kernels and/or changes that you guys make when you add openvz and/or other things. I can tell you is that if a pre-up option enabled in an iface section in /etc/network/interfaces, that iface section is ignored. If the pre-up option is disabled, then the iface loads as expected. This does not happen when booted using the Debian provided vmlinuz-2.6.32-5-amd64 and initrd.img-2.6.32-5-amd64. I am not seeing any messages in kernel.log, dmesg, messages.log, syslog, etc. Maybe it's the specific command I am using or maybe it's pre-up in general. It's hard to tell at this point. I am working to gather more information.

Also, I mentioned kernel, but it could be something added by the pve-firmware as I had to install that first to get my NICs to work with the pve kernel.

Code: 
# pveversion -v
pve-manager: 2.1-14 (pve-manager/2.1/f32f3f46)
running kernel: 2.6.32-14-pve
proxmox-ve-2.6.32: 2.1-73
pve-kernel-2.6.32-13-pve: 2.6.32-72
pve-kernel-2.6.32-14-pve: 2.6.32-73
lvm2: 2.02.95-1pve2
clvm: 2.02.95-1pve2
corosync-pve: 1.4.3-1
openais-pve: 1.1.4-2
libqb: 0.10.1-2
redhat-cluster-pve: 3.1.92-3
resource-agents-pve: 3.9.2-3
fence-agents-pve: 3.1.8-1
pve-cluster: 1.0-27
qemu-server: 2.0-48
pve-firmware: 1.0-18
libpve-common-perl: 1.0-30
libpve-access-control: 1.0-24
libpve-storage-perl: 2.0-30
vncterm: 1.0-2
vzctl: 3.0.30-2pve5
vzprocps: 2.0.11-2
vzquota: 3.0.12-3
pve-qemu-kvm: 1.1-7
ksm-control-daemon: 1.1-1
 
Last edited:
xelkano said:
after booting with the new kernel (pve-kernel-2.6.32-14-pve) the network is unreachable in my server. If I boot again with kernel pve-kernel-2.6.32-13-pve the network works again.
Click to expand...

Please can you verify that the firmware is correctly loaded at boot time? (if not, try to update-initramfs)
 
xelkano said:
Thanks for your reply, but this is not the case, the interfaces are not renamed. Under both kernels I have eth0,eth1 and bond0 inteface over them. Same behaviour in all of my nodes, with kernel pve-kernel-2.6.32-14-pve I have no network access.

Best Regards,
Click to expand...

I have same issue with my bond in active-backup using a realtek and and Intel card.
Realtek has issues, Intel worked ok.
Searching for a solution I've seen people having issues with broadcom and bonding in other distros with updated bonding code.
I have no solution other than to stop using the bond.
I think something changed in the bonding code that is causing the issue.
Here is the thread I started about this issue: http://forum.proxmox.com/threads/10635-2-6-32-14-causing-bonding-and-or-vlan-issues
 
dietmar said:
Please can you verify that the firmware is correctly loaded at boot time? (if not, try to update-initramfs)
Click to expand...

Tried updating the existing initrd and creating a new initrd and both had the same result, same issue. As far as it could be the command, it's just a echo statement that updates a file in /proc/sys/net/ipv6/conf/vmbr0, see below, and again it works when I boot using the Debian provided kernel. Yes, I have run it without the quotes as well.

pre-up "echo 2 > /proc/sys/net/ipv6/conf/vmbr0/use_tempaddr"

Do any proxmox settings prevent changing files in /proc/sys/net/ipv6/conf/vmbr0/ or does it update these values regularly to so that user changes would not bee seen?
 
dietmar said:
That is totally dependent on kernel. I assume the command runs, but has different effects on different kernels.
Click to expand...

dietmar,

1) thanks for updating the wiki, but I suggest noting that the pve-headers are needed if you have custom kernel modules.

2) I resolved the issue with pre-up/sysctl settings I am setting. The problem was not the command, but target. It seems that this is a timing issue with the ipv6 stack. Before installing the Proxmox pve-firmware, pve-kernel and pve-headers, this was not an issue, but something changed after I installed them. It could be the kernel itself, a change made in a file due to installing the pve packages, maybe the pve packages cause the network interfaces to load sooner, etc. The fix was to add ipv6 to /etc/modules. Then both the sysctl and pre-up options worked as expected.

vi /etc/modules

Code: 
# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.
# Parameters can be specified after the module name.

loop
ipv6

The reason that the pre-up would cause the iface ipv6 section to be ignored is because pre-up does not bring up the interface when the pre-up command fails. The failure was not being saved in any log that I could find, but I could see it at the console. Finding the error lead to the solution. Below are details of the errors at the console.

The error when using the sysctl method:
error: "net.ipv6.conf.vmbr0.use_tempaddr" is an unknown key

The error when using the pre-up method:
cannot create use_tempaddr: directory nonexistent


When I get more time I will try booting using the debian provided kernel with ipv6 disabled in /etc/modules to see if it works and I will install Debian in a VM to see if I can find any setting differences. You you do not find better solution to resolve this kind of issue, you may want to consider adding ipv6 to /etc/modules when Proxmox fully supports IPv6. e.g. Currently if you add net.ipv6.* items to /etc/sysctl.d/pve.conf and/or /etc/sysctl.d/vzctl.conf, they will be ignored unless you have ipv6 in /etc/module at boot or of course you resolve this issue using a different method.

While I know the specific command I was trying to get working is trivial especially for a server, but I hope it helps someone else trying to do the same or something that would have the same issue.

Finally, while looking through console messages I noticed the following error and below that are some links related to this issue. This does seem to be a kernel issue.

ata.01 failed to resume link (SControl 0)

https://bugzilla.redhat.com/show_bug.cgi?id=653811
http://permalink.gmane.org/gmane.linux.ide/49813
http://lkml.indiana.edu/hypermail/linux/kernel/1201.2/00543.html
http://www.linuxquestions.org/quest...t-slackware-how-can-i-do-it-847506/page2.html
 
dietmar said:
Please can you verify that the firmware is correctly loaded at boot time? (if not, try to update-initramfs)
Click to expand...

I've tryed updating initrd image but the issue is not solved, the network card firmware is loaded correctly.
I've verified that when passing all traffic through eth0 instead of using bond0 device all works ok, so the issue is related to bond interface.

At boot time the bond0 device seems to bring up Ok, but later it does not work:

Code: 
Aug 20 09:52:37 proxnode03 kernel: bnx2 0000:03:00.0: eth0: NIC Copper Link is Up, 100 Mbps full duplex
Aug 20 09:52:37 proxnode03 kernel: bond0: link status definitely up for interface eth0, 100 Mbps full duplex.
Aug 20 09:52:37 proxnode03 kernel: bonding: bond0: making interface eth0 the new active one.
Aug 20 09:52:37 proxnode03 kernel: device eth0 entered promiscuous mode
Aug 20 09:52:37 proxnode03 kernel: bonding: bond0: first active interface up!

I am using Broadcom network cards:

Code: 
03:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 12)
07:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 12)

My network configuration:

Code: 
# The primary network interface
iface eth0 inet manual
iface eth1 inet manual

auto bond0
iface bond0 inet manual
       slaves eth0 eth1
       bond_miimon 100
       bond_mode active-backup

auto vlan50
iface vlan50 inet manual
        vlan_raw_device bond0

auto vlan60
iface vlan60 inet manual
        vlan_raw_device bond0

auto vmbr0
iface vmbr0 inet static
        address  172.17.16.44
        netmask  255.255.254.0
        gateway  172.17.16.1
        bridge_ports vlan50
        bridge_stp off
        bridge_fd 0

auto vmbr60
iface vmbr60 inet static
        address  0.0.0.0
        netmask  255.255.255.255
        bridge_ports vlan60
        bridge_stp off
        bridge_fd 0
 
I also updated to the new kernel pve-kernel-2.6.32-14-pve_2.6.32-73_amd64 and am facing problems, too.
The boot message is:

Loading Linux 2.6.32-14-pve ...
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
Pid: 1, comm: swapper veid: 0 Not tainted 2.6.32-14-pve #1
...

Hardware is a board with Intel Q67 chipset.
I will be trying to switch back to the previous kernel. Any other suggestion? Can I provide any other information?

EDIT:
The problem was not related to the new kernel. It seems the "aptitude upgrade" failed or was incomplete due to limited space on the boot partition. (Iirc, I shrunk down the boot partition size after the initial Proxmox VE system installation.)
I cannot recall any related error message in aptitude's output. I think any failure during the update should prevent the update from being successful. So maybe the failure was not detected, or it failed to propagate properly. Anyway, this has probably nothing todo with proxmox.
 
Last edited by a moderator:
dear all

I am using proxmox 2.1 version provided by OVH (on debian squeeze 64) and it works perfectly.

but when I do update & full-upgrade , without any other change, the machine becomes unreachable

after re starting the machine by ovh maintenance I got the following from pveversion -v. (see below)

It seems that the grub file is not updated with pve kernel by the process. proxmow web iterface is reachable but nothing works

thanks for your help and suggestions





pve-manager: 2.1-14 (pve-manager/2.1/f32f3f46)
running kernel: 3.2.13-xxxx-std-ipv6-64
proxmox-ve-2.6.32: 2.1-73
pve-kernel-2.6.32-14-pve: 2.6.32-73
lvm2: 2.02.95-1pve2
clvm: 2.02.95-1pve2
corosync-pve: 1.4.3-1
openais-pve: 1.1.4-2
libqb: 0.10.1-2
redhat-cluster-pve: 3.1.92-3
resource-agents-pve: 3.9.2-3
fence-agents-pve: 3.1.8-1
pve-cluster: 1.0-27
qemu-server: 2.0-49
pve-firmware: 1.0-18
libpve-common-perl: 1.0-30
libpve-access-control: 1.0-24
libpve-storage-perl: 2.0-30
vncterm: 1.0-2
vzctl: 3.0.30-2pve5
vzprocps: 2.0.11-2
vzquota: 3.0.12-3
pve-qemu-kvm: 1.1-8
ksm-control-daemon: 1.1-1
 
yesterday i updated to the new pve-kernel-2.6.32-14-pve. since the update, in all my CTs (about 40 CTs (on two hosts) with ubuntu precise 64bit on nfs storage) the nscd daemon goes up to 100% (partly even more) cpu load. the host went up to a permanent load avg of above 70. booting the old pve-kernel-2.6.32-12-pve, everything goes fine.
 
Hm. I updated, have the versions listed. I did a full reboot. The web frontend now shows me "Version undefined" whereas before, it showed "Version 2.1-1/f9b0f63a". Might be just cosmetic.
 
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom
Back