Hyper-V on Windows Server 2019
ipfire-2.23.x86_64-full-core139.iso
Second generation Virtual Maschine with Secure Boot diabled
On the initial screen (GRUB) I can use the keyboard but after selecting “Install IPFire 2.23 x86_64” on the Language selection screen no input is possible. This also affects sending the ctrl-alt-del from Hyper-V:
[Window Title]
Virtual Machine Connection
[Main Instruction]
Could not send keys to the virtual machine.
[Content]
Interacting with the virtual machine’s keyboard device failed.
The operation cannot be performed while the object is in its current state.
Hi there IPFire community,
I tried x86_64 on Core 151 Hyper-v 2016 Gen 2 VM no secure boot and i’m also stuck on langage selection with no keyboard.
I also have to mention that i586 Core 148 still support multiple virtual cpu as Core 149 does not boot with 2 CPU - error: “CPU 1 not responding for 23s”
It’s booting with 1 CPU.
Does anyone has positive experiences on x86_64 Gen 2 VM or i586 multiple CPU post Core 148 with hyper-v
I have been trying to repeatedly get access to one of the affected Hyper-V hosts. I do not have access to one myself except Azure and therefore nobody of the team could ever reproduce this and test this.
You should not use a 32 bit installation in a virtual environment. What is your reason to try that?
Hi Michael,
Thanks for your reply and warm welcome.
I’ve been using the i586 architecture on hyper-v for a few years, on 1 Server 2012 R2 (cluster 2 nodes) and 3 Server 2016 hyper-v. IPFIRE vm are Gen 1 with a Vhdx. I’m in Core 144 working very fine, we love the product.
I thought i586 Gen 1 VM was the only architecture that was working on hyper-v for now.
May be i’m wrong ?
I gave it a try on x86_64 Gen 2 VM a few times with different Cores and i recently found that Secure Boot has to be diabled so i tried on Server 2016 recently and booting was fine but i had this same keyboard issue on Langage selection.
I can confirm i586 Gen 1 VM has CPU problem Past Core 148, we are working fine with Core 144 2 CPU 4Go RAM 3 Network Cards but last Pakfire to 151 made a crash after reboot. I restored the previous Core 144 and analyse that the 2 CPU configuration had problems on boot on Core 151. I tested all the i586 ISO from 151 to 148 to find that Core 148 was the last to work fine on i586 Gen1 VM 2 CPU.
I will try to install x86_64 Core 151 Gen 1 VM from ISO, i tried by the past but had installation problems. I could try Core 152 but i don’t know if i have access to the ISO on the blog.
I can help testing IPFIRE on hyper-v even though i’m not a Linux specialist.
Thanks and great job for IPFIRE.
Hi Michael,
Some more testing on Hyper-v 2016 on-premise. I successfully installed x86_64 Core 144 Gen 1 VM 2 CPU 4Mo RAM from ISO. I backup and restore my i586 Core 144 config on the x86_64 Core 144. I used the scripts : https://wiki.ipfire.org/installation/arch-change to fix the Graphs problem. Then i used Pakfire to update to Core 151 with success. The only problem i have is i’m stuck at boot for 7mn Fresh installation stuck 8 minutes at boot. Even though i let the system boot, it is always stuck at “Setting up Pakfire Package Manager…” Core 144 had the same problem at boot. I saw you filed a Bugzilla post on this: https://bugzilla.ipfire.org/show_bug.cgi?id=12445 but i don’t know it Core 151 is supposed to have this fixed or not ? So i can confirm x86_64 Core 151 Gen 1 VM works fine with hyper-v 2016 / Gen 2 not for now (Frozen install at “Language selection”)
My IPFire installation (x64) is running on an Server 2016 Gen 1 whout EFI and Secure Boot. Works fine!
From my experience, this can also be helpful for other admins reading this: Don’t change your virtual CPUs after the installation of an Client OS. No matter if Linux or Windows. It s h o u l d work theoretically but I encountered a lot of problems the last 10 years I’m working with Hyper-V. So just don’t do it and you’ll be fine.
Hi Tom,
Thanks for your answer and good to know there is a few crazy people running IPFire on Hyper-v.
Is the patch downloadable by any way or do i have to manually change the /src/initscripts/helper/azure-setup as mentioned ?
Thanks for the tips and return of experience on x64 on hyper-v 2016.
I’m trying to build my VM with all parameters ready at start: 2 CPU, 4096RAM, 3 Network Cards and stay with that.
My Tip : use static Mac Address on the Advanced properties of each Network Cards of the VM
Green …01, Orange …02, Red, …03
It is very important if you use Cluster configuration as Mac Adresses are different on each node.
Thanks again for your feed back.
Cheers from Tahiti
JiM
the content of the Mailinglist if a diff. Copy it into a file (e.g. /root/hyperv.patch) and then patch the azure-setup script with patch /etc/rc.d/helper/azure-setup /root/hyperv.patch
Hi Guys,
I also tried Gen 2 HyperV VM with last ISOs
Core 153 ISO NOK
Core 154 ISO OK installing great no KBD issue, rebooting fine.
I restored my settings on it and it seems to work fine.
I’m testing this Gen2 VM in our lab. I will let you know if it is stable…
Greetings
JiM
Long followup reply here but I wanted to point out an issue I am seeing on HyperV now. The install is working with an interactive keyboard now. However, on reboots (such as after a patch or other maintenance) the firewall is getting stuck at the prompt “setting up Pakfire Package Manager”.
I have to manually connect to the VM console and press CTRL +C, after this the boot process completes and the firewall functions normally. If I do not do this manual process, the firewall stays stuck and will not complete bootup.
EDIT: I also want to mention, this is happening on the current Core155 release. I updated it today and it was stuck booting up per the attached screenshot.
Reason:
A lot of Core Developers read in this community somehow irregular (although there are some very busy readers like Peter Mueller). This has nothing to do with ignorance just with a lake of time. We cannot monitor a handful of platforms for important information and so important information like the one which you posted here gets somehow lost.
Therefore please post this information in a bug report, that it gets recognized.
Hi Fire Well,
I had this before Core 154, on Core 154 i had to wait around 1mn on “setting up Pakfire Package Manager” or press CTRL+C on console.
It has to do with detection of MS Azure, see:
I just had a look at the bug and checked the patch status. I found that due to the incorrect subject line the patch was not automatically put into the IPFire Patchwork system. The patch can only be seen in the development mailing list.
Any action on a patch such as it being tested and/or being staged into the next build is done via Patchwork. Therefore nothing has happened with this patch.
@tomtom94 needs to resubmit the patch with the subject line split into subject and commit message. The patch will have looked like it had a very long subject line and no commit message.
I think that the system is looking at emails going to the development list and any that have the word PATCH in the subject line and then a commit message followed by the Signed-off-by: git tag will be automatically picked up and also put into Patchwork.
Michael had the idea to change the timeout/tries values. So I updated the patch again.
I’ll also post the new Patchwork link https://patchwork.ipfire.org/patch/4089/ in the Bug ticket.
