I followed your instructions of 4/21 regarding changing kernel parameters and attaching PuTTY etc. Screenshot of the edited parameters is next to your email attached (if attachment won't get published, I will post online). I can send the PuTTY output, but I don't think we learned anything we didn't already see in dmesg. Console login prompt comes up quickly, then the long delay in the Hyper-V Connection window before arriving at the Xorg GUI login. Alt-SysRq-w during this time gives nothing, just two lines like these:
[ 70.428525] sysrq: Show Blocked State [ 70.429990] task PC stack pid father While doing this, I noticed today that some previously reliable ways to get to the "shortcut boot" (the XRDP login screen, which comes up quickly, instead of waiting for the Xorg screen) were no longer reliable (e.g., sometimes "power off" force in Hyper-V Manager and restart led to a long boot). I also discovered a state in which starting the VM from an "off" state in Hyper-V Manager apparently skipped even the Grub screen and went quickly to XRDP login screen. At this point I rebooted the host. Some deep kind of Windows caching going on? After reboot, behaviors earlier described became predictable again. Three questions: 1) You wrote on 4/22 (second mail): "I also tried xrdp mode and the VM booted up to the xrdp login window in 14 seconds, which is faster than the "native Xorg GUI mode" (which needs 30s)". How did you intentionally "try XRDP mode"? How do you have any control over whether you get the XRDP or Xorg login screen? It seems to me I do not have any control. >From a user's perspective, that is the whole problem here, how to get the XRDP login screen on first startup (and all subsequent) of a 19.10 VM within a given Hyper-V Connection window. As shown earlier, when the user gets the XRDP login, the (presumably) same processes are still being delayed for the same length of time as when the user is forced to wait for the Xorg login screen, but the user has meanwhile been able to log in via XRDP and begin doing his or her work. Furthermore, screen size control and cut-and-paste from guest to host are available only with the XRDP login. From user's perspective, I think the problem is solved once user can log into the VM and start working without waiting for a 90s timeout, and screen size control and cut-paste are operational. Which in my case seems to be equivalent to being able to get the XRDP login screen reliably; if I get it, it always arrives quickly. 2) You wrote on 4/21: "It looks systemd can be configured to use "--log-level=debug --default- standard-output=kmsg --default-standard- error=kmsg". Please advise me how to do this. I administered Debian systems from Buzz (1996) to Squeeze (2011), and a lot of the boot process is new to me. (In those days, one had to use Ctrl-S / Ctrl-Q to be able to read booting output.) 3) You wrote on 4/22: "I'm wondering if you can disable setvtrgb.service, system-getty.slice, systemd-update-utmp- runlevel.service, and plymouth-quit-wait.service, and see if the long delay will disappear. I guess these 4 services don't look critical to the GUI desktop." Likewise, please advise me *how* to disable them. I've been trying unsuccessfully to disable Ubuntu automatic updates (in another VM, not the one I am testing) and have concluded that I really do not understand any of this newfangled .service stuff. (And I shouldn't have to, to achieve that objective, but that is a different gripe.) ** Attachment added: "kernel_parameters.PNG" https://bugs.launchpad.net/bugs/1848534/+attachment/5359626/+files/kernel_parameters.PNG -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gdm3 in Ubuntu. https://bugs.launchpad.net/bugs/1848534 Title: [Microsoft Hyper-V guest] System shows graphic artifacts for a moment, then text cursor for about minute and then starts To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1848534/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
