similar to: virt-v2v - Window firstboot service questions

On Thu, Jul 23, 2020 at 12:28:17PM +0300, Sam Eiderman wrote: > Hi, > > It seems that on Windows we create the following dir: > > /Program Files/Guestfs/Firstboot/ > > Where '/' is the os volume (where /Windows reside) > > Is it possible that Program Files is not actually located on the os volume? > (i.e. C:\Windows, D:\Program Files on original vm)

By creating an empty disk and using it as the first disk of the vm (i.e. /dev/sda, /dev/sdb{1,2} contains the windows fses) we change the iteration order of the disks. This causes inspect_os() to fail since Parted returns a Unix_error if the device does not contain any partitions - fix this by handling this Unix_error. Signed-off-by: Sam Eiderman <sameid@google.com> ---

Yea, I noticed that commit, but since it was used in gpt too regardless of that commit, I decided not to mention this regression. I also noticed that list_filesystems() still works, this is probably due to filtering of devices (daemon/listfs.ml): "let devices = List.filter is_not_partitioned_device devices in" What do you have in mind here? On Tue, Jun 30, 2020 at 12:33 PM Pino

Although not fatal, _unconfigure_xenpv should report a warning and return if firstboot is not available (during Windows conversions). --- lib/Sys/VirtConvert/Converter/Windows.pm | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/lib/Sys/VirtConvert/Converter/Windows.pm b/lib/Sys/VirtConvert/Converter/Windows.pm index 59d273f..ce8b474 100644 --- a/lib/Sys/VirtConvert/Converter/Windows.pm

Hello, We have a nodejs app which is injecting first boot scripts using virt-customize however the exact same commands are working when triggered manually. Here is the debug output of the commands Regards, Peter [ 0.0] Examining the guest ... libguestfs: trace: set_network true libguestfs: trace: set_network = 0 libguestfs: trace: add_drive

A very miscellaneous set of cleanups to how we handle the Windows registry in virt-v2v, firstboot, and inspection code. This should all be straightforward non-controversial refactoring. Some highlights: - Add a new mllib Registry module containing various utility functions that are currently scattered all around. - Only compute the software/system hive paths once during inspection, and

On Thu, Nov 21, 2019 at 12:04:18PM +0100, Tomáš Golembiovský wrote: > Instead of running firstboot scripts during early boot schedule a task > delayed for 1-2 minute. > > During the first boot, after virt-v2v conversion, Windows installs the > drivers injected by virit-v2v. When this installation is finished > Windows enforces some kind of internal reboot. This unfortunately

I am running libguestfs version 1.34.2 The issue is the following. When I start the vm with virt-log I see this: Mar 13 17:33:30 multi6 firstboot.sh[358]: /usr/lib/virt-sysprep/firstboot.sh start Mar 13 17:33:30 multi6 cron[359]: (CRON) INFO (Running @reboot jobs) Mar 13 17:33:30 multi6 firstboot.sh[358]: Scripts dir: /usr/lib/virt-sysprep/scripts Mar 13 17:33:30 multi6 firstboot.sh[358]: ===

When firstboot is used from virt-v2v the scripts, if not fast enough, can get killed by Windows. After windows installs virtio drivers injected by virt-v2v it performs some internall reboot, stopping all the running services and killing any running firstboot script. This is problem mostly for MSI installs (like qemu-ga that was added recently) that can take several seconds to finish. This change

Currently we install a systemd service named firstboot.service and a SysV service named virt-sysprep-firstboot. On systems where systemd is the init system and runs with the SysV compatibility, the different names make systemd handle them as different services, and thus trying to run the firstboot script runner twice. Rename the systemd service to virt-sysprep-firstboot as well: other than being

> > I have really no clue about this. > > > > What is "~dpnx0"? > > I wanted to documented that in a comment at first. But then I decided > against that as it seemed that as it seemed such patterns are used in > multiple places in the code (ergo everyone knows). > > Looking now I see two occurrence in convert_windows.ml and one in >

If a script does not finish, hangs, etc, it would be executed again at the next boot, since the injected firstboot.sh helper removes it only after it finished. Since firstboot.sh only runs executable files, then remove the executable attributes before running it, so it will not run again. Also, remove any file found in the scripts subdirectory, be it just run or run in a previous boot. This

I have only verified the fix on Debian 7. The Debian 6 guest doesn't appear to boot, I'm not sure why. The second patch contains a test suite. Rich.

I am running the stock libguestfs on latest Ubuntu 16.04 (1:1.32.2-4ubuntu2). My guests are also Ubuntu 16.04. I am running virt-sysprep with --firstboot-command 'dpkg-reconfigure openssh-server'. This works 90% of the time, but occasionally when a new guest first starts it can't find the script: ~# cat virt-sysprep-firstboot.log /etc/init.d/virt-sysprep-firstboot start Scripts

On Wednesday, 3 August 2016 16:39:46 CEST Richard W.M. Jones wrote: > On Wed, Aug 03, 2016 at 05:35:14PM +0200, Pino Toscano wrote: > > Currently we install a systemd service named firstboot.service and a > > SysV service named virt-sysprep-firstboot. On systems where systemd is > > the init system and runs with the SysV compatibility, the different > > names make

What's the best way around "firstboot" ? "firstboot" hung my machine and had to blown it up to get past it. If you bypass firstboot, what other config settings is one missing? I found the following info.... ==================================================================== # Booting without Internet Connection / Stuck on RedHat Registration during First Bootup This

If a script does not finish, hangs, etc, it would be executed again at the next boot, since the injected firstboot.sh helper removes it only after it finished. Before executing a script, move it to another internal subdirectory (scripts-done) and execute it from there, so it is not run again by firstboot.sh. The downside is that now scripts are executed only once at all, so if a script fails it

Pass -a to each tee invocation, otherwise just the last one (so only for the last script executed) will appear in the log file. --- customize/firstboot.ml | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/customize/firstboot.ml b/customize/firstboot.ml index 89821f3..0b95708 100644 --- a/customize/firstboot.ml +++ b/customize/firstboot.ml @@ -50,8 +50,8 @@ d=%s/scripts

Dear Experts, Sorry about taking shortcut and asking everybody... My question is: how do you avoid "firstboot" screen in latest CentOS 7.3 kickstart. I have installed about a dozen of CentOS 7 (none of which was 7.3) with that kickstart file. None of them ever went to firstboot screen on first boot. Now after kickstart installation of CentOS 7.3 it goes into firstboot screen showing

On Fri, Oct 07, 2016 at 04:42:21PM -0400, Charlie Drage wrote: > I apologize if this is not the appropriate place to contact you.. Adding the mailing list. > Got a weird issue! > > So when I use --firstboot via virt-sysprep on a host, it's totally fine. > > However.. > > In this scenario: > 1. virt-sysprep an offline image > 2. transfer said image from one