Not sure whether this is a known issue (perhaps something I should have just “known” as a Linux server admin), but figured I’d share in case someone else runs into the same issue.
I copied a live system (VMware VM in this case) via lxd-p2c like so:
and ended up with a container which has the contents of ‘/’ and ‘/boot’. That part worked.
However, the /etc/fstab file in the newly generated container still has the mount points from the old system. At boot time, the entry within the /etc/fstab time in the container were enough to cause the network configuration to not be applied as expected. Once I commented out the entries within the /etc/fstab file and restarted the container, the system was able to pull an IP Address via DHCP as intended.
On a related note:
After very brief testing, I was able to have the container start without issue without a /etc/fstab file present. Is that file even needed within a LXD container? I assume it is, but very quick testing appears to indicate otherwise. Would an empty /etc/fstab file cause any issues?
lxd-p2c doesn’t perform any modification to the container’s content as such modifications would be very distribution and environment specific.
It’s indeed up to the user to perform the few post-migration steps that may be required.
In some cases it’s updating network configuration files, in some other, cleaning up no longer relevant /etc/fstab entries, sometimes it involves disabling some services, …
Your distribution in the container still does use /etc/fstab, though LXD does pre-mount /, /proc and /sys, so if that’s all you have in there, it’s indeed not actually used.
Understood. Thanks for explicitly noting those details. On a related note, is there a separate docs page for lxd-p2c? This seems like great material to include in such a page.
Ah, OK that makes sense. Is that configurable from a property somewhere in a profile or on the container itself? Just curious.