Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Segmentation fault . . . Hmm . . . Can't be the kernel version, that is still in 2.4 land for RH9 I believe. 2.4 is supported by DRBD still, and I can't imagine you would use a lower version for any reason. It might be worth a try on the newer systems. THere are a lot of things that need to be just right when you install DRBD. For one, you want to use the same compiler version for it that you used on your kernel. If that has changed or been upgraded since you built the computer, and you haven't compiled a new kernel with it, this could explain stuff. Also, you must have the exact same version of source as your running kernel. One thing to try to be sure all things are equal, is to simply recompile your kernel with the source that you now have, get it running, then delete and re-create the source directory, and compile DRBD against it. Let us know how it goes! -----Original Message----- From: drbd-user-bounces at lists.linbit.com [mailto:drbd-user-bounces at lists.linbit.com] On Behalf Of David Sent: Saturday, May 21, 2005 11:40 PM To: DRBD List Subject: Re: [DRBD-user] DRBD on redhat 9 ----- Original Message ----- From: Discussion Lists <mailto:discussions at lagraphico.com> To: David <mailto:david at davidbranford.net> Sent: Sunday, May 22, 2005 6:52 AM Subject: RE: [DRBD-user] DRBD on redhat 9 Coupla things: When you create your partitions, I assume you are using fdisk right? After you write them, do you reboot before going on? The kernel has to re-read the partition table to see the new partitions. I skimmed through your post, so I appologize if I missed the part where you stated that you did. That's OK, I didn't say I did... but I did :) ALso try the following mknod command instead of what you have been using: mknod -m 0660 /dev/drbd0 b 147 0 okay I am not entirely sure what the difference is, but I know it worked for me. I also do that stuff in the following context when setting up for the first time: mknod -m 0660 /dev/drbd0 b 147 0 modprobe drbd drbdsetup /dev/drbd0 disk /dev/sdb1 /dev/sdb2 0 --on-io-error=detach drbdsetup /dev/drbd0 syncer --rate=30M --group=1 --al-extents=257 drbdsetup /dev/drbd0 net $THISNODEIP:7789 $OTHERNODEIP:7789 C drbdsetup /dev/drbd0 primary --do-what-I-say mkfs -j /dev/drbd0 tune2fs -c -1 -i 0 /dev/drbd0 Obviously replace the variables, and the sdb* with hdb* though. Again, I am not saying this is the BEST way to do it, because I am no uber genious DRBD expert, but it is what worked for me. Once you get that going with no error, do a "cat /proc/drbd" to confirm that it looks good, then do a "drbdadm down all" and try to start it up from your init script. You will also want to create a directory somewhere, and then set up mount and umount statement in your init script. hmm, following these same commands, I get to here: [root at celery root]# modprobe drbd [root at celery root]# drbdsetup /dev/drbd0 disk /dev/hdc1 /dev/hda5 0 --on-io-error=detach Segmentation fault ...and the same appears in my system log files as before: May 22 16:01:54 celery kernel: drbd: initialised. Version: 0.7.10 (api:77/proto:74) May 22 16:01:54 celery kernel: drbd: SVN Revision: 1743 build by phil at mescal, 2005-01-31 12:22:07 May 22 16:01:54 celery kernel: drbd: registered as block device major 147 May 22 16:03:08 celery kernel: drbd0: Both nodes diskless! May 22 16:03:08 celery kernel: drbd0: Assuming that all blocks are out of sync (aka FullSync) May 22 16:03:08 celery kernel: drbd0: drbd_bm_set_all: (!(b && b->bm)) in drbd_bitmap.c:553 May 22 16:03:08 celery kernel: d419be98 d894f1b7 d8963d00 00000000 d89635b1 d896970d 00000229 00000000 May 22 16:03:08 celery kernel: 00000000 d8951294 d4053000 00000000 000001c9 00000246 c1e5f005 00000002 May 22 16:03:08 celery kernel: 00000000 00000000 00000000 00001601 d7aba380 d4250900 0000000f 00000001 May 22 16:03:08 celery kernel: Call Trace: [<d894f1b7>] drbd_bm_set_all [drbd] 0x137 (0xd419be9c)) May 22 16:03:08 celery kernel: [<d8963d00>] .rodata.str1.32 [drbd] 0x260 (0xd419bea0)) May 22 16:03:08 celery kernel: [<d89635b1>] __func__.17 [drbd] 0x0 (0xd419bea8)) May 22 16:03:08 celery kernel: [<d896970d>] .rodata.str1.1 [drbd] 0x0 (0xd419beac)) May 22 16:03:08 celery kernel: [<d8951294>] drbd_ioctl_set_disk [drbd] 0x624 (0xd419bebc)) May 22 16:03:08 celery kernel: [<d89528b6>] drbd_ioctl [drbd] 0x846 (0xd419bf28)) May 22 16:03:08 celery kernel: [<c014ec6e>] blkdev_ioctl [kernel] 0x3e (0xd419bf80)) May 22 16:03:08 celery kernel: [<c01571a9>] sys_ioctl [kernel] 0xc9 (0xd419bf94)) May 22 16:03:08 celery kernel: [<c010953f>] system_call [kernel] 0x33 (0xd419bfc0)) May 22 16:03:08 celery kernel: May 22 16:03:08 celery kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000000 May 22 16:03:08 celery kernel: printing eip: May 22 16:03:08 celery kernel: d894f0ae May 22 16:03:08 celery kernel: *pde = 00000000 May 22 16:03:08 celery kernel: Oops: 0000 May 22 16:03:08 celery kernel: drbd parport_pc lp parport autofs sis900 keybdev mousedev hid input usb-ohci usbcore ext3 jbd May 22 16:03:08 celery kernel: CPU: 0 May 22 16:03:08 celery kernel: EIP: 0060:[<d894f0ae>] Not tainted May 22 16:03:08 celery kernel: EFLAGS: 00010082 May 22 16:03:08 celery kernel: May 22 16:03:08 celery kernel: EIP is at drbd_bm_set_all [drbd] 0x2e (2.4.20-31.9) May 22 16:03:08 celery kernel: eax: 00000000 ebx: d4685480 ecx: 00000001 edx: 00000000 May 22 16:03:08 celery kernel: esi: d4053000 edi: d4053000 ebp: 00000000 esp: d419bea0 May 22 16:03:08 celery kernel: ds: 0068 es: 0068 ss: 0068 May 22 16:03:08 celery kernel: Process drbdsetup (pid: 2619, stackpage=d419b000) May 22 16:03:08 celery kernel: Stack: d8963d00 00000000 d89635b1 d896970d 00000229 00000000 00000000 d8951294 May 22 16:03:08 celery kernel: d4053000 00000000 000001c9 00000246 c1e5f005 00000002 00000000 00000000 May 22 16:03:08 celery kernel: 00000000 00001601 d7aba380 d4250900 0000000f 00000001 00000000 00000000 May 22 16:03:08 celery kernel: Call Trace: [<d8963d00>] .rodata.str1.32 [drbd] 0x260 (0xd419bea0)) May 22 16:03:08 celery kernel: [<d89635b1>] __func__.17 [drbd] 0x0 (0xd419bea8)) May 22 16:03:08 celery kernel: [<d896970d>] .rodata.str1.1 [drbd] 0x0 (0xd419beac)) May 22 16:03:08 celery kernel: [<d8951294>] drbd_ioctl_set_disk [drbd] 0x624 (0xd419bebc)) May 22 16:03:08 celery kernel: [<d89528b6>] drbd_ioctl [drbd] 0x846 (0xd419bf28)) May 22 16:03:08 celery kernel: [<c014ec6e>] blkdev_ioctl [kernel] 0x3e (0xd419bf80)) May 22 16:03:08 celery kernel: [<c01571a9>] sys_ioctl [kernel] 0xc9 (0xd419bf94)) May 22 16:03:08 celery kernel: [<c010953f>] system_call [kernel] 0x33 (0xd419bfc0)) May 22 16:03:08 celery kernel: May 22 16:03:08 celery kernel: May 22 16:03:08 celery kernel: Code: 81 3c 90 67 02 74 83 74 33 c7 44 24 0c 2e 02 00 00 8b 15 30 same on pii (?? a seg. fault on two different systems, running the same os? I must be doing something wrong somewhere...) Thanks for the extra info. though; know I'm assured it's at least _possible_ to get working on fedora 2/3 perhaps I'll try one of those (but that's a big change). David. HTH -----Original Message----- From: drbd-user-bounces at lists.linbit.com [mailto:drbd-user-bounces at lists.linbit.com] On Behalf Of David Sent: Saturday, May 21, 2005 12:10 PM To: DRBD List Subject: Re: [DRBD-user] DRBD on redhat 9 ----- Original Message ----- From: Discussion Lists <mailto:discussions at lagraphico.com> To: David <mailto:david at davidbranford.net> ; DRBD List <mailto:drbd-user at lists.linbit.com> Sent: Sunday, May 22, 2005 3:49 AM Subject: RE: [DRBD-user] DRBD on redhat 9 I have not tried to get it running on Redhat, but I have successfully gotten it running on FC1 and FC3 with success. I had to be very dilligent about following the instructions in the INSTALL file. I have also it helps in certain cases to know a little about kernel upgrading and patching. Any errors you are getting? Are you sure IPTables isn't blocking any network traffic? My setup is as here: http://www.gossamer-threads.com/lists/drbd/users/8260 Basically two machines on a private LAN, no firewall rules (IPTABLES default policy "accept"), using redhat kernel. I have not patched my kernel, and I have compiled drbd (0.7.10) as a kernel module, against the kernel source. I have followed the instructions in the INSTALL file as closely as possible; everything worked as expected as far as configuring/compiling/installing until I came to running drbdadm, then I got the kernel errors I listed in the above post. Thanks, David. -----Original Message----- From: drbd-user-bounces at lists.linbit.com [mailto:drbd-user-bounces at lists.linbit.com] On Behalf Of David Sent: Saturday, May 21, 2005 2:53 AM To: DRBD List Subject: [DRBD-user] DRBD on redhat 9 Hi everyone, Has anybody succeeded in making drbd work on redhat 9? If so, could you share a couple of details like kernel version, drbd version (ie. 0.7.10?) as I am stuck and don't want to do a full re-install for fedora or something (which, btw, I have not made drbd work on successfully yet either). Especially I am hoping there is someone out there who has drbd working on redhat 9 on a 2.4x version kernel... Many thanks, David. !DSPAM:428fa69e236324445860300! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20050522/6bc3e0da/attachment.htm>