Possible regression for BTRFS in 2.18

Sorry for going straight to github issues in the past - I didn’t know about this forum. I’ll suss this one out here and file an issue if it is in fact an issue.

root@wyzlap:/mnt/c/Users/Sean# ssh root@wyzsrv
Welcome to Ubuntu 16.04.3 LTS (GNU/Linux 4.4.0-97-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage

0 packages can be updated.
0 updates are security updates.


Last login: Thu Oct 19 20:01:47 2017 from 192.168.1.99
root@wyzsrv:~# lxc info
config:
  core.https_address: '[::]:8443'
api_extensions:
- storage_zfs_remove_snapshots
- container_host_shutdown_timeout
- container_syscall_filtering
- auth_pki
- container_last_used_at
- etag
- patch
- usb_devices
- https_allowed_credentials
- image_compression_algorithm
- directory_manipulation
- container_cpu_time
- storage_zfs_use_refquota
- storage_lvm_mount_options
- network
- profile_usedby
- container_push
- container_exec_recording
- certificate_update
- container_exec_signal_handling
- gpu_devices
- container_image_properties
- migration_progress
- id_map
- network_firewall_filtering
- network_routes
- storage
- file_delete
- file_append
- network_dhcp_expiry
- storage_lvm_vg_rename
- storage_lvm_thinpool_rename
- network_vlan
- image_create_aliases
- container_stateless_copy
- container_only_migration
- storage_zfs_clone_copy
- unix_device_rename
- storage_lvm_use_thinpool
- storage_rsync_bwlimit
- network_vxlan_interface
- storage_btrfs_mount_options
- entity_description
- image_force_refresh
- storage_lvm_lv_resizing
- id_map_base
- file_symlinks
- container_push_target
- network_vlan_physical
- storage_images_delete
- container_edit_metadata
- container_snapshot_stateful_migration
- storage_driver_ceph
- storage_ceph_user_name
- resource_limits
- storage_volatile_initial_source
- storage_ceph_force_osd_reuse
- storage_block_filesystem_btrfs
api_status: stable
api_version: "1.0"
auth: trusted
public: false
environment:
  addresses:
  - 192.168.1.75:8443
  architectures:
  - x86_64
  - i686
  certificate: |
    -----BEGIN CERTIFICATE-----
    MIIFQTCCAymgAwIBAgIRALo7K41xPnu2nKOEJiWH3jowDQYJKoZIhvcNAQELBQAw
    NDEcMBoGA1UEChMTbGludXhjb250YWluZXJzLm9yZzEUMBIGA1UEAwwLcm9vdEB3
    eXpzcnYwHhcNMTcxMDE4MTgxNDI4WhcNMjcxMDE2MTgxNDI4WjA0MRwwGgYDVQQK
    ExNsaW51eGNvbnRhaW5lcnMub3JnMRQwEgYDVQQDDAtyb290QHd5enNydjCCAiIw
    DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAMBYv9/zg+yPeBR/l+wco1hkr6Zl
    TVaBamgcCbySoYYqoBCQUiRig/37gzESMJScFLtYPAelPZKbUlo+1gldr3eKXgG8
    1rK2CWRuTj0oCAgknZC4fQWObDEHJKqvr7BjZRNJachs7fz+pMtoH6zg3NSmsFnU
    +LuRuk+tSozpTpqBBjsBwXlAL+nWAr6UfjreiZamqC1kVb/gMYKvqYaTUQ7+uv7B
    DR4ABNsOarkGiAXmgfUevIgXnDkekOIC8JybrxNvRJn2ifyPI4AMwH2R9l2KUX7j
    K8w7pKhzsfyVxeLKFAdD8m5QyGiaAWmIumNLX+t6nKATK2RToU2NtVlWZNePVp6D
    3PER8dCXJ29ek3e5vYN2wAX9ixGScTJVk/aG7Jrij5mY538IsRb+BMm+U1S5NQVw
    iWMl3HYyo24Fc3E3+SNDDL/D+hewU0Zp7KMCu0ACte+ltXjDIr84FnV+hWAmru4d
    PWELhhqoRBZQG+3WGKDyuz0gXZmjlLa+PQKCFQRmy35DAqa0+NTzwzjhfWCpQHc4
    84DiWZ7FSX/yObKk0ts0h9sBU/k0/NRnvlbBtts8dujbVcBBghyvbXlIaV0GpHCJ
    Z24iPjVrmLHTdd+0mKaFHnJ8P+Fyesnghl4DkznurcRPt3f15wGfgkQEiGeTo4IE
    Sn0rDo7T7muwIg1XAgMBAAGjTjBMMA4GA1UdDwEB/wQEAwIFoDATBgNVHSUEDDAK
    BggrBgEFBQcDATAMBgNVHRMBAf8EAjAAMBcGA1UdEQQQMA6CBnd5enNydocEwKgB
    SzANBgkqhkiG9w0BAQsFAAOCAgEAai3yF7lYVUwH08NWXFWwYyxuApLxWtDjYEC4
    5Titd5w1SERkznAWEe6G88q7InDqIF5w6z7In46mMjfd8BPSdV0+0Z0m2IYBul7L
    rvYEuT3vywJWNZuidzFLacLQVoMoQiAK6eFUWZ13s9NDxDXOw34fLIEoDmylFf/W
    ilZ/4He8HFRCikFG67F1qrVTJw0ODDdDjuuWqsl9pzjsHDub5qpMFQvyMMRE76lJ
    fnjGylEtrUpUxIfwtd/bU9iEFU6NNvaM/eZCkL5C3hK6Qihj8MIG/e79b4FXUt8U
    bHTFZyjIy7QuQN6tJYp+PqjwNCtnoHXP36mCTp+0eTR5g9o0XkFNzR+FaBYtHNBA
    4O44EQDOxfrOwaGcC5HvSQWLjVSZwbvcZXTZ65ZFJgkQtwaCwUmgTlAY0QcqA+Mz
    l3bC5SDzLa6tf/xYFFs6aJzsOJemgUkeZDWCgYdDX/53NZDd6ju19/V3H0k4JhKW
    zyy3ZdnWMYkV1s70WB/gScoOzLPNJgD3Ai4YL036xRxXE1xt6zqa7z10F54xQUVL
    T5r3HB3x/FFjW+ipUAFVGMV7fP4HCnpcVks2qX1I9PE6bVACaLf2pFSUKhPn5dSq
    ZgAQeCLDCwDNEIg1NsLxAEWnAHusytGbCnXfOgxi8rY8zgbcoRkTfR69OTpZbEOB
    z8Ls2V8=
    -----END CERTIFICATE-----
  certificate_fingerprint: 332a47ba4f50d5365fb13fb2fc16281f14a577bc3b9e22a42f970908707b8e08
  driver: lxc
  driver_version: 2.0.8
  kernel: Linux
  kernel_architecture: x86_64
  kernel_version: 4.4.0-97-generic
  server: lxd
  server_pid: 1777
  server_version: "2.18"
  storage: btrfs
  storage_version: "4.4"
root@wyzsrv:~# cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback
root@wyzsrv:~# cat /etc/network/interfaces.d/br0
auto br0

iface br0 inet dhcp
  bridge_ports enp6s7

iface br0 inet6 auto

iface enp6s7 inet manual
iface enp6s7 inet6 manual

root@wyzsrv:~# lxc profile show default
config: {}
description: Default LXD profile
devices:
  eth0:
    nictype: bridged
    parent: br0
    type: nic
  root:
    path: /
    pool: default
    type: disk
name: default
used_by: []
root@wyzsrv:~# lxc image info ubuntu:lts
Fingerprint: 61d54418874f2f84e24ddd6934b3bb759ca76cbc49820da7d34f8b5b778e4816
Size: 156.15MB
Architecture: x86_64
Public: yes
Timestamps:
    Created: 2017/10/11 00:00 UTC
    Uploaded: 2017/10/11 00:00 UTC
    Expires: 2021/04/21 00:00 UTC
    Last used: never
Properties:
    release: xenial
    version: 16.04
    architecture: amd64
    label: release
    serial: 20171011
    description: ubuntu 16.04 LTS amd64 (release) (20171011)
    os: ubuntu
Aliases:
    - 16.04
    - 16.04/amd64
    - default
    - default/amd64
    - lts
    - lts/amd64
    - x
    - x/amd64
    - xenial
    - xenial/amd64
Cached: no
Auto update: disabled
root@wyzsrv:~# lxc launch ubuntu:lts test
Creating test
Starting test

That’s the host background

tl;dr: metal running lxd 2.18 with btrfs can’t run nested stock lxd 2.0.10 on ubunto:lts (16.04)

scenario ran successfully with metal running 2.17

scenario: lxd init --auto et. al. inside of a stock container (ubuntu:lts) where the host runs btrfs.

error info:

root@wyzsrv:~# lxc exec test bash
root@test:~# ls /var/lib/lxd
root@test:~# ls /var/lib/lxd
root@test:~# ls /var/lib/lxd
root@test:~# ls /var/lib/lxd
unix.socket
root@test:~# systemctl status lxd.socket
● lxd.socket - LXD - unix socket
   Loaded: loaded (/lib/systemd/system/lxd.socket; enabled; vendor preset: enabled)
   Active: active (listening) since Fri 2017-10-20 02:31:33 UTC; 20s ago
     Docs: man:lxd(1)
   Listen: /var/lib/lxd/unix.socket (Stream)

Oct 20 02:31:33 test systemd[1]: Starting LXD - unix socket.
Oct 20 02:31:33 test systemd[1]: Listening on LXD - unix socket.
root@test:~# systemctl status lxd-bridge
● lxd-bridge.service - LXD - network bridge
   Loaded: loaded (/lib/systemd/system/lxd-bridge.service; static; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:lxd(1)
root@test:~# systemctl status lxd
● lxd.service - LXD - main daemon
   Loaded: loaded (/lib/systemd/system/lxd.service; indirect; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:lxd(1)
root@test:~# lxd init --auto
error: Unable to talk to LXD: Get http://unix.socket/1.0: read unix @->/var/lib/lxd/unix.socket: read: connection reset by peer
root@test:~# systemctl status lxd.socket
● lxd.socket - LXD - unix socket
   Loaded: loaded (/lib/systemd/system/lxd.socket; enabled; vendor preset: enabled)
   Active: failed (Result: trigger-limit-hit) since Fri 2017-10-20 02:32:11 UTC; 3s ago
     Docs: man:lxd(1)
   Listen: /var/lib/lxd/unix.socket (Stream)

Oct 20 02:31:33 test systemd[1]: Starting LXD - unix socket.
Oct 20 02:31:33 test systemd[1]: Listening on LXD - unix socket.
root@test:~# systemctl status lxd-bridge
● lxd-bridge.service - LXD - network bridge
   Loaded: loaded (/lib/systemd/system/lxd-bridge.service; static; vendor preset: enabled)
   Active: failed (Result: exit-code) since Fri 2017-10-20 02:32:07 UTC; 10s ago
     Docs: man:lxd(1)
  Process: 621 ExecStart=/usr/lib/lxd/lxd-bridge.start (code=exited, status=2)
 Main PID: 621 (code=exited, status=2)

Oct 20 02:32:10 test systemd[1]: Failed to start LXD - network bridge.
Oct 20 02:32:10 test systemd[1]: Failed to start LXD - network bridge.
Oct 20 02:32:10 test systemd[1]: Failed to start LXD - network bridge.
Oct 20 02:32:10 test systemd[1]: Failed to start LXD - network bridge.
Oct 20 02:32:10 test systemd[1]: Failed to start LXD - network bridge.
Oct 20 02:32:10 test systemd[1]: Failed to start LXD - network bridge.
Oct 20 02:32:10 test systemd[1]: Failed to start LXD - network bridge.
Oct 20 02:32:10 test systemd[1]: Failed to start LXD - network bridge.
Oct 20 02:32:10 test systemd[1]: Failed to start LXD - network bridge.
Oct 20 02:32:10 test systemd[1]: Failed to start LXD - network bridge.
root@test:~# systemctl status lxd
● lxd.service - LXD - main daemon
   Loaded: loaded (/lib/systemd/system/lxd.service; indirect; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:lxd(1)

Oct 20 02:32:10 test systemd[1]: lxd.service: Job lxd.service/start failed with result 'dependency'.
Oct 20 02:32:10 test systemd[1]: lxd.service: Job lxd.service/start failed with result 'dependency'.
Oct 20 02:32:10 test systemd[1]: lxd.service: Job lxd.service/start failed with result 'dependency'.
Oct 20 02:32:10 test systemd[1]: lxd.service: Job lxd.service/start failed with result 'dependency'.
Oct 20 02:32:10 test systemd[1]: lxd.service: Job lxd.service/start failed with result 'dependency'.
Oct 20 02:32:10 test systemd[1]: lxd.service: Job lxd.service/start failed with result 'dependency'.
Oct 20 02:32:10 test systemd[1]: lxd.service: Job lxd.service/start failed with result 'dependency'.
Oct 20 02:32:10 test systemd[1]: lxd.service: Job lxd.service/start failed with result 'dependency'.
Oct 20 02:32:10 test systemd[1]: lxd.service: Job lxd.service/start failed with result 'dependency'.
Oct 20 02:32:10 test systemd[1]: lxd.service: Job lxd.service/start failed with result 'dependency'.

So again, the regression is that when running btrfs, you can’t nest 2.0.10 inside of a 2.18 host. My example didn’t show on the launch command -c security.nesting=true or `-c security.privileged=true’ but same results.

I don’t know if this happened on 2.17 but…

root@test:~# dmesg | grep 'BTRFS'
[   17.968929] BTRFS: device label default devid 1 transid 132 /dev/dm-4
[ 2887.916342] BTRFS info (device dm-4): disk space caching is enabled
[ 2887.916352] BTRFS: has skinny extents
[ 2942.432341] BTRFS error (device dm-4): could not find root 8
[ 3079.764178] BTRFS error (device dm-4): could not find root 8
[ 3212.802244] BTRFS error (device dm-4): could not find root 8
[ 3413.799527] BTRFS error (device dm-4): could not find root 8
[ 4660.605285] BTRFS error (device dm-4): could not find root 8
[ 6408.103605] BTRFS error (device dm-4): could not find root 8
root@test:~#```

the same results with the same grep on the host

knowing that some btrfs changes came through 2.18, I dropped and recreated my storage volume.  No difference.

This forum needs a 'preview' button so that i can see that I make sense lol, so I'm submitting and I'll edit if I don't

What happens if you run “lxd --debug --group lxd” as root inside the container?

Oh, actually it looks like it’s because lxd-bridge is failing to start in the container, so lxd itself doesn’t start.

The usual reason for this is some missing iptables modules that the container can’t load, causing lxd-bridge to fail to start.

You can try running:

/usr/lib/lxd/lxd-bridge start

Which may get you a more readable error.

INFO[10-20|02:56:28] LXD 2.0.10 is starting in normal mode    path=/var/lib/lxd
WARN[10-20|02:56:28] CGroup memory swap accounting is disabled, swap limits will be ignored.
INFO[10-20|02:56:28] Kernel uid/gid map:
INFO[10-20|02:56:28]  - u 0 100000 65536
INFO[10-20|02:56:28]  - g 0 100000 65536
INFO[10-20|02:56:28] Configured LXD uid/gid map:
INFO[10-20|02:56:28]  - u 0 100000 65536 (unusable)
INFO[10-20|02:56:28]  - g 0 100000 65536 (unusable)
WARN[10-20|02:56:28] One or more uid/gid map entry isn't usable (typically due to nesting)
WARN[10-20|02:56:28] Only privileged containers will be able to run
DBUG[10-20|02:56:31] Init                                     driver=storage/btrfs
INFO[10-20|02:56:31] Expiring log files
INFO[10-20|02:56:31] Done expiring log files
INFO[10-20|02:56:31] Starting /dev/lxd handler
DBUG[10-20|02:56:31] Looking for existing certificates        cert=/var/lib/lxd/server.crt key=/var/lib/lxd/server.key
INFO[10-20|02:56:40] LXD isn't socket activated
INFO[10-20|02:56:40] Connecting to a local LXD over a Unix socket
INFO[10-20|02:56:40] Sending request to LXD                   etag= method=GET url=http://unix.socket/1.0
DBUG[10-20|02:56:40] Detected stale unix socket, deleting
INFO[10-20|02:56:40] REST API daemon:
INFO[10-20|02:56:40]  - binding Unix socket                   socket=/var/lib/lxd/unix.socket
INFO[10-20|02:56:40] Pruning expired images
INFO[10-20|02:56:40] Updating images
INFO[10-20|02:56:40] Done pruning expired images
INFO[10-20|02:56:40] Done updating images

its still running - should it stop?

cancelling that previous comand (ctrl-c) locked up my console

^CINFO[10-20|03:00:31] Received 'interrupt signal', exiting.
INFO[10-20|03:00:31] Stopping REST API handler:
INFO[10-20|03:00:31]  - closing socket                        socket=/var/lib/lxd/unix.socket
INFO[10-20|03:00:31] Stopping /dev/lxd handler
INFO[10-20|03:00:31] Stopped /dev/lxd handler
INFO[10-20|03:00:31] Unmounting temporary filesystems
INFO[10-20|03:00:31] Done unmounting temporary filesystems
INFO[10-20|03:00:31] Closing the database
INFO[10-20|03:00:31] Saving simplestreams cache
INFO[10-20|03:00:31] Saved simplestreams cache

and it won’t accept input

restarting…

lxd bridge input yields:

root@test:~# /usr/lib/lxd/lxd-bridge start
Bad argument `'
Try `iptables -h' or 'iptables --help' for more information.
Failed to setup lxd-bridge.
modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/4.4.0-97-generic/modules.dep.bin'
modprobe: FATAL: Module ip_tables not found in directory /lib/modules/4.4.0-97-generic
iptables v1.6.0: can't initialize iptables table `filter': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/4.4.0-97-generic/modules.dep.bin'
modprobe: FATAL: Module ip_tables not found in directory /lib/modules/4.4.0-97-generic
iptables v1.6.0: can't initialize iptables table `filter': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/4.4.0-97-generic/modules.dep.bin'
modprobe: FATAL: Module ip_tables not found in directory /lib/modules/4.4.0-97-generic
iptables v1.6.0: can't initialize iptables table `filter': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/4.4.0-97-generic/modules.dep.bin'
modprobe: FATAL: Module ip_tables not found in directory /lib/modules/4.4.0-97-generic
iptables v1.6.0: can't initialize iptables table `filter': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/4.4.0-97-generic/modules.dep.bin'
modprobe: FATAL: Module ip_tables not found in directory /lib/modules/4.4.0-97-generic
iptables v1.6.0: can't initialize iptables table `filter': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/4.4.0-97-generic/modules.dep.bin'
modprobe: FATAL: Module ip_tables not found in directory /lib/modules/4.4.0-97-generic
iptables v1.6.0: can't initialize iptables table `mangle': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/4.4.0-97-generic/modules.dep.bin'
modprobe: FATAL: Module ip6_tables not found in directory /lib/modules/4.4.0-97-generic
ip6tables v1.6.0: can't initialize ip6tables table `filter': Table does not exist (do you need to insmod?)
Perhaps ip6tables or your kernel needs to be upgraded.
modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/4.4.0-97-generic/modules.dep.bin'
modprobe: FATAL: Module ip6_tables not found in directory /lib/modules/4.4.0-97-generic
ip6tables v1.6.0: can't initialize ip6tables table `filter': Table does not exist (do you need to insmod?)
Perhaps ip6tables or your kernel needs to be upgraded.
modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/4.4.0-97-generic/modules.dep.bin'
modprobe: FATAL: Module ip6_tables not found in directory /lib/modules/4.4.0-97-generic
ip6tables v1.6.0: can't initialize ip6tables table `filter': Table does not exist (do you need to insmod?)
Perhaps ip6tables or your kernel needs to be upgraded.
modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/4.4.0-97-generic/modules.dep.bin'
modprobe: FATAL: Module ip6_tables not found in directory /lib/modules/4.4.0-97-generic
ip6tables v1.6.0: can't initialize ip6tables table `filter': Table does not exist (do you need to insmod?)
Perhaps ip6tables or your kernel needs to be upgraded.
modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/4.4.0-97-generic/modules.dep.bin'
modprobe: FATAL: Module ip6_tables not found in directory /lib/modules/4.4.0-97-generic
ip6tables v1.6.0: can't initialize ip6tables table `filter': Table does not exist (do you need to insmod?)
Perhaps ip6tables or your kernel needs to be upgraded.
root@test:~#

hmm… ok i had this in mind to say but it got lost,

rather than type your command i did, and then got:

root@test:~# lxc stop test
Generating a client certificate. This may take a minute...
If this is your first time using LXD, you should also run: sudo lxd init
To start your first container, try: lxc launch ubuntu:16.04

LXD socket not found; is LXD installed and running?
root@test:~#```

thinking that I'd shut the container down, issue your change, and restart

what I had in mind was time based - the above errors that I originally linked as a result of `lxd init --auto` would also happen if I never did `lxd init` but waited many minutes and then did that sequence of `systemctl status` command...  the same would be true

Ok, so LXD itself works fine but it fails to start because lxd-bridge itself fails to start.

The reason appears to be that you’re missing the ip6_tables module and possibly some more.

lxc config set test linux.kernel_modules ip_tables,ip6_tables

Then try starting the lxd-bridge script again. The error message should at least change to reference the next set of missing modules.

You usually see such behavior if the network on the host is macvlan or bridged as in those case LXD on the host didn’t cause those modules to be loaded.

oops my above post got edited rather than replying :confused:

I am now trying that command

ok including my typo shame because it is late lol

LXD socket not found; is LXD installed and running?
root@test:~# lxc stop test
LXD socket not found; is LXD installed and running?
root@test:~# lxc info
LXD socket not found; is LXD installed and running?
root@test:~# exit
root@wyzsrv:~# lxc stop test
root@wyzsrv:~# lxc start test
root@wyzsrv:~# lxc exec test bash
root@test:~# exit
root@wyzsrv:~# lxc stop test
root@wyzsrv:~# lxc config set test linux.kernel_modules ip_tables,ip6_tables
root@wyzsrv:~# lxc start test
root@wyzsrv:~# lxc exec test bash
root@test:~# lxd init --auto
LXD has been successfully configured.
root@test:~#

success

ok like a rockstar (as usual) you found the root of it all xD… so now I assert my original test case that I’ve been using:

In 2.17 I could create that container, and then create a sub-container - no issues

in 2.18 why would I suddenly need to include lxc config set test linux.kernel_modules ip_tables,ip6_tables (regression point)

2.17 command sequence (with btrfs set up as default storage): (replication steps)

lxc launch ubuntu:lts test
lxc exec test bash
lxd init --auto```

The above continues to work with my .travis.yml, & vagrant...  it is only my 'sandbox' environment with BTRFS that fails.  The others use the 'DIR' provider

repo: (for ruby'ists): https://github.com/NexusSW/lxd-common

There is no change in LXD 2.18 that would explain this.

The normal reason for this behavior is that your system would in the past have auto-loaded those iptables modules and isn’t anymore. The auto-loading can happen for any number of reason, running something as simple as “iptables -L” will cause them to auto-load.

On most LXD systems these modules get auto-loaded because the user selects our default “lxdbr0” bridge which does have IPv4 and IPv6 firewalling on it, causing the modules to get loaded.

It’s only on cases where you don’t have LXD run a bridge for you AND your system never attempts to read any of the iptables tables that those modules won’t be loaded and will require that linux.kernel_modules config key to ensure that they’re loaded prior to the container starting up.

I’m having trouble finding the command to backtrack my host to 2.17 or I would have done that as a troubleshooting step

i can’t find it, but I swear there was something titled approximately ‘add btfrs as a block file system’ in the 2.18 release - that’s what had me on alert about this release

Yeah, but that’s quite unrelated. This changelog item is about allowing users to create btrfs formatted filesystems when using a LVM or Ceph storage pool.

I’m off to bed but tomorrow i’ll figure out how to backtrack my metal to 2.17, and initiate

lxc exec test bash
lxd init --auto```

it will succeed.  and if the metal is 2.18 the same will fail (If btrfs)

I’m honestly not sure it’s worth the trouble since we wouldn’t treat it as a regression anyway :slight_smile:

Unprivileged containers can’t load kernel modules so if you depend on some specific modules being loaded (as is the case with nested LXD), then those should be listed in linux.kernel_modules or you should otherwise be sure that something will have loaded those modules prior to the container starting.

I get it now! Something didn’t quite sink in last night (I have to quit working so late)…

I rebooted my host to get it clean and repeated the above steps with lxc launch ubuntu:lts test -c security.privileged=true -c security.nesting=true that my tests do and I usually forget when I’m typing by hand (like I did above)

same results. Now with my (limited) understanding of module loading in a container, I believe with it being privileged it ‘could’ have loaded those modules(?), if it had those modules in its own filesystem. But it doesn’t so that explains the ‘same results’

At any rate, weird… I really couldn’t tell you what was loading those modules in 2.17 because my host is very stock and the only thing I’ve set up to use on it, beyond the basic desktop (that I don’t use - I ssh in), is that raw bridge, md, lvm, btrfs, all in support of lxd. Perhaps something else that updated alongside lxd when I did apt-get upgrade used to load them.

Meanwhile, I’m loading those modules in my default profile now. Thank you again!!!