[DRBD-user] DRBD9 not building on PVE6.1

[Gianni Milo]

Thanks Roland for your suggestions, they were very helpful.

Just a side note, tested your docker image from dockerhub
(linbit/coccinelle), but it appears to be slightly outdated (it's on 1.0.7).
To be honest, the tarball method works fine for me, but having also the
docker image up to date would be helpful.

B.R.
G.


On Mon, 9 Dec 2019 at 09:16, Roland Kammerer <roland.kammerer at linbit.com>
wrote:

> On Sun, Dec 08, 2019 at 09:00:09AM +0000, Gianni Milo wrote:
> > Hi Christoph,
> >
> > I followed your suggestions and below follows the outcome of it...
> >
> > - I'm using DRBD9 on Proxmox, which in turn its based on Debian 10, so
> the
> > PPA method did not work as it's designed for Ubuntu?
>
> Yes. https://wiki.debian.org/DontBreakDebian . Don't mix in PPAs if you
> do not exactly know why.
>
> > - Debian 10 ships with an old spatch version (1.0.4), where DRBD requires
> > 1.0.8, so no luck there as well.
>
> Also true.
>
> > -Only solution for Proxmox users seem to be using SPAAS method and that
> > works, as soon as Proxmox servers have unrestricted access to the
> internet.
> > In our topology that's not the case, as these servers cannot access
> > internet hosts on non standard ports.Your SPAAS service requires access
> to
> > the port TCP 2020. Would it be possible to use a fallback port TCP 443 or
> > TCP 80 instead ?
>
> I think about it. Currently we host it on a server that already uses
> 80/443 for something else.
>
> > - One last method, which also seems to work is  by using a separate
> machine
> > (or VM), with Proxmox installed and with unrestricted access to the
> > internet. Build DRBD kernel modules in there (with SPAAS) and manually
> > transfer them  to the production servers (in
> > /lib/modules/<kernel_version>/updates).
>
> One additional way would be to extract the tarball on a machine you can
> access SPAAS and where you have the exact same kernel version as on the
> destination. Then build it, which will fetch a SPAAS generated patch.
> Then generate the dkms package from that and dpkg -i it. This then finds
> the patch in the cache and does not try to fetch it. Not very nice, just
> saying it could be done like this.
>
> What some devs, me included, did for some time was to use a 'spatch'
> that was in fact a Docker container containing an spatch recent enough.
> You most likely don't want that in production either, but it could be
> used instead of SPAAS for the above described tarball-repacking.
>
> Best, rck
> _______________________________________________
> Star us on GITHUB: https://github.com/LINBIT
> drbd-user mailing list
> drbd-user at lists.linbit.com
> https://lists.linbit.com/mailman/listinfo/drbd-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20191209/eb4fdca7/attachment.html>