Bug 1465323 - virt-customize cannot set random seed for fresh Debian 9 guests
Summary: virt-customize cannot set random seed for fresh Debian 9 guests
Keywords:
Status: NEW
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libguestfs
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Richard W.M. Jones
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-06-27 08:33 UTC by Richard W.M. Jones
Modified: 2019-02-05 22:54 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.