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 Kernel Packages, which is subscribed to linux 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 Status in gdm3 package in Ubuntu: Confirmed Status in linux package in Ubuntu: Confirmed Bug description: AFter upgrade system shows graphic artefacts for a moment and then text cursor for about minute (it looks like hanged) and then starts. In 19.04 startup required 1 or 2 seconds. ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: ubuntu-release-upgrader-core 1:19.10.15 ProcVersionSignature: Ubuntu 5.3.0-18.19-generic 5.3.1 Uname: Linux 5.3.0-18-generic x86_64 ApportVersion: 2.20.11-0ubuntu8 Architecture: amd64 CrashDB: ubuntu CurrentDesktop: ubuntu:GNOME Date: Thu Oct 17 17:42:27 2019 InstallationDate: Installed on 2019-07-04 (104 days ago) InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416) PackageArchitecture: all SourcePackage: ubuntu-release-upgrader Symptom: dist-upgrade UpgradeStatus: Upgraded to eoan on 2019-10-17 (0 days ago) VarLogDistupgradeLspcitxt: VarLogDistupgradeXorgFixuplog: INFO:root:/usr/bin/do-release-upgrade running INFO:root:No xorg.conf, exiting --- ProblemType: Bug ApportVersion: 2.20.11-0ubuntu8 Architecture: amd64 AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CompositorRunning: None CurrentDesktop: ubuntu:GNOME DistUpgraded: 2019-10-17 17:03:47,139 DEBUG Running PostInstallScript: './xorg_fix_proprietary.py' DistroCodename: eoan DistroRelease: Ubuntu 19.10 DistroVariant: ubuntu ExtraDebuggingInterest: Yes GraphicsCard: InstallationDate: Installed on 2019-07-04 (105 days ago) InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416) IwConfig: eth0 no wireless extensions. lo no wireless extensions. Lspci: Lsusb: Error: command ['lsusb'] failed with exit code 1: MachineType: Microsoft Corporation Virtual Machine Package: xorg-server (not installed) ProcFB: 0 hyperv_fb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.3.0-18-generic root=UUID=17409d40-25e9-4051-9fd9-758e2a02ebc3 ro quiet splash video=hyperv_fb:1900x900 elevator=noop vt.handoff=7 ProcVersionSignature: Ubuntu 5.3.0-18.19-generic 5.3.1 RelatedPackageVersions: linux-restricted-modules-5.3.0-18-generic N/A linux-backports-modules-5.3.0-18-generic N/A linux-firmware 1.183 RfKill: Tags: eoan ubuntu Uname: Linux 5.3.0-18-generic x86_64 UpgradeStatus: Upgraded to eoan on 2019-10-17 (0 days ago) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo _MarkForUpload: True dmi.bios.date: 01/30/2019 dmi.bios.vendor: Microsoft Corporation dmi.bios.version: Hyper-V UEFI Release v4.0 dmi.board.asset.tag: None dmi.board.name: Virtual Machine dmi.board.vendor: Microsoft Corporation dmi.board.version: Hyper-V UEFI Release v4.0 dmi.chassis.asset.tag: 2831-3616-6111-5725-4803-1162-28 dmi.chassis.type: 3 dmi.chassis.vendor: Microsoft Corporation dmi.chassis.version: Hyper-V UEFI Release v4.0 dmi.modalias: dmi:bvnMicrosoftCorporation:bvrHyper-VUEFIReleasev4.0:bd01/30/2019:svnMicrosoftCorporation:pnVirtualMachine:pvrHyper-VUEFIReleasev4.0:rvnMicrosoftCorporation:rnVirtualMachine:rvrHyper-VUEFIReleasev4.0:cvnMicrosoftCorporation:ct3:cvrHyper-VUEFIReleasev4.0: dmi.product.family: Virtual Machine dmi.product.name: Virtual Machine dmi.product.sku: None dmi.product.version: Hyper-V UEFI Release v4.0 dmi.sys.vendor: Microsoft Corporation version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.99-1ubuntu1 version.libgl1-mesa-dri: libgl1-mesa-dri 19.2.1-1ubuntu1 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.xserver-xorg-core: xserver-xorg-core 2:1.20.5+git20191008-0ubuntu1 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.0.1-1ubuntu1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20190815-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1848534/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
