RE: [Bug 1848534] Re: [Microsoft Hyper-V guest] System shows graphic artifacts for a moment, then text cursor for about minute and then starts
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] taskPC 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
[Bug 1848534] Re: [Microsoft Hyper-V guest] System shows graphic artifacts for a moment, then text cursor for about minute and then starts
To clarify, I say the purple login screen is "more native" because that's what I get on the monitor of a physically independent machine (not a VM) running Ubunutu; naturally I do not get an (X)RDP screen on that machine ever. -- 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
[Bug 1848534] Re: [Microsoft Hyper-V guest] System shows graphic artifacts for a moment, then text cursor for about minute and then starts
You missed that I did include the output of 'systemctl list-jobs' during the crucial interval of delay. I will follow your instructions regarding boot parameters etc. and post results asap. I expect there is an enormous difference between accessing the VM via RPD (XRDP) protocol and accessing the VM via the more native interface (purple screen) which is eventually available on 19.10, even though both are accessed through the Hyper-V "Connection" interface. XRDP seems like the preferred way, it's the only way I get to 18.04, and forcing it on 19.10 is the only way I get screen size control and cut-and-paste from guest to host. Am seeking confirmation of what is the correct/preferred behavior is with 19.10. Should I be getting the "native" purple login screen quickly and then have cut-paste and screen control, or should be getting the XRDP interface quickly, just like I do with 18.04? -- 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
[Bug 1848534] Re: [Microsoft Hyper-V guest] System shows graphic artifacts for a moment, then text cursor for about minute and then starts
Now we are getting somewhere. X windows system implicated. Though the 2d video shows how fast the shortcut boot is, I thought I should get a firm number so I did the shortcut boot and logged in to get output of 'systemd-analyze critical- chain' and I got the following very interesting responses, shell dialogue copied below. The same processes (I would assume) are hanging for 1m44s, but the shortcut somehow allows the user to log in while waiting for them to finish (as well as solving the other problems of clipboard and screen size, which seem to go with the more primitive login screen). Whether those processes should take 1m44s or not, I don't know, maybe it is normal, but the user should be able to log in before they are complete, as I can do with shortcut boot. If those processes are taking inordinately long, then shortcut boot gives opportunity to log in and catch them as they struggle, as seen below. The time I had to wait to get the critical-chain result was about as long as I had to wait to log in at all, under stock 19.10 without shortcut-boot procedure: wift@stock19:~$ sudo -i [sudo] password for swift: root@stock19:~# systemd-analyze critical-chain Bootup is not yet finished (org.freedesktop.systemd1.Manager.FinishTimestampMonotonic=0). Please try again later. Hint: Use 'systemctl list-jobs' to see active jobs root@stock19:~# systemctl list-jobs JOB UNIT TYPE STATE 48 setvtrgb.service start waiting 137 system-getty.slice start waiting 1 graphical.target start waiting 102 systemd-update-utmp-runlevel.service start waiting 83 plymouth-quit-wait.service start running 2 multi-user.targetstart waiting 6 jobs listed. root@stock19:~# systemd-analyze critical-chain Bootup is not yet finished (org.freedesktop.systemd1.Manager.FinishTimestampMonotonic=0). Please try again later. Hint: Use 'systemctl list-jobs' to see active jobs root@stock19:~# systemd-analyze critical-chain Bootup is not yet finished (org.freedesktop.systemd1.Manager.FinishTimestampMonotonic=0). Please try again later. Hint: Use 'systemctl list-jobs' to see active jobs root@stock19:~# systemd-analyze critical-chain Bootup is not yet finished (org.freedesktop.systemd1.Manager.FinishTimestampMonotonic=0). Please try again later. Hint: Use 'systemctl list-jobs' to see active jobs root@stock19:~# date Sun 19 Apr 2020 10:50:27 PM EDT root@stock19:~# systemd-analyze critical-chain The time when unit became active or started is printed after the "@" character. The time the unit took to start is printed after the "+" character. graphical.target @1min 44.881s └─multi-user.target @1min 44.881s └─xrdp.service @1.496s +1.036s └─xrdp-sesman.service @1.474s +20ms └─network.target @1.470s └─NetworkManager.service @1.381s +88ms └─dbus.service @1.379s └─basic.target @1.375s └─sockets.target @1.375s └─snapd.socket @1.373s +1ms └─sysinit.target @1.372s └─systemd-timesyncd.service @1.175s +196ms └─systemd-tmpfiles-setup.service @1.160s +10ms └─local-fs.target @1.158s └─home-swift-shared\x2ddrives.mount @11.731s └─local-fs-pre.target @177ms └─lvm2-monitor.service @116ms +61ms └─dm-event.socket @115ms └─system.slice @110ms └─-.slice @110ms root@stock19:~# -- 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
[Bug 1848534] Re: [Microsoft Hyper-V guest] System shows graphic artifacts for a moment, then text cursor for about minute and then starts
I've created a 2m35s desktop video showing a boot of stock 18.04 and
19.10 on my system, posted at https://chaetura.net/ms-
vid1-bug-1848534.webm (18MB, renders in Chrome window for me, or use VLC
to watch).
I've posted a second video showing the shortcut to boot 19.10 quickly
that I described earlier, but which I have simplified to simply pulling
the plug with "power off" from Hyper-V at the grub menu, do not close
the Connection window, restart, and 19.10 will boot fast. Note that
"system setup" (I previously mistakenly wrote "system startup") doesn't
appear in the grub menu of stock 19.10; it appears only after updating
packages in Ubuntu. Yes, I am able to select the “restart” button with
the keyboard. But then the shortcut doesn’t work; what triggers the
shortcut is powering off the VM.
https://chaetura.net/ms-vid2-bug-1848534.webm
Furthermore, the shortcut boot of 19.10 solves *THREE* significant
problems with stock 19.10 that are not problems with stock 18.04.3.
Reasonable conclusion is that all three problems have the same cause,
which somehow the shortcut boot avoids:
1) avoids the long delay in startup
2) allows user to select any screen size for the Connection (whereas
stock 19.10 came in one size only and user has no opportunity to select;
goes hand in hand with the different login screen, as you can see in
video.
3) after login, cut-and-paste from guest to host is possible. Not
functional with stock 19.10.
I see that graphical artifact at some point during boot of any Ubuntu VM
in Hyper-V. You can see it in the video too. In 19.10 it comes while the
Spectre mitigation message is on the screen in console, at a point where
console changes its rendering/mode somehow and the message reappears in
a slightly different font.
I forgot to show /proc/cmdline and "uname -a" in the video but for 19.10
it is:
BOOT_IMAGE=/boot/vmlinuz-5.3.0-23-generic root=PARTUUID=[blahblah] ro quiet
splash
Linux stock19 5.3.0-23-generic #25-Ubuntu SMP Tue Nov 12 09:22:33 UTC 2019
x86_64 x86_64 x86_64 GNU/Linux
and in 18.04.3 it is
BOOT_IMAGE=/boot/vmlinuz-5.0.0-25-generic root=LABEL=desktop-rootfs ro
quiet splash vt.handoff=1
Linux stock18 5.0.0-25-generic #26~18.04.1-Ubuntu SMP Thu Aug 1 13:51:02
UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Note that I installed my 19.10 via Hyper-V Manager's "quick-create"
rather than from an .iso downloaded separately. Same kernel version, but
mine is an earlier packaging number, and who knows what else may be
different about the install image. The manager says the image was
updated 17 October 2019. The Manager downloads a zip file from partner-
images.canonical.com via https so I cannot snoop the URL looking at the
packets. I have a copy of the .vhdx which is insie the zip file, and I'm
messing around with trying to mount it in another VM but I haven't
solved that yet.
My Windows 10 Pro x64 build (today) is Win10: Version 1909 (OS Build
18363.778). No further windows updates are available, and I don't
understand Windows version numbers, so I can't explain the discrepancy
from yours.
The startup delay persists after updating the stock install of 19.10
(using aptitude; all available updates accepted but the grub packages
held back till I learn how to do them; they broke my last install).
I noticed while making the video that during the long startup delay, the
process is using GPU at 5% -- significant amount of usage (documented in
video). Therefore I've included my GPU information at bottom below.
I boot stock quick-create 19.10. I change the name of the VM only
("Stock19"). Default ethernet adapter. Note that the first boot is
immediate; the only one that will ever be that fast, unless I go through
the shortcut boot sequence. On first boot, I go through Ubuntu
configuration screens minimally. Post-install runs. No further updates,
just reboot now (because critical-chain timings are much longer the
first boot than all subsequent boots). Login, run terminal, sudo-i, then
systemd-analyze critical-chain:
first line is: graphical.target @1min 44.651s
This is typical of all subsequent boots.
I'm not copying the full output all because cut-and-paste text from
guest to host is broken for me in 19.10. It is not broken in an 18.04.3
guest ("updated 19 August 2019" in Hyper-V Manager).
Here for comparison is the critical-chain for 18.04, which I can cut-
and-paste. Less than 2s to "graphical.target", compared with 104s for
19.10.
swift@Riflebird:~$ sudo -i
[sudo] password for swift:
root@Riflebird:~# systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.
graphical.target @1.836s
└─multi-user.target @1.836s
└─kerneloops.service @1.829s +6ms
└─network-online.target @1.827s
└─NetworkManager-wait-online.service @663ms +1.163s
└─NetworkManager.service @566ms +96ms
└─dbus.service @538ms
└─basic.target @5
[Bug 1848534] Re: [Microsoft Hyper-V guest] System shows graphic artifacts for a moment, then text cursor for about minute and then starts
A stray click sent my previous message before I had finished editing it, and I see no way to edit my post. I will post fully complete/edited version momentarily. I hope an admin will delete this message and my prior message to avoid cruft in this thread. -- 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
[Bug 1848534] Re: [Microsoft Hyper-V guest] System shows graphic artifacts for a moment, then text cursor for about minute and then starts
I've created a 2m35s desktop video showing a boot of stock 18.04 and
19.10 on my system, posted at https://chaetura.net/ms-
vid1-bug-1848534.webm (18MB, renders in Chrome window for me, or use VLC
to watch).
I've posted a second video showing the shortcut to boot 19.10 quickly
that I described earlier, but which I have simplified to simply pulling
the plug with "power off" from Hyper-V at the grub menu, do not close
the Connection window, restart, and 19.10 will boot fast. Note that
"system setup" (I previously mistakenly wrote "system startup") doesn't
appear in the grub menu of stock 19.10; it appears only after updating
packages in Ubuntu.
Furthermore, the shortcut boot of 19.10 solves *THREE* significant
problems with stock 19.10 that are not problems with stock 18.04.3:
1) avoids the long delay in startup
2) allows user to select any screen size for the Connection (whereas stock
19.10 came in one size only
and user has no opportunity to select; goes hand in hand with the
different login screen, as you
I see that graphical artifact at some point during boot of any Ubuntu VM in
Hyper-V. You can see it in the video too. In 19.10 it comes while the Spectre
mitigation message is on the screen in console, at a point where console
changes its rendering/mode somehow and the message reappears in a slightly
different font.
I forgot to show /proc/cmdline and "uname -a" in the video but for 19.10 it is:
BOOT_IMAGE=/boot/vmlinuz-5.3.0-23-generic root=PARTUUID=[blahblah] ro quiet
splash
Linux stock19 5.3.0-23-generic #25-Ubuntu SMP Tue Nov 12 09:22:33 UTC 2019
x86_64 x86_64 x86_64 GNU/Linux
and in 18.04.3 it is
BOOT_IMAGE=/boot/vmlinuz-5.0.0-25-generic root=LABEL=desktop-rootfs ro
quiet splash vt.handoff=1
Linux stock18 5.0.0-25-generic #26~18.04.1-Ubuntu SMP Thu Aug 1 13:51:02
UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Note that I installed my 19.10 via Hyper-V Manager's "quick-create"
rather than from an .iso downloaded separately. Same kernel version, but
mine is an earlier packaging number, and who knows what else may be
different about the install image. The manager says the image was
updated 17 October 2019. The Manager downloads a zip file from partner-
images.canonical.com via https so I cannot snoop the URL looking at the
packets. I have a copy of the .vhdx which is insie the zip file, and I'm
messing around with trying to mount it in another VM but I haven't
solved that yet.
My Windows 10 Pro x64 build (today) is Win10: Version 1909 (OS Build
18363.778). No further windows updates are available, and I don't
understand Windows version numbers, so I can't explain the discrepancy
from yours.
The startup delay persists after updating the stock install of 19.10
(using aptitude; all available updates accepted but the grub packages
held back till I learn how to do them; they broke my last install).
I noticed while making the video that during the long startup delay, the
process is using GPU at 5% -- significant amount of usage (documented in
video). Therefore I've included my GPU information at bottom below.
I boot stock quick-create 19.10. I change the name of the VM only
("Stock19"). Default ethernet adapter. Note that the first boot is
immediate; the only one that will ever be that fast, unless I go through
the restart sequence described last time. (On that subject, I don't get
the "system setup" grub option in the stock 19.10, only after updates.
You probably figured out I mistakenly wrote "system startup" earlier
instead of "system setup" as well. And yes, keyboard can select
"restart" but in this case, the shortcut does *NOT* work. Only pulling
the plug on the VM from Hyper-V ) On first boot, I go through Ubuntu
configuration screens minimally. Post-install runs. No further updates,
just reboot noq (because critical-chain timings are much longer the
first boot than all subsequent boots). Login, run terminal, sudo-i, then
systemd-analyze critical-chain:
first line is: graphical.target @1min 44.651s
This is typical of all subsequent boots.
I'm not copying the full output all because cut-and-paste text from
guest to host is broken for me in 19.10. It is not broken in an 18.04.3
guest ("updated 19 August 2019" in Hyper-V Manager).
Also in 19.10 I never get the choice of a screen size for the guest when
connecting; it is always the same size. I get the choice in 18.04 and
can choose any size including full-screen, and it just works.
I understand that these other problems with 19.10 guest may be off-
topic; I am mentioning them here in case they correlate to the current
topic. In summary, four significant problems with 19.10 that do not
exist in 18.04, both out of the box quick-create, using same host: 1)
the long delay at startup. 2) no cut-and-paste from guest to host. 3) no
capability to resize Hyper-V Connection screen. 4) requires research to
get past a grub update.
Here for comparison is the critical-chain for 18.04, which I can cut-
and-paste. Less th
[Bug 1848534] Re: [Microsoft Hyper-V guest] System shows graphic artifacts for a moment, then text cursor for about minute and then starts
I reproduced this with Win10 x64 up to date on 4/11/2020 and the stock "quick create" versions of Ubuntu 18.04 and 19.10 as referenced and selected from the Hyper-V manager. Default options all the way. No updates installed after initial installation. This machine has AMD Ryzen 7 3800X and 32GB memory, NVMe SSD system drive -- it's fast. Default network adapter for the VMs. ipv6 enabled or disabled on underlying NIC and the vEthernet default switch (I tried both ways). 18.04 goes from "start" to X login in 11 seconds, including having to press through a console "error: no such device: root / press any key to continue" glitch. 19.10 goes from start to a Grub menu in about 3 seconds. 11 more seconds through console message about Spectre mitigation, then the Ubuntu splash screen of 5 dots on purple background, then console cursor holds for about 1:40. Then X login finally. System load during the long delay on network, disk, CPU under 5% during this time. Then suddenly a flurry of console messages followed by X login window. Seems very clear that the boot process is waiting for a long failed timeout somehow before proceeding. By accident I discovered the following with 19.10. Select "system startup" from the grub menu. Result is Windows logo screen "Hyper-V UEFI / No boot devices were found." The "restart" button is not functional, have to "power off" the VM because "shutdown" fails. Re-power on without closing the connection window, and 19.10 proceeds through same sequence from "start" to X login in about 12 seconds: spectre mitigation message on console, Ubuntu splash, console cursor, then possibly the flurry of console messages (but so fast invisible), then X login. I can get through the sequence above of grub "system startup" then power-off, then restart to the X login from scratch in 25 seconds, whereas about 120 seconds if I just start and wait through the timeout. -- 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
