Using delete or backspace on keyboard like if we typing a words.
It did not help, same thing, boot stuck
Here my last idea, rebuild your initramfs from live cd. Btw thank you to stick with me.
Since I believe hyper-v not able to boot with live usb, you could use fedora mate 35 spin iso mounted to your virtual CD here.
Then change the arrangement of your boot list on hiper-v. Should be on the same panel on the BIOS menu. Make the virtual CD room as your first boot.
Boot to live cd and then chroot your installed Fedora Mate Fedora Docs - chroot LVM.
If you’re success to chroot, then run bellow command to backup your current initramfs:
mv /boot/initramfs-5.15.6-200.fc35.x86_64.img /boot/initramfs-5.15.6-200.fc35.x86_64.img.backup
Then build new intiramfs:
dracut /boot/initramfs-5.15.6-200.fc35.x86_64.img 5.15.6-200.fc35.x86_64 --force
Then type exit enter. Try to boot again normally (change back the boot order).
@oprizal , I followed your 1st instructions, downloaded the f35 mate spin, rebooted with it, chose
start Fedora Mate_compiz-live 35
I got the exact same behavior
If you failed to boot the live cd it’s means nothing we can do. Something on your virtual machine no longer work with current version of Fedora.
Maybe you could backup your data inside your vm and make new configuration of your VM then make fresh installation.
Update:
Here I found YouTube video on how to setup Fedora 33 in hyper-v. Fedora 33 should be have same config with Fedora 35 because it’s only 2 version left behind here.
First of all, I booted on the f35 spin as I showed in the napshot
2nd, I have those 2 VMs since 10 years on hyper-V, migrated from F20 up to 31 over the years and worked fine. It is last week when I followed instructions on fedora docs to upgrade to F32, then 33, then 34 then 35 which I did and in all cases I was able to RDP but boot gets stuck
If there is no solution, I think I will revert back to F31 as I have a full VM backup for one of them. and see what will happen. What do you think? If you are ok, let me know and will start the restore in Hyper-V and would like your recommandation on how to proceed to upgrade
I restored the VM before upgrading which had F31, as you can notice in the snapshots, boot finished without any issue . Of course I used 1st line to boot
Could you boot to Fedora 31 and check the lsbk -apf?
Login and I want to know your partition layout. On terminal run lsblk -apf
Once more, lscpu and free -h.
Update:
I have 10 years old laptop with Debian installed that I want to replace it with Fedora. So I install it with Fedora Spin Mate 31 from Fedora Project ISO archive with default setup and upgrade it to Fedora 35 to at least replicate some of the cases you have.
Below are much what I did with some modification that maybe needed by your system.
Notice there are lot of dnf clean all to clean unnecessary cache of metadata and dowloaded packages leftover from each time after succesfully upgrading the system and possibly making your system failed to boot.
I run on BIOS legacy (1st generation BIOS).
Minimum system for Fedora 35 (our final upgrade target), 2GHz, 2 core cpu, 2GB ram, 20GB disk.
On 31
# Backup your data. I always said backup your data (not snapshot of your virtual machine state) because if the upgrade always fail, you could create new Hiper-V setup with current technology (let say BIOS generation 2, new secure boot CA) with latest system requirements needed by latest Fedora Project release then install directly latest Fedora Linux version and create again whatever setup you need to run in your server. Of course you need to test it first on newly created Hiper-V setup before migrating.
# On "System > Control Center > Power Management" making sure setting related to sleep and hibernate are inactive.
# Disable third party repos (if you added this manually before or by installing third party packages) that's not from Fedora project. Please refer to Fedora docs on how to do this.
# making sure all basic tasks related to kernel working properly
systemctl suspend
systemctl reboot
systemctl poweroff
sudo dnf clean all
sudo dnf module reset libgit2 exa bat #<--- I'm forget where this comes. But it's related to bugs on Fedora 31 with distro-sync.
sudo dnf distro-sync
systemctl reboot #<--- In case there some upgrade that need to reboot (example: driver) also need to booting to newer kernel.
sudo dnf clean all
# making sure all basic tasks related to newer installed kernel from upgrade working properly
systemctl suspend
systemctl reboot
systemctl poweroff
sudo dnf repoquery --unsatisfied #<--- should be empty, if not remove pakages listed
sudo dnf install rpmconf
sudo rpmconf -a #<--- Always pick I or Y
sudo rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-33-x86_64 #<--- not necessary since only skipping 1 version, but just in case
sudo dnf install dnf-plugin-system-upgrade
sudo dnf system-upgrade download --releasever=33
sudo dnf system-upgrade reboot
Then login to Fedora 33 with latest kernel version installed
On 33
# On "System > Control Center > Power Management" making sure setting related to sleep and hibernate are inactive.
# making sure all basic tasks related to kernel working properly
systemctl suspend
systemctl reboot
systemctl poweroff
cat /etc/os-release #<--- Making sure on Fedora 33
sudo dnf clean all
sudo dnf repoquery --unsatisfied #<--- should be empty, if not remove pakages listed
sudo rpmconf -a #<--- Always pick I or Y
sudo dnf distro-sync #<--- most likely it will not overing new upgrade since we should be on the latest version before Fedora 33 become EOL
systemctl reboot #<--- In case there some upgrade that need to reboot (example: driver) also need boot to newer kernel. Skip this if distro-sync didn't offering any new packages.
sudo dnf clean all
sudo rpmconf -a #<--- Always pick I or Y
sudo rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-35-x86_64 #<--- not necessary since only skipping 1 version, but just in case
sudo dnf system-upgrade download --releasever=35
sudo dnf system-upgrade reboot
Then login to Fedora 35 with latest kernel version installed
On 35
# On "System > Control Center > Power Management" making sure setting related to sleep and hibernate are inactive.
# making sure all basic tasks related to kernel working properly
systemctl suspend
systemctl reboot
systemctl poweroff
sudo dnf clean all
sudo dnf repoquery --unsatisfied #<--- should be empty, if not remove pakages listed
sudo rpmconf -a #<--- Always pick I or Y
# Enable again third party repos that's not from Fedora project. Please refer to Fedora docs on how to do this.
sudo dnf upgrade --refresh
systemctl reboot #<--- In case there some upgrade that need to reboot (example: driver) also need boot to newer kernel.
sudo dnf clean all
# If there any third party repos that modify your kernel, this for making sure all basic tasks related to kernel working properly.
systemctl suspend
systemctl reboot
systemctl poweroff
Since I modify the dnf.conf I was able to preserve the kernel installed on my system. Here the picture of all my boot list (kernel version).
output lscpu (This forum did not allow me to respond saying that I need to wait for 8 hours, this mornining I was able to reply but it does not allow me to put the 2nd snapshot and it says that I need to wait for 3 hours agai, this is the 1st time I see htis in a community forum)
output free -h
> total used free shared buff/cache available
Mem: 3.8Gi 2.0Gi 266Mi 52Mi 1.5Gi 1.5Gi
Swap: 3.9Gi 149Mi 3.8Gi
1 Like
@oprizal I followed your instruction to upgrade F31 > F33, after upgrade finished, it booted on the 31 kernel (the 2nd in the list at boot as 33 was 1st) and boot process went through and I was able to login.
I rebooted and chose F33 in the boot list, I got the exact same behavior , boot process got stuck again at “Started Notify NFS peers of a restart”.
Also, while booting there is one service that fails as you can notice in the snapshot
Hardware Monitoring Sensors
1 Like
I don’t know if this related with your problem. From your lscpu you only allocate 1 core CPU. Fedora 35 need 2 cores.
Update:
Also with Fedora 33 need 2 core CPU. Fedora 33 docs.
I assigned 2 CPUs to the VM, rebooted, still boot getting stuck
Try rebooting to 31, then check the network connections using ‘ip a’
For my network connections I normally use bridged with the host virbr0 bridge.
Also, check the memory allocation. I normally give a VM 2 CPUs & 4096 memory.
My VM has now the exact same config as yours, 2 CPUs and 4096 RAM.
The difference is it is on Hyper-V, there is no concept of bridged network as VMware or virtualbox, 3 options exist in Hyper-V virtual switches concept (the VM is connected to an external virtual switch so it can connect to internet)
Here is the output of “ip a”
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:15:5d:01:1d:06 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.48/24 brd 192.168.1.255 scope global dynamic noprefixroute eth0
valid_lft 82431sec preferred_lft 82431sec
inet6 2a01:e0a:322:14d1:d1c3:b701:97d3:29a6/64 scope global dynamic noprefixroute
valid_lft 2591881sec preferred_lft 604681sec
inet6 fe80::205d:9b78:ed18:de8e/64 scope link noprefixroute
valid_lft forever preferred_lft forever
3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
link/ether 52:54:00:93:02:2b brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
valid_lft forever preferred_lft forever
4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master
virbr0 state DOWN group default qlen 1000
link/ether 52:54:00:93:02:2b brd ff:ff:ff:ff:ff:ff
5: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:4f:02:16:94 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
Since I have never used Hyper-V I have no experience there. I use QEMU/KVM for almost everything. I have tried VirtualBox but do not use it regularly.
You said, I believe, that you can access the VM when it hangs at that point, which seems to imply that it is up but something on the user interface may be an issue.
Is it possible when you remotely access it for you to get the output of `dmesg’ and ‘journalctl -b’ so you can see exactly what is happening behind the screen. If you can do so then please post those so we can see if there are any messages pointing the direction to look.