Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
>> Does anybody know what kind of configuration setup is necessary on >> openSUSE 11.1 to bring a drdb-device into primary role during the >> execution of the initrd linuxrc-script? >> The purpose would be that on one node a drbd-device gets primary before >> fsck checks the underlying FS during system boot and the device is ready >> for auto-mounting via fstab. >> >> So far I have figured out: Because drbd needs the /etc/drbd.conf, it is >> not sufficient to add the drbd-module to the INITRD_MODULES list and run >> 'mkinitrd', because the mkinitrd scripts are missing for handling drdb >> specific tasks during generation of the initial ramdisk. >> >> Is it possible to add the necessary drbd items manually to an existing >> initrd? >> > You probably won't like my comment: > Don't do that. > > Do not try to activate drbd from your initrd. > Simply don't. > It is in almost every case the completly wrong approach. > > > But, maybe you have a very good reason > to try to activate drbd from your initrd, > so please, what exactly are you up to? > > Hm, can you tell me/us why it is not advisable to activate drbd right out of initrd? I was thinking of the device mapper (LVM, softRAID, ...) which is capable to come up during initial boot. That is the user can rely on the devices already activated and ready for usage, even fsck had been taken place. Why wouldn't it be possible to do the same with drdb? Of course I can bring up the system first and add another init-script to bring a drbd-device first up to primary role, then mount it and then start e.g. NFS. Or I change the dependencies of the init-scripts. Especially in this case I just want to use drbd as a 'simple' networked RAID1, where a replicate is on a different node to have a worst case backup of 1,5 TB of data. That is the primary role won't switch from one node to the other. The drdb-device on Node1 is always primary and directly available upon reboot. Henrik -------------- next part -------------- A non-text attachment was scrubbed... Name: henrik_kuhn.vcf Type: text/x-vcard Size: 286 bytes Desc: not available URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20100305/40a5de66/attachment.vcf>