Bug in DRBD causes split-brain, already patched by DRBD devs

e100 said:
NOTE: at the time of this post drbd-8.3.13rc1 is the latest tag in 8.3 and is the lowest version that contains the split brain causing bug.
Click to expand...

Hello e100 again - you are the Master of Masters!!!

Humbly, please let me to do a questions:
1- Today 2012-Nov-18 the PVE Kernel support DRBD ver. 8.3.13 stable. Does this version the split brain bug?
2- With this version of DRBD and LVM on top of DRBD, can i migrate the VMs without problems of DRBD?
3- Is correct this form of install DRBD:

Edited to ask better:
On my lab:
- With PVE the latest version updated, I execute:

mkdir /root/drbd
cd /root/drbd
apt-get install git-core git-buildpackage fakeroot debconf-utils docbook-xml docbook-xsl \
dpatch xsltproc autoconf flex pve-headers-2.6.32-16-pve module-assistant
git clone http://git.drbd.org/drbd-8.3.git
cd drbd-8.3
git checkout drbd-8.3.13
dpkg-buildpackage -rfakeroot -b -uc -d
(now I have the new DRBD version 8.3.13 on my PenDrive)

On two Nodes into production enviroment with old DRBD version (8.3.10):
- After of copy the file created on my lab "drbd8-utils_8.3.13-0_amd64.deb"
into the Nodes of production enviroment, I execute:

dpkg -iGE drbd8-utils_8.3.13-0_amd64.deb

Is correct the procedure? or am I missing something?. For example I did not install the file "drbd8-module-source_8.3.13-0_all.deb" and this is necessary too?

4: For what's "drbd8-module-source_8.3.13-0_all.deb"? and in my case for the Nodes into production enviroment, do I need to install it?

Attentively
Cesar
 
Last edited:
With kernel 2.6.32-16-pve or higher it should not be necessary to install drbd8-module-source_8.3.13-0_all.deb

drbd8-module-source_8.3.13-0_all.deb is to build the updated kernel module but since the kernel already has version 8.3.13 everything should be ok.

I have got into the habit of compiling and installing the source kernel module each time I update the kernel.
So many of my DRBD servers are using the source compiled module rather than the new updated version included in the kernel by default.
Because of this I can not yet confirm that the new default kernel module is bug free, but there is no reason to believe that it would have a problem.
 
Hello everyone

This post is Urgent, my servers are in production

I am in a serious problem and need help

My scenario:
- I have two workstations ASUS P8H77-M PRO with Intel core I7, Proxmox VE 2.3, DRBD 8.3.13, LVM on top of DRBD
- 2 NICs Realtek RTL8111/8168 PCI-E of 1 Gb/s in bond round robin only for use with DRBD

And after awhile it shows me this:

shell#cat /proc/drbd
version: 8.3.13 (api:88/proto:86-96)
GIT-hash: 83ca112086600faacab2f157bc5a9324f7bd7f77 build by root@sighted, 2012-10-09 12:47:51
0: cs:StandAlone ro:Primary/Unknown ds:UpToDate/DUnknown r-----
ns:237256 nr:307093 dw:307093 dr:690264 al:0 bm:321 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0
1: cs:Connected ro:Primary/Primary ds:UpToDate/UpToDate C r-----
ns:0 nr:467984 dw:467984 dr:537932 al:0 bm:13 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0

This is my configuration:

File global_common.conf:
global { usage-count no;
}

common {
protocol C;

handlers {
pri-on-incon-degr "/usr/lib/drbd/notify-pri-on-incon-degr.sh; /usr/lib/drbd/notify-emergency-reboot.sh; echo b > /proc/sysrq-trigger ; reboot -f";
pri-lost-after-sb "/usr/lib/drbd/notify-pri-lost-after-sb.sh; /usr/lib/drbd/notify-emergency-reboot.sh; echo b > /proc/sysrq-trigger ; reboot -f";
local-io-error "/usr/lib/drbd/notify-io-error.sh; /usr/lib/drbd/notify-emergency-shutdown.sh; echo o > /proc/sysrq-trigger ; halt -f";
split-brain "/usr/lib/drbd/notify-split-brain.sh root";
out-of-sync "/usr/lib/drbd/notify-out-of-sync.sh root";
}

startup {
}

disk { on-io-error detach;
}

net { sndbuf-size 0; no-tcp-cork; unplug-watermark 16; max-buffers 8000; max-epoch-size 8000;
data-integrity-alg sha1;
}

syncer { rate 75M; al-extents 3389; cpu-mask 0; verify-alg "sha1";
}
}

File r0.res:
resource r0 {
protocol C;
startup {
wfc-timeout 15;
degr-wfc-timeout 60;
become-primary-on both;
}
net {
allow-two-primaries;
after-sb-0pri discard-zero-changes;
after-sb-1pri discard-secondary;
after-sb-2pri disconnect;
}
on kvm5 {
device /dev/drbd0;
disk /dev/sda3;
address 10.2.2.50:7788;
meta-disk internal;
}
on kvm6 {
device /dev/drbd0;
disk /dev/sda3;
address 10.2.2.51:7788;
meta-disk internal;
}
}

File r1.res:
resource r1 {
protocol C;
startup {
wfc-timeout 15;
degr-wfc-timeout 60;
become-primary-on both;
}
net {
allow-two-primaries;
after-sb-0pri discard-zero-changes;
after-sb-1pri discard-secondary;
after-sb-2pri disconnect;
}
on kvm5 {
device /dev/drbd1;
disk /dev/sdb3;
address 10.2.2.50:7789;
meta-disk internal;
}
on kvm6 {
device /dev/drbd1;
disk /dev/sdb3;
address 10.2.2.51:7789;
meta-disk internal;
}
}

Note:
I use on the directive net "data-integrity-alg sha1"; because for me is very important the data

These are my Logs:

Log in Node A:
Jun 14 08:07:28 kvm5 kernel: dlm: connecting to 4
Jun 14 08:50:12 kvm5 kernel: block drbd0: Digest mismatch, buffer modified by upper layers during write: 21158352s +4096
Jun 14 08:50:12 kvm5 kernel: block drbd0: sock was reset by peer
Jun 14 08:50:12 kvm5 kernel: block drbd0: peer( Primary -> Unknown ) conn( Connected -> BrokenPipe ) pdsk( UpToDate -> DUnknown )
Jun 14 08:50:12 kvm5 kernel: block drbd0: short read expecting header on sock: r=-104
Jun 14 08:50:12 kvm5 kernel: block drbd0: meta connection shut down by peer.
Jun 14 08:50:12 kvm5 kernel: block drbd0: new current UUID 76A887AA443E0DBB:15B9E4140BB5F41B:48B8F43E491AA38D:48B7F43E491AA38D
Jun 14 08:50:12 kvm5 kernel: block drbd0: asender terminated
Jun 14 08:50:12 kvm5 kernel: block drbd0: Terminating asender thread
Jun 14 08:50:12 kvm5 kernel: block drbd0: Connection closed
Jun 14 08:50:12 kvm5 kernel: block drbd0: conn( BrokenPipe -> Unconnected )
Jun 14 08:50:12 kvm5 kernel: block drbd0: receiver terminated
Jun 14 08:50:12 kvm5 kernel: block drbd0: Restarting receiver thread
Jun 14 08:50:12 kvm5 kernel: block drbd0: receiver (re)started
Jun 14 08:50:12 kvm5 kernel: block drbd0: conn( Unconnected -> WFConnection )
Jun 14 08:50:13 kvm5 kernel: block drbd0: Handshake successful: Agreed network protocol version 96
Jun 14 08:50:13 kvm5 kernel: block drbd0: conn( WFConnection -> WFReportParams )
Jun 14 08:50:13 kvm5 kernel: block drbd0: Starting asender thread (from drbd0_receiver [1847])
Jun 14 08:50:13 kvm5 kernel: block drbd0: data-integrity-alg: sha1
Jun 14 08:50:13 kvm5 kernel: block drbd0: drbd_sync_handshake:
Jun 14 08:50:13 kvm5 kernel: block drbd0: self 76A887AA443E0DBB:15B9E4140BB5F41B:48B8F43E491AA38D:48B7F43E491AA38D bits:99 flags:0
Jun 14 08:50:13 kvm5 kernel: block drbd0: peer CF68F4906E4001C5:15B9E4140BB5F41B:48B8F43E491AA38D:48B7F43E491AA38D bits:0 flags:0
Jun 14 08:50:13 kvm5 kernel: block drbd0: uuid_compare()=100 by rule 90
Jun 14 08:50:13 kvm5 kernel: block drbd0: helper command: /sbin/drbdadm initial-split-brain minor-0
Jun 14 08:50:13 kvm5 kernel: block drbd0: helper command: /sbin/drbdadm initial-split-brain minor-0 exit code 0 (0x0)
Jun 14 08:50:13 kvm5 kernel: block drbd0: Split-Brain detected but unresolved, dropping connection!
Jun 14 08:50:13 kvm5 kernel: block drbd0: helper command: /sbin/drbdadm split-brain minor-0
Jun 14 08:50:13 kvm5 kernel: block drbd0: helper command: /sbin/drbdadm split-brain minor-0 exit code 0 (0x0)
Jun 14 08:50:13 kvm5 kernel: block drbd0: conn( WFReportParams -> Disconnecting )
Jun 14 08:50:13 kvm5 kernel: block drbd0: error receiving ReportState, l: 4!
Jun 14 08:50:13 kvm5 kernel: block drbd0: asender terminated
Jun 14 08:50:13 kvm5 kernel: block drbd0: Terminating asender thread
Jun 14 08:50:13 kvm5 kernel: block drbd0: Connection closed
Jun 14 08:50:13 kvm5 kernel: block drbd0: conn( Disconnecting -> StandAlone )
Jun 14 08:50:13 kvm5 kernel: block drbd0: receiver terminated
Jun 14 08:50:13 kvm5 kernel: block drbd0: Terminating receiver thread

Log in node B:
Jun 14 08:07:28 kvm6 kernel: dlm: Using TCP for communications
Jun 14 08:07:28 kvm6 kernel: dlm: got connection from 3
Jun 14 08:50:12 kvm6 kernel: block drbd0: Digest integrity check FAILED: 21158352s +4096
Jun 14 08:50:12 kvm6 kernel: block drbd0: error receiving Data, l: 4140!
Jun 14 08:50:12 kvm6 kernel: block drbd0: peer( Primary -> Unknown ) conn( Connected -> ProtocolError ) pdsk( UpToDate -> DUnknown )
Jun 14 08:50:12 kvm6 kernel: block drbd0: new current UUID CF68F4906E4001C5:15B9E4140BB5F41B:48B8F43E491AA38D:48B7F43E491AA38D
Jun 14 08:50:12 kvm6 kernel: block drbd0: asender terminated
Jun 14 08:50:12 kvm6 kernel: block drbd0: Terminating asender thread
Jun 14 08:50:12 kvm6 kernel: block drbd0: Connection closed
Jun 14 08:50:12 kvm6 kernel: block drbd0: conn( ProtocolError -> Unconnected )
Jun 14 08:50:12 kvm6 kernel: block drbd0: receiver terminated
Jun 14 08:50:12 kvm6 kernel: block drbd0: Restarting receiver thread
Jun 14 08:50:12 kvm6 kernel: block drbd0: receiver (re)started
Jun 14 08:50:12 kvm6 kernel: block drbd0: conn( Unconnected -> WFConnection )
Jun 14 08:50:13 kvm6 kernel: block drbd0: Handshake successful: Agreed network protocol version 96
Jun 14 08:50:13 kvm6 kernel: block drbd0: conn( WFConnection -> WFReportParams )
Jun 14 08:50:13 kvm6 kernel: block drbd0: Starting asender thread (from drbd0_receiver [1857])
Jun 14 08:50:13 kvm6 kernel: block drbd0: data-integrity-alg: sha1
Jun 14 08:50:13 kvm6 kernel: block drbd0: drbd_sync_handshake:
Jun 14 08:50:13 kvm6 kernel: block drbd0: self CF68F4906E4001C5:15B9E4140BB5F41B:48B8F43E491AA38D:48B7F43E491AA38D bits:0 flags:0
Jun 14 08:50:13 kvm6 kernel: block drbd0: peer 76A887AA443E0DBB:15B9E4140BB5F41B:48B8F43E491AA38D:48B7F43E491AA38D bits:99 flags:0
Jun 14 08:50:13 kvm6 kernel: block drbd0: uuid_compare()=100 by rule 90
Jun 14 08:50:13 kvm6 kernel: block drbd0: helper command: /sbin/drbdadm initial-split-brain minor-0
Jun 14 08:50:13 kvm6 kernel: block drbd0: helper command: /sbin/drbdadm initial-split-brain minor-0 exit code 0 (0x0)
Jun 14 08:50:13 kvm6 kernel: block drbd0: Split-Brain detected but unresolved, dropping connection!
Jun 14 08:50:13 kvm6 kernel: block drbd0: helper command: /sbin/drbdadm split-brain minor-0
Jun 14 08:50:13 kvm6 kernel: block drbd0: meta connection shut down by peer.
Jun 14 08:50:13 kvm6 kernel: block drbd0: conn( WFReportParams -> NetworkFailure )
Jun 14 08:50:13 kvm6 kernel: block drbd0: asender terminated
Jun 14 08:50:13 kvm6 kernel: block drbd0: Terminating asender thread
Jun 14 08:50:13 kvm6 kernel: block drbd0: helper command: /sbin/drbdadm split-brain minor-0 exit code 0 (0x0)
Jun 14 08:50:13 kvm6 kernel: block drbd0: conn( NetworkFailure -> Disconnecting )
Jun 14 08:50:13 kvm6 kernel: block drbd0: error receiving ReportState, l: 4!
Jun 14 08:50:13 kvm6 kernel: block drbd0: Connection closed
Jun 14 08:50:13 kvm6 kernel: block drbd0: conn( Disconnecting -> StandAlone )
Jun 14 08:50:13 kvm6 kernel: block drbd0: receiver terminated
Jun 14 08:50:13 kvm6 kernel: block drbd0: Terminating receiver thread

I will be extremely grateful to anyone who can help me

Best regards
Cesar
 
cesarpk said:
Thanks mir for your answer, I know the procedure for resynchronize, but i like to know how to fix it since that this problem is constant, every 1 hour approximately.
Click to expand...
If that is the case then you have a serious network and/or configuration problem. Resolving such issues requires deep insight into your specific setup and environment and since it does not seem that you can come closer to a solution I think you need to turn to outside help from a person which can look at the problem onsite.
 
mir said:
If that is the case then you have a serious network and/or configuration problem. Resolving such issues requires deep insight into your specific setup and environment and since it does not seem that you can come closer to a solution I think you need to turn to outside help from a person which can look at the problem onsite.
Click to expand...

Thanks mir for your answer, but i don't know anybody that can help me.
I believe that I am into of a serious problem... :-(

Best regards
Cesar
 
Maybe you should avoid using DRBD entirely an stick to the recommended usecases for proxmox. If you go your own way chances for failures and lack of proper support is a considerable risk unless you really know what you are doing.
 
mir said:
Maybe you should avoid using DRBD entirely an stick to the recommended usecases for proxmox. If you go your own way chances for failures and lack of proper support is a considerable risk unless you really know what you are doing.
Click to expand...

I have solved many strange problems with a little help, including Kernels, I just wish some tracks of that is/are causing the problem(s) and i will find the solution. And daily backups of VMs is a possible alternative until I find the solution.

Please if anyone can help me, let me know

Best regards
Cesar
 
I'm in middle of my own drbd cleanup............. So have not read entire thread.

Do you use primary/primary drbd?

Do kvm's on a resource only run on one node? Or are the mixed?
 
Are you using a dedicated network port for DRBD?
If not, then network congestion is a likely source of the issue here.

Also, the error seems to indicate some sort of data corruption, maybe you have a bad nic/switch or ram.
Code: 
[COLOR=#333333]Jun 14 08:50:12 kvm6 kernel: block drbd0:[B] Digest integrity check FAILED:[/B] 21158352s +4096[/COLOR]
[COLOR=#333333]Jun 14 08:50:12 kvm6 kernel: block drbd0: error receiving Data, l: 4140!
[/COLOR]


Code:
Code: 
[COLOR=#333333]Jun 14 08:50:12 kvm5 kernel: block drbd0: Digest mismatch, [B]buffer modified by upper layers during write[/B]: 21158352s +4096[/COLOR]


A simple google search took me to this page:

http://www.drbd.org/users-guide/re-drbdconf.html

Go to the section titled "Notes on data integrity"
I think your answer is to this problem is there.
 
Last edited:
e100 said:
Are you using a dedicated network port for DRBD?
If not, then network congestion is a likely source of the issue here.

Also, the error seems to indicate some sort of data corruption, maybe you have a bad nic/switch or ram.
Code: 
[COLOR=#333333]Jun 14 08:50:12 kvm6 kernel: block drbd0:[B] Digest integrity check FAILED:[/B] 21158352s +4096[/COLOR]
[COLOR=#333333]Jun 14 08:50:12 kvm6 kernel: block drbd0: error receiving Data, l: 4140!
[/COLOR]


Code:
Code: 
[COLOR=#333333]Jun 14 08:50:12 kvm5 kernel: block drbd0: Digest mismatch, [B]buffer modified by upper layers during write[/B]: 21158352s +4096[/COLOR]


A simple google search took me to this page:

http://www.drbd.org/users-guide/re-drbdconf.html

Go to the section titled "Notes on data integrity"
I think your answer is to this problem is there.
Click to expand...

Hi e100 (the Master!!!), am pleased to greet you again.

I use two NICs dedicated for DRBD in bond RR in mode crossover-cable, and about the RAM i think that should be fine because the PCs are new

I have read the "Notes on data integrity", but if I have only one VM that run services that consuming few hardware resources, I don't worry for the CPU costs (Intel core I7 Processor, and PVE GUI shows that the Node consumes few resources), so i like to use data-integrity-alg. Today I changed of sha1 to md5 becasue I have read on a web page of linbit-DRBD that md5 is better for this case.

Also I have read that without data integrity is common when you do a manual check (by CLI), the checking finds differences in some disk blocks, which is why I do not want to remove this option.

Then I want to ask for help to complete the tuning and if not find the solution, I will have to remove that option.

Please, any ideas or clues?

Best regards
Cesar
 
Last edited:
cesarpk said:
Hi e100 (the Master!!!), am pleased to greet you again.

I use two NICs dedicated for DRBD in bond RR in mode crossover-cable, and about the RAM i think that should be fine because the PCs are new

I have read the "Notes on data integrity", but if I have only one VM that run services that consuming few hardware resources, I don't worry for the CPU costs (Intel core I7 Processor, and PVE GUI shows that the Node consumes few resources), so i like to use data-integrity-alg. Today I changed of sha1 to md5 becasue I have read on a web page of linbit-DRBD that md5 is better for this case.

Also I have read that without data integrity is common when you do a manual check (by CLI), the checking finds differences in some disk blocks, which is why I do not want to remove this option.

Then I want to ask for help to complete the tuning and if not find the solution, I will have to remove that option.

Please, any ideas or clues?

Best regards
Cesar
Click to expand...



If still not solved, Try not using bond.
 
This could might well be the problem. The bond is using round robin. What will that mean to the TCP checksum algorithm if a stream of data is suddenly coming from the other nic in the middle of transfer? My best guess is that the only bond protocol which can be used is LACP (802.3AD) since this is the only protocol which is transparent to the receiving side. LACP ensures that the virtual interface will always present the same MAC and because the MAC is part of the TCP header a changed MAC will inevitably resolve in a change in TCP checksum.
 
mir said:
This could might well be the problem. The bond is using round robin. What will that mean to the TCP checksum algorithm if a stream of data is suddenly coming from the other nic in the middle of transfer? My best guess is that the only bond protocol which can be used is LACP (802.3AD) since this is the only protocol which is transparent to the receiving side. LACP ensures that the virtual interface will always present the same MAC and because the MAC is part of the TCP header a changed MAC will inevitably resolve in a change in TCP checksum.
Click to expand...

Hi mir and RobFantini

I have changed the checksum to md5, and after of see the error also changed the bond RR to active-backup, but the problem persist.
I think that i will be installing DRBD 8.4.3 from the source.

My questions:
1- Any ideas about of install DRBD 8.4.3, or other ideas?
2- Or anyone that uses DRBD 8.3.13 without the directive net data-integrity-alg and after a long time when execute by CLI "drbdadm verify <Resource-Name>" not shows errors of DRBD ???
 
Search the forum on installing 8.4, I know someone shared that info.

I run without data-integrity-alg and periodically run a verify, DRBD is not the problem.

You have a hardware problem( ram, motherboard, network card ), buggy checksum offloading or buggy network card driver.

If this was my machine I would diagnose it like this:
Memtest is good way to check ram, if you have ECC ram( you should for production ) just search logs for EDAC errors.
Disable checksum offloading
Try a different network card, a different brand or model would be best.
If none of those things solve the issue try a different motherboard/cpu/ram combination.
 
e100 said:
Search the forum on installing 8.4, I know someone shared that info.

I run without data-integrity-alg and periodically run a verify, DRBD is not the problem.

You have a hardware problem( ram, motherboard, network card ), buggy checksum offloading or buggy network card driver.

If this was my machine I would diagnose it like this:
Memtest is good way to check ram, if you have ECC ram( you should for production ) just search logs for EDAC errors.
Disable checksum offloading
Try a different network card, a different brand or model would be best.
If none of those things solve the issue try a different motherboard/cpu/ram combination.
Click to expand...

Thanks e100 , i will follow your advices

But please let me to do a questions:
1- For install DRBD 8.4.3 i have problems, please fix the procedure:
mkdir ~/drbd && cd ~/drbd
apt-get install git-core git-buildpackage fakeroot debconf-utils docbook-xml docbook-xsl dpatch xsltproc autoconf flex module-assistant git build-essential autoconf debhelper dpatch debhelper pve-headers-2.6.32-19-pve
git clone http://git.drbd.org/drbd-8.4.git #<----------- 8.4???, I prefer 8.4.3 and i can't continue, Re-Edit: I want really the latest stable version.

cd drbd-8.4
git checkout drbd-8.4.1
dpkg-buildpackage -rfakeroot -b -uc
cd ..
dpkg -i drbd8-module-source_8.4.1-0_all.deb drbd8-utils_8.4.1-0_amd64.deb
module-assistant auto-install drbd8
reboot

2- What is buggy checksum offloading?
3- what is buggy network card driver?

Thank you in advance for your kind and fine attention

Best regards
Cesar

Re-Edit : I want really the latest stable version of DRBD, and i think that is 8.4.3
 
Last edited:
I agree with e100's advice in posting #57.

Also, I think it's a bad idea to upgrade DRBD in this unstable situation. Configuration files have changed significantly between 8.3 and 8.4, that will add to the trouble you already have.
 
richardvd said:
I agree with e100's advice in posting #57.

Also, I think it's a bad idea to upgrade DRBD in this unstable situation. Configuration files have changed significantly between 8.3 and 8.4, that will add to the trouble you already have.
Click to expand...

Thanks richardvd for your answer, but for now i want to try with DRBD 8.4.2 because it can not be worse.

Now in one node i have executed:
mkdir ~/drbd && cd ~/drbd
apt-get install git-core git-buildpackage fakeroot debconf-utils docbook-xml docbook-xsl dpatch xsltproc autoconf flex module-assistant git build-essential autoconf debhelper dpatch debhelper

apt-get install pve-headers-2.6.32-19-pve
git clone http://git.drbd.org/drbd-8.4.git
cd drbd-8.4
git checkout drbd-8.4.2
dpkg-buildpackage -rfakeroot -b -uc
cd ..
dpkg -i drbd8-module-source_8.4.2-0_all.deb drbd8-utils_8.4.2-0_amd64.deb

So far all is ok!

But the problem is with the command:
module-assistant auto-install drbd8

This is the log:
dpatch deapply-all
rm -rf patch-stamp patch-stampT debian/patched
dh_clean
/usr/bin/make -C drbd clean
make[1]: Entering directory `/usr/src/modules/drbd/drbd'
rm -rf .tmp_versions Module.markers Module.symvers modules.order
rm -f *.[oas] *.ko .*.cmd .*.d .*.tmp *.mod.c .*.flags .depend .kernel*
rm -f compat/*.[oas] compat/.*.cmd
make[1]: Leaving directory `/usr/src/modules/drbd/drbd'
/usr/bin/make -f debian/rules kdist_clean kdist_config binary-modules
make[1]: Entering directory `/usr/src/modules/drbd'
dpatch deapply-all
rm -rf patch-stamp patch-stampT debian/patched
dh_clean
dh_clean: Compatibility levels before 5 are deprecated.
/usr/bin/make -C drbd clean
make[2]: Entering directory `/usr/src/modules/drbd/drbd'
rm -rf .tmp_versions Module.markers Module.symvers modules.order
rm -f *.[oas] *.ko .*.cmd .*.d .*.tmp *.mod.c .*.flags .depend .kernel*
rm -f compat/*.[oas] compat/.*.cmd
make[2]: Leaving directory `/usr/src/modules/drbd/drbd'
for templ in /usr/src/modules/drbd/debian/drbd8-module-_KVERS_.postinst /usr/src/modules/drbd/debian/drbd8-module-_KVERS_.postinst.backup /usr/src/modules/drbd/debian/drbd8-module-_KVERS_.postinst.modules.in /usr/src/modules/drbd/debian/drbd8-module-_KVERS_.postrm /usr/src/modules/drbd/debian/drbd8-module-_KVERS_.postrm.backup /usr/src/modules/drbd/debian/drbd8-module-_KVERS_.postrm.modules.in; do \
cp $templ `echo $templ | sed -e 's/_KVERS_/2.6.32-19-pve/g'` ; \
done
for templ in `ls debian/*.modules.in` ; do \
test -e ${templ%.modules.in}.backup || cp ${templ%.modules.in} ${templ%.modules.in}.backup 2>/dev/null || true; \
sed -e 's/##KVERS##/2.6.32-19-pve/g ;s/#KVERS#/2.6.32-19-pve/g ; s/_KVERS_/2.6.32-19-pve/g ; s/##KDREV##//g ; s/#KDREV#//g ; s/_KDREV_//g ' < $templ > ${templ%.modules.in}; \
done
dh_testdir
dh_testroot
dh_clean -k
dh_clean: dh_clean -k is deprecated; use dh_prep instead
dh_clean: Compatibility levels before 5 are deprecated.
/usr/bin/make -C drbd KERNEL_SOURCES=/usr/src/linux-headers-2.6.32-19-pve MODVERSIONS=detect KERNEL=linux-2.6.32-19-pve KDIR=/usr/src/linux-headers-2.6.32-19-pve
make[2]: Entering directory `/usr/src/modules/drbd/drbd'

Calling toplevel makefile of kernel source tree, which I believe is in
KDIR=/usr/src/linux-headers-2.6.32-19-pve


/usr/bin/make -C /usr/src/linux-headers-2.6.32-19-pve SUBDIRS=/usr/src/modules/drbd/drbd modules
make[3]: Entering directory `/usr/src/linux-headers-2.6.32-19-pve'
CC [M] /usr/src/modules/drbd/drbd/drbd_buildtag.o
CC [M] /usr/src/modules/drbd/drbd/drbd_bitmap.o
CC [M] /usr/src/modules/drbd/drbd/drbd_proc.o
CC [M] /usr/src/modules/drbd/drbd/drbd_worker.o
CC [M] /usr/src/modules/drbd/drbd/drbd_receiver.o
CC [M] /usr/src/modules/drbd/drbd/drbd_req.o
CC [M] /usr/src/modules/drbd/drbd/drbd_actlog.o
CC [M] /usr/src/modules/drbd/drbd/lru_cache.o
CC [M] /usr/src/modules/drbd/drbd/drbd_main.o
CC [M] /usr/src/modules/drbd/drbd/drbd_strings.o
CC [M] /usr/src/modules/drbd/drbd/drbd_nl.o
CC [M] /usr/src/modules/drbd/drbd/drbd_interval.o
CC [M] /usr/src/modules/drbd/drbd/drbd_state.o
CC [M] /usr/src/modules/drbd/drbd/compat/idr.o
/usr/src/modules/drbd/drbd/compat/idr.c: In function 'idr_get_next':
/usr/src/modules/drbd/drbd/compat/idr.c:16: error: 'MAX_LEVEL' undeclared (first use in this function)
/usr/src/modules/drbd/drbd/compat/idr.c:16: error: (Each undeclared identifier is reported only once
/usr/src/modules/drbd/drbd/compat/idr.c:16: error: for each function it appears in.)
/usr/src/modules/drbd/drbd/compat/idr.c:16: warning: unused variable 'pa'
make[4]: *** [/usr/src/modules/drbd/drbd/compat/idr.o] Error 1
make[3]: *** [_module_/usr/src/modules/drbd/drbd] Error 2
make[3]: Leaving directory `/usr/src/linux-headers-2.6.32-19-pve'
make[2]: *** [kbuild] Error 2
make[2]: Leaving directory `/usr/src/modules/drbd/drbd'
make[1]: *** [binary-modules] Error 2
make[1]: Leaving directory `/usr/src/modules/drbd'
make: *** [kdist_build] Error 2


Can you or anyone help me for complete this installation?
 
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