@paddylandau, I think you should give bridged networking a go. That way there is no NAT (network address translation) involved and you can use the advertised IP directly. In fact, Ubuntu Core will get its IP address from your local DHCP server, just like your host machine and other devices on your network. If nothing else, that’s the closest estimate of what a bare metal server would look like to your network environment.
For a VM you don’t actually have to write the image to a disk device. I haven’t; I simply told virt-manager to use the .img as the storage device. If you want to emulate how to do it on a server, you can set up a VM with internal storage, then run an Ubuntu Desktop live session and do the dd from there.
Say your VM has a disk device at /dev/sda, then you just do:
That was an improvement. I followed your instructions to dd the image onto a local disk (it took a bit of figuring out how to do it, because VirtualBox couldn’t directly load the .img file).
Anyway, the result is that after booting the machine, it runs through through the usual console messages, restarts, and repeats. It’s in an infinite loop.
Are you sure it’s an infinite loop? Might just be the magic happening. With a clean TPM 2.0 and secure boot enabled, it took some additional reboot(s) (I didn’t count them). When it says “Press Enter to configure” (or similar) and you press Enter, it will probably come back with saying something like “Kernel is updating”, the next time around it will say a reboot is pending. I guess that’s required for the TPM-backed FDE setup. Eventually you should get to the point where you supply your email address, though. It is a bit counterintuitive, I’ll give you that.
Nah, I think those are just issues one encounters with VM’s. You could also just sudo dd if=/path/to/ubuntu-core-26-amd64.img of=/dev/disk/by-id/usb-<stick>[1] on the host machine and boot your home server from that USB stick; perhaps unplug any internal storage, just to be safe.
You should actually see it doing the partitioning and installing on the very first boot, then it should reboot and greet you with a setup tool where you first configure the network and after this a screen where you type in your users email address …
In a VM you can just hit enter and have it use all the defaults for the network and once you gave it your email it will pull down the ssh key from login.ubuntu.com and create a user with this key for you … once it is done you will not see any login prompt but the ssh fingerprints for the machine. If this is visible you should be able to ssh in…
That part didn’t really happen for me. After seeing the fast-ish scrolling text boot messages (plymouth-text?), I was greeted with the “Press Enter to configure”; pressing Enter at that point seemed to do nothing at first and after a short delay it said pc-kernel and (not sure) core26 were updating. Then there was “Press Enter to configure” again; this time it replied with reboot pending. After the reboot, pressing Enter did drop me in the config dialog you described.
But there wasn’t really a stage in which it showed some sort of “doing this” progress indicator, unless you count the Plymouth text. I did spot a TPM/FDE refusal message by sheer accident, because it scrolled past rather quickly; I had tried to reuse my other Ubuntu Desktop TPM/FDE VM, which already had a key in the TPM, so that’s how I knew to spin up a new VM.
While it’s not a big issue for me, it’s adding more hurdles for the uninitiated.
I had wanted to address this sooner but forgot. That’s what I meant by “bolting the front to door shut while the bathroom window is ajar”.
I believe you could look into sealing the full kernel command line; any change then results in the wrong measurement and failover to requesting the recovery key for decryption.
There is a storage layout called “hybrid” with optional encryption. If you use this layout, it should be exactly what you’re looking for.
If I understand correctly, this is exactly what the desktop installer is doing under the hood anyway.
Here is the relevant section:
Additionally, TPM-backed encryption can be enabled by using the hybrid layout with encrypted set to yes.
autoinstall:
storage:
layout:
name: hybrid
encrypted: yes
It very definitely looked like it. It was repeating the same thing over and over. I left it running for a while.
VirtualBox virtual disks are stored in a .vdi format, and this wouldn’t work. It has to be done within the VM, which I did do successfully.
Unfortunately, it didn’t happen, but fortunately, the factory-level reset did work. Although, as noted, I couldn’t proceed.
Today, when I started it up again, it returned to an infinite loop!
I have deleted the VM altogether, and I’ll start afresh.
Thank you for the details. This is probably what was missing in my knowledge base. I’ll try it when I redo the VM.
Thank you. This is an area that I haven’t learned, and it looks like quite a bit of learning for someone like me. At this stage, I wouldn’t even know where to start configuring this.
Hmm, it looks like the TPM stuff didn’t work at all in that screenshot, not sure if that’s a VirtualBox thing, I don’t see this happening in my qemu/kvm VMs …
That screenshot shows pretty much the same problem I’m having right now with my TPM/FDE Desktop VM, which I brought on myself by messing with the TPM, so it looks like you were trying to use a pre-owned TPM.
This thread seems to describe the problem I’m having but there seems to be no solution other than wiping the TPM and then reinstalling from scratch, which you seem to have done in the meantime.
No, definitely not. I had deleted the old VM, and created a brand new one, which means that the virtual TPM was fresh. VirtualBox doesn’t share the TPM between each VM; each one is unique and independent.
