search

lavabit / robox

The tools needed to robotically create/configure/provision a large number of operating systems, for a variety of hypervisors, using packer.
620 stars 139 forks source link

generic/arch seems to have an invalid swap entry in `/etc/fstab` #250

Closed mrc0mmand closed 2 years ago

mrc0mmand commented 2 years ago

In the latest generic/arch box (v4.0.4) I noticed that the /etc/fstab is incorrectly generated (similarly to #152) - this time only the swap entry is affected, which is not UUID-ified:

v4.0.4

# cat /etc/fstab
# Static information about the filesystems.
# See fstab(5) for details.

# <file system> <dir> <type> <options> <dump> <pass>
# /dev/sda2
UUID=68c1501d-cb48-4758-8a55-b05644517d99   /           ext4        rw,relatime 0 1

# /dev/sda1
/dev/sda1               none        swap        defaults    0 0

#VAGRANT-BEGIN
# The contents below are automatically generated by Vagrant. Do not modify.
#VAGRANT-END

v4.0.0

# cat /etc/fstab
# Static information about the filesystems.
# See fstab(5) for details.

# <file system> <dir> <type> <options> <dump> <pass>
# /dev/sda2
UUID=3726d25c-ad4f-4bfb-b33c-e28a61a22175   /           ext4        rw,relatime 0 1

# /dev/sda1
UUID=fa9241bf-e73c-426e-a11f-1e1396c347d8   none        swap        defaults    0 0

#VAGRANT-BEGIN
# The contents below are automatically generated by Vagrant. Do not modify.
#VAGRANT-END

This results in a delayed boot, since systemd waits for /dev/sda1 to come up, but we're dealing with /dev/vda* here:

# lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
vda    254:0    0  128G  0 disk 
├─vda1 254:1    0    4G  0 part [SWAP]
└─vda2 254:2    0  124G  0 part /
[    4.880193] systemd-networkd[220]: eth0: DHCPv4 address 192.168.122.221/24, gateway 192.168.122.1 acquired from 192.168.122.1
[   91.463684] systemd[1]: dev-sda1.device: Job dev-sda1.device/start timed out.
[   91.464067] systemd[1]: Timed out waiting for device /dev/sda1.
[   91.464133] systemd[1]: Dependency failed for /dev/sda1.
[   91.464185] systemd[1]: Dependency failed for Swaps.
[   91.464229] systemd[1]: swap.target: Job swap.target/start failed with result 'dependency'.
[   91.464270] systemd[1]: dev-sda1.swap: Job dev-sda1.swap/start failed with result 'dependency'.
[   91.464314] systemd[1]: dev-sda1.device: Job dev-sda1.device/start failed with result 'timeout'.

Originally I though genfstab is at fault, but the version is the same in both boxes, and if I manually mount the swap in the v4.0.4 box, I get the expected result:

# swapon /dev/vda1
# genfstab -U /
# /dev/vda2
UUID=68c1501d-cb48-4758-8a55-b05644517d99   /           ext4        rw,relatime 0 1

# tracefs
tracefs                 /sys/kernel/tracing tracefs     rw,nosuid,nodev,noexec  0 0

# /dev/vda1
UUID=b6dca211-9765-4b74-a4f8-9b7d9273f3e6   none        swap        defaults    0 0
ladar commented 2 years ago

What platform host/hypervisor are you using? I wonder if the virtual disk type is changing between when the box is built, and when you run it. Possibly from virtio-scsi to virtio.

I'm going to see if I can run genfstab inside the chroot shell, and if that generates an fstab using the UUID instead.

mrc0mmand commented 2 years ago

What platform host/hypervisor are you using? I wonder if the virtual disk type is changing between when the box is built, and when you run it. Possibly from virtio-scsi to virtio.

Ah, apparently I forgot to include the most important info, my apologies. All my runs are using vagrant-libvirt on either Fedora 36 or CentOS Stream 8, using the default storage driver (which appears to be virtio):

virsh dump ```xml $ virsh dumpxml arch_default arch_default 292e6f23-89d6-4c79-9d6f-e25baadfd92f Source: /home/mrc0mmand/vagrant/arch/Vagrantfile 2097152 2097152 2 hvm destroy restart destroy /bin/qemu-system-x86_64

I'm going to see if I can run genfstab inside the chroot shell, and if that generates an fstab using the UUID instead.

ladar commented 2 years ago

I just tested the install logic, and it appears that genfstab is using UUIDs for the root and the swap partitions. I couldn't run genfstab from inside the chroot environment, but I did notice that a systemd unit was create for automatic fstab creation. It makes me wonder if the fstab that is being cretaed when the box is built, is being overwritten.

I also checked, and we're using virtio-scsi when building the box, but that gets set the storage driver is set to virtio by default, using the bundled Vagrantfile, since the virtio-scsi device type is a Red Hat specific thing.

Since you're on RH based distros, you could probably set disk_bus = "virtio-scsi" ... which would probably result in the disk being mapped to the sda node instead of the vda node. But that's cheating...

ladar commented 2 years ago

I tried running the arch box on a CentOS 7 sysstem, and everything appears to be good, although this was with the latest v4.1.0 box release.

# ./connect.sh generic arch libvirt
==> box: Loading metadata for box 'generic/arch'
    box: URL: https://vagrantcloud.com/generic/arch
==> box: Adding box 'generic/arch' (v4.1.0) for provider: libvirt
    box: Downloading: https://vagrantcloud.com/generic/boxes/arch/versions/4.1.0/providers/libvirt.box
    box: Calculating and comparing box checksum...
==> box: Successfully added box 'generic/arch' (v4.1.0) for 'libvirt'!
Bringing machine 'default' up with 'libvirt' provider...
==> default: Checking if box 'generic/arch' version '4.1.0' is up to date...
==> default: Uploading base box image as volume into Libvirt storage...
==> default: Creating image (snapshot of base box volume).
==> default: Creating domain with the following settings...
==> default:  -- Name:              generic-arch-libvirt_default
==> default:  -- Description:       Source: /home/ladar/robox/check/generic-arch-libvirt/Vagrantfile
==> default:  -- Domain type:       kvm
==> default:  -- Cpus:              2
==> default:  -- Feature:           acpi
==> default:  -- Feature:           apic
==> default:  -- Feature:           pae
==> default:  -- Clock offset:      utc
==> default:  -- Memory:            2048M
==> default:  -- Management MAC:    
==> default:  -- Loader:            
==> default:  -- Nvram:             
==> default:  -- Base box:          generic/arch
==> default:  -- Storage pool:      default
==> default:  -- Image(vda):        /var/lib/libvirt/images/generic-arch-libvirt_default.img, virtio, 128G
==> default:  -- Disk driver opts:  cache='default'
==> default:  -- Kernel:            
==> default:  -- Initrd:            
==> default:  -- Graphics Type:     vnc
==> default:  -- Graphics Port:     -1
==> default:  -- Graphics IP:       127.0.0.1
==> default:  -- Graphics Password: Not defined
==> default:  -- Video Type:        cirrus
==> default:  -- Video VRAM:        256
==> default:  -- Video 3D accel:    false
==> default:  -- Sound Type:    
==> default:  -- Keymap:            en-us
==> default:  -- TPM Backend:       passthrough
==> default:  -- TPM Path:          
==> default:  -- INPUT:             type=mouse, bus=ps2
==> default:  -- CHANNEL:             type=unix, mode=
==> default:  -- CHANNEL:             target_type=virtio, target_name=com.qemu.guest_agent.0
==> default: Creating shared folders metadata...
==> default: Starting domain.
==> default: Waiting for domain to get an IP address...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 192.168.121.139:22
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: 
    default: Vagrant insecure key detected. Vagrant will automatically replace
    default: this with a newly generated keypair for better security.
    default: 
    default: Inserting generated public key within guest...
    default: Removing insecure key from the guest if it's present...
    default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Machine booted and ready!
[vagrant@arch ~]$ cat /etc/fstab 
# Static information about the filesystems.
# See fstab(5) for details.

# <file system> <dir> <type> <options> <dump> <pass>
# /dev/sda2
UUID=c7b5eda0-d558-46d1-814f-2091ec78092b   /           ext4        rw,relatime 0 1

# /dev/sda1
UUID=2d9ecb93-4730-429b-978a-3e6aa33915ad   none        swap        defaults    0 0

#VAGRANT-BEGIN
# The contents below are automatically generated by Vagrant. Do not modify.
#VAGRANT-END
[vagrant@arch ~]$ swapon -v
NAME      TYPE      SIZE USED PRIO
/dev/vda1 partition   4G   0B   -2
mrc0mmand commented 2 years ago

I tried running the arch box on a CentOS 7 sysstem, and everything appears to be good, although this was with the latest v4.1.0 box release.

Interesting, with v4.1.0 I can confirm everything looks as it should:

$ vagrant up
Bringing machine 'default' up with 'libvirt' provider...
==> default: Checking if box 'generic/arch' version '4.1.0' is up to date...
==> default: Uploading base box image as volume into Libvirt storage...
==> default: Creating image (snapshot of base box volume).
==> default: Creating domain with the following settings...
==> default:  -- Name:              arch_default
==> default:  -- Description:       Source: /home/mrc0mmand/vagrant/arch/Vagrantfile
==> default:  -- Domain type:       kvm
==> default:  -- Cpus:              2
==> default:  -- Feature:           acpi
==> default:  -- Feature:           apic
==> default:  -- Feature:           pae
==> default:  -- Clock offset:      utc
==> default:  -- Memory:            2048M
==> default:  -- Management MAC:    
==> default:  -- Loader:            
==> default:  -- Nvram:             
==> default:  -- Base box:          generic/arch
==> default:  -- Storage pool:      default
==> default:  -- Image():     /home/mrc0mmand/.local/share/libvirt/images/arch_default.img, 128G
==> default:  -- Disk driver opts:  cache='default'
==> default:  -- Kernel:            
==> default:  -- Initrd:            
==> default:  -- Graphics Type:     vnc
==> default:  -- Graphics Port:     -1
==> default:  -- Graphics IP:       127.0.0.1
==> default:  -- Graphics Password: Not defined
==> default:  -- Video Type:        cirrus
==> default:  -- Video VRAM:        256
==> default:  -- Video 3D accel:    false
==> default:  -- Sound Type:    
==> default:  -- Keymap:            en-us
==> default:  -- TPM Backend:       passthrough
==> default:  -- TPM Path:          
==> default:  -- Disks:         vdb(raw,512M)
==> default:  -- Disk(vdb):     /home/mrc0mmand/.local/share/libvirt/images/arch_default-vdb.raw
==> default:  -- INPUT:             type=mouse, bus=ps2
==> default:  -- CHANNEL:             type=unix, mode=
==> default:  -- CHANNEL:             target_type=virtio, target_name=com.qemu.guest_agent.0
==> default:  -- RNG device model:  random
==> default: Creating shared folders metadata...
==> default: Starting domain.
==> default: Waiting for domain to get an IP address...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 192.168.122.120:22
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: 
    default: Vagrant insecure key detected. Vagrant will automatically replace
    default: this with a newly generated keypair for better security.
    default: 
    default: Inserting generated public key within guest...
    default: Removing insecure key from the guest if it's present...
    default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Machine booted and ready!
$ vagrant ssh
[vagrant@arch ~]$ cat /etc/fstab
# Static information about the filesystems.
# See fstab(5) for details.

# <file system> <dir> <type> <options> <dump> <pass>
# /dev/sda2
UUID=c7b5eda0-d558-46d1-814f-2091ec78092b   /           ext4        rw,relatime 0 1

# /dev/sda1
UUID=2d9ecb93-4730-429b-978a-3e6aa33915ad   none        swap        defaults    0 0

#VAGRANT-BEGIN
# The contents below are automatically generated by Vagrant. Do not modify.
#VAGRANT-END
[vagrant@arch ~]$

So I guess it was just some transient issue that sorted itself out. In any case, this issue can be safely closed, thanks :-)

ladar commented 2 years ago

There was a recent issue with the mirror list being moved from www.archlinux.org to archlinux.org and the script not accepting the redirect. That was causing problems wiith pacman, but its been fixed. So perhaps that was the culprit.