Mailing List Archive

did you install iptables in your debian 11 VM?

On Mon, 4 Oct 2021 at 11:09, Chris Myers <chrismyers81@gmail.com> wrote:

> I'm working on upgrading my Xen environments from Debian 10 to 11. Today I
> tried one of my dom0's and that seemed to go fine, so I tried a couple of
> domu's. That didn't go quite so well; when they started up the networking
> wouldn't start.
>
> Doing some checks, the error message was that it was in the pre-up
> scripts, which I've only got one thing - restoring the iptables rulesets.
>
> Trying to do a generic iptables -V gives the generic message
>
> iptables/1.8.7 Failed to initialize nft: Protocol not supported
>
> I ran the same command on the dom0 and it worked correctly.
>
> I'm restoring my domu snapshots to revert them back to Debian 10, but was
> curious - is there a way to get the regular iptables-nft stuff to work in a
> Debian 11 pv domu, or do I need to start migrating over all of my firewall
> rules (hundreds of them, with some really complex stuff set up that I'm not
> ready to have break and try to fix...) before I can upgrade my VMs?
>
> Chris
>


--
--
GPG key fingerprint: 07DF B95B DB58 57B6 9656 682E 830A D092 288E F017
GPG public key available on pgp(dot)net key server

Hey,

As nft seems to me mainly coming from modules (and because seems to be
installed), I would check the kernel of guests: which one is loaded, how,
does it comes with nft modules....

Cheers,

mathias

Le lun. 4 oct. 2021 à 03:25, TMC <tmciolek@gmail.com> a écrit :

> did you install iptables in your debian 11 VM?
>
> On Mon, 4 Oct 2021 at 11:09, Chris Myers <chrismyers81@gmail.com> wrote:
>
>> I'm working on upgrading my Xen environments from Debian 10 to 11. Today
>> I tried one of my dom0's and that seemed to go fine, so I tried a couple of
>> domu's. That didn't go quite so well; when they started up the networking
>> wouldn't start.
>>
>> Doing some checks, the error message was that it was in the pre-up
>> scripts, which I've only got one thing - restoring the iptables rulesets.
>>
>> Trying to do a generic iptables -V gives the generic message
>>
>> iptables/1.8.7 Failed to initialize nft: Protocol not supported
>>
>> I ran the same command on the dom0 and it worked correctly.
>>
>> I'm restoring my domu snapshots to revert them back to Debian 10, but was
>> curious - is there a way to get the regular iptables-nft stuff to work in a
>> Debian 11 pv domu, or do I need to start migrating over all of my firewall
>> rules (hundreds of them, with some really complex stuff set up that I'm not
>> ready to have break and try to fix...) before I can upgrade my VMs?
>>
>> Chris
>>
>
>
> --
> --
> GPG key fingerprint: 07DF B95B DB58 57B6 9656 682E 830A D092 288E F017
> GPG public key available on pgp(dot)net key server
>

On Sun, Oct 03, 2021 at 07:08:10PM -0500, Chris Myers wrote:
> Trying to do a generic iptables -V gives the generic message
> iptables/1.8.7 Failed to initialize nft: Protocol not supported

You are missing NFT support in the kernel. So you run the kernel not
shipped in this version of Debian or in an environment that forbids
loading modules. You could use a workaround and revert to the old
iptables interface, by using iptables-legacy (see update-alternatives
--list iptables).

Bastian

--
"... freedom ... is a worship word..."
"It is our worship word too."
-- Cloud William and Kirk, "The Omega Glory", stardate unknown

Hi Chris,

On Sun, Oct 03, 2021 at 07:08:10PM -0500, Chris Myers wrote:
is there a way to get the regular iptables-nft stuff to work in a
> Debian 11 pv domu,

I've not had any issues using iptables, with nft or legacy, in
Debian 11 or Debian 12 PV domU, so I think your problem is strictly
related to the kernel you are using.

Can you confirm whether your domU kernel and its modules are ones
that come from the linux-image-amd64 package that comes with Debian
11?

Cheers,
Andy

Debian 12?

On Tue, 5 Oct 2021 at 06:51, Andy Smith <andy@strugglers.net> wrote:

> Hi Chris,
>
> On Sun, Oct 03, 2021 at 07:08:10PM -0500, Chris Myers wrote:
> is there a way to get the regular iptables-nft stuff to work in a
> > Debian 11 pv domu,
>
> I've not had any issues using iptables, with nft or legacy, in
> Debian 11 or Debian 12 PV domU, so I think your problem is strictly
> related to the kernel you are using.
>
> Can you confirm whether your domU kernel and its modules are ones
> that come from the linux-image-amd64 package that comes with Debian
> 11?
>
> Cheers,
> Andy
>
>

--
--
GPG key fingerprint: 07DF B95B DB58 57B6 9656 682E 830A D092 288E F017
GPG public key available on pgp(dot)net key server

Hello,

On Tue, Oct 05, 2021 at 10:30:59AM +1100, TMC wrote:
> Debian 12?

Okay, so what will be Debian 12 when it's released - the current
testing distribution, bookworm. It currently has a 5.14.x kernel, as
opposed to 11's (bullseye's) 5.10.x.

Cheers,
Andy

Forgot to do reply all ... with some additional details at the bottom.

Thanks for all the replies!

I re-upgraded one of the VMs that I had to revert last night, and tonight
it's working, no errors. Exact same commands --
- Make sure all Deb10 patches installed
- apt clean
- Flip sources.list
- apt update
- apt upgrade --without-new-pkgs
- apt full-upgrade
- reboot

I realized what's different though. Last night I also changed what kernel I
was using on the guest. I flipped my vmname.cfg from
[...]
kernel = '/boot/vmlinuz-5.10.0-8-amd64'
ramdisk = '/boot/initrd.img-5.10.0-8-amd64'
[...]
(the kernel version that came with Debian 11)
back to the 4.19.0-16-amd64 that was with Debian 10.

Is it possible that the 5.10.0-8-amd64 that comes with Debian 11 isn't all
the way there? I can confirm that the linux-image-amd64 is the one that
came as a part of doing the in-place upgrade. I don't mess with custom
kernels etc., just the ones that come straight from apt's wisdom. From the
perspective of the dom0 ::

# uname -a
Linux vhost 5.10.0-8-amd64 #1 SMP Debian 5.10.46-5 (2021-09-23) x86_64
GNU/Linux

# apt list --installed | grep linux-image-amd64

WARNING: apt does not have a stable CLI interface. Use with caution in
scripts.

linux-image-amd64/stable-security,now 5.10.46-5 amd64 [installed]

# md5sum ./var/cache/apt/archives/linux-image-amd64_5.10.46-5_amd64.deb
9e4185453765f40a69e248925ed0366f
./var/cache/apt/archives/linux-image-amd64_5.10.46-5_amd64.deb


/lib/modules# ls
4.19.0-13-amd64 4.19.0-16-amd64 4.19.0-17-amd64 5.10.0-8-amd64






On Mon, Oct 4, 2021 at 7:18 PM Andy Smith <andy@strugglers.net> wrote:

> Hello,
>
> On Tue, Oct 05, 2021 at 10:30:59AM +1100, TMC wrote:
> > Debian 12?
>
> Okay, so what will be Debian 12 when it's released - the current
> testing distribution, bookworm. It currently has a 5.14.x kernel, as
> opposed to 11's (bullseye's) 5.10.x.
>
> Cheers,
> Andy
>
>

--
People use duct tape to fix everything....God used nails.

http://www.myerscountry.net

Hello,

On Mon, Oct 04, 2021 at 08:11:52PM -0500, Chris Myers wrote:
> I re-upgraded one of the VMs that I had to revert last night, and tonight
> it's working, no errors. Exact same commands --
> - Make sure all Deb10 patches installed
> - apt clean
> - Flip sources.list

When you do this step do you make sure to get the new format
"bullseye-security/updates" line correct? Because without that, you
end up with linux-image-5.10.0-8-amd64 version 5.10.46-4, not version
5.10.46-5.

> I flipped my vmname.cfg from
> [...]
> kernel = '/boot/vmlinuz-5.10.0-8-amd64'
> ramdisk = '/boot/initrd.img-5.10.0-8-amd64'
> [...]
> (the kernel version that came with Debian 11)
> back to the 4.19.0-16-amd64 that was with Debian 10.
>
> Is it possible that the 5.10.0-8-amd64 that comes with Debian 11 isn't all
> the way there?

It works for me on 14 different domUs at present, so I'd say not
likely.

> I can confirm that the linux-image-amd64 is the one that
> came as a part of doing the in-place upgrade. I don't mess with custom
> kernels etc., just the ones that come straight from apt's wisdom.

The way you are booting these domains though inherently requires
synchronisation between the domU's config file in dom0 (that says
which kernel+initramfs to use) and the /lib/modules directory in the
domU. Easy to make a mistake.

So are you sure that you haven't mismatched something there?

Once you've got to the bottom of this I recommend switching to
pvhgrub booting to do away with that class of problems…

> From the perspective of the dom0 ::

[…]

> /lib/modules# ls
> 4.19.0-13-amd64 4.19.0-16-amd64 4.19.0-17-amd64 5.10.0-8-amd64

…and the domU in question has that same /lib/modules/5.10.0-8-amd64
directory tree from dom0?

Cheers,
Andy

Le sigh that would be it...I feel like a doofus now. I'd totally forgotten
to do that after the upgrade ... I'm surprised the silly things booted at
all.

Out of curiosity is there a better/preferred way of handling it so that I
don't need to remember to keep them in sync every time I do a kernel
upgrade?

On Mon, Oct 4, 2021 at 8:28 PM Andy Smith <andy@strugglers.net> wrote:

> Hello,
>
> On Mon, Oct 04, 2021 at 08:11:52PM -0500, Chris Myers wrote:
> > I re-upgraded one of the VMs that I had to revert last night, and tonight
> > it's working, no errors. Exact same commands --
> > - Make sure all Deb10 patches installed
> > - apt clean
> > - Flip sources.list
>
> When you do this step do you make sure to get the new format
> "bullseye-security/updates" line correct? Because without that, you
> end up with linux-image-5.10.0-8-amd64 version 5.10.46-4, not version
> 5.10.46-5.
>
> > I flipped my vmname.cfg from
> > [...]
> > kernel = '/boot/vmlinuz-5.10.0-8-amd64'
> > ramdisk = '/boot/initrd.img-5.10.0-8-amd64'
> > [...]
> > (the kernel version that came with Debian 11)
> > back to the 4.19.0-16-amd64 that was with Debian 10.
> >
> > Is it possible that the 5.10.0-8-amd64 that comes with Debian 11 isn't
> all
> > the way there?
>
> It works for me on 14 different domUs at present, so I'd say not
> likely.
>
> > I can confirm that the linux-image-amd64 is the one that
> > came as a part of doing the in-place upgrade. I don't mess with custom
> > kernels etc., just the ones that come straight from apt's wisdom.
>
> The way you are booting these domains though inherently requires
> synchronisation between the domU's config file in dom0 (that says
> which kernel+initramfs to use) and the /lib/modules directory in the
> domU. Easy to make a mistake.
>
> So are you sure that you haven't mismatched something there?
>
> Once you've got to the bottom of this I recommend switching to
> pvhgrub booting to do away with that class of problems…
>
> > From the perspective of the dom0 ::
>
> […]
>
> > /lib/modules# ls
> > 4.19.0-13-amd64 4.19.0-16-amd64 4.19.0-17-amd64 5.10.0-8-amd64
>
> …and the domU in question has that same /lib/modules/5.10.0-8-amd64
> directory tree from dom0?
>
> Cheers,
> Andy
>
>

--
People use duct tape to fix everything....God used nails.

http://www.myerscountry.net

On Mon, Oct 04, 2021 at 08:35:35PM -0500, Chris Myers wrote:
> Out of curiosity is there a better/preferred way of handling it so that I
> don't need to remember to keep them in sync every time I do a kernel
> upgrade?

> > Once you've got to the bottom of this I recommend switching to
> > pvhgrub booting to do away with that class of problems…

Thanks! I'll check that out.

Up to this point I've always just done in-place upgrades of everything
(been running Xen PV domu's for about 7 years now) and have just followed
with that old way because it generally just worked (with a few nuances.)

On Mon, Oct 4, 2021 at 8:38 PM Andy Smith <andy@strugglers.net> wrote:

> On Mon, Oct 04, 2021 at 08:35:35PM -0500, Chris Myers wrote:
> > Out of curiosity is there a better/preferred way of handling it so that I
> > don't need to remember to keep them in sync every time I do a kernel
> > upgrade?
>
> > > Once you've got to the bottom of this I recommend switching to
> > > pvhgrub booting to do away with that class of problems…
>
>

--
People use duct tape to fix everything....God used nails.

http://www.myerscountry.net