|Summary:||virt-customize cannot set random seed for fresh Debian 9 guests|
|Product:||[Community] Virtualization Tools||Reporter:||Richard W.M. Jones <rjones>|
|Component:||libguestfs||Assignee:||Richard W.M. Jones <rjones>|
|Status:||NEW ---||QA Contact:|
|Fixed In Version:||Doc Type:||If docs needed, set a value|
|Doc Text:||Story Points:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Richard W.M. Jones 2017-06-27 08:33:20 UTC
Description of problem: $ virt-sysprep -a debian-9 ... virt-sysprep: warning: random seed could not be set for this type of guest This is a newly created Debian 9 guest, so d-i has run but the guest has never been booted normally. Debian 9 uses systemd and systemd-random-seed.service. The service file contains: [Unit] ... RequiresMountsFor=/var/lib/systemd/random-seed which seems to indicate that this is the path where the random seed would be stored. However this path does not exist, and virt-customize works by assuming that the seed file exists before it will detect and overwrite the seed. I'm guessing this file would be created at first boot of the guest, which is too late. Version-Release number of selected component (if applicable): libguestfs-tools-c-1.37.14-3.fc27.x86_64 How reproducible: At least once. Steps to Reproduce: 1. Create a new guest using d-i. 2. Run virt-sysprep on it.
Comment 1 Peter Lawler 2019-02-05 22:54:07 UTC
Still happening in virt-sysprep 1.38.6 (on debian itself) Hopefully not too many server farms are relying on this to work as intended. Bit of a worry that there was no script failure when attempting this, as I'd argue that the user's intention is clearly to set the random seed and any failure to do so should generate a major error and stop the sysprep operation, not merely continue on as if this isn't a possible security problem.