View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0005270 | Kali Linux | [All Projects] General Bug | public | 2019-02-22 10:10 | 2021-08-16 18:19 |
Reporter | freakyclown | Assigned To | rhertzog | ||
Priority | normal | Severity | major | Reproducibility | always |
Status | resolved | Resolution | fixed | ||
Product Version | 2019.1 | ||||
Target Version | Fixed in Version | 2019.1 | |||
Summary | 0005270: Fresh Installation on Vmware Fusion from ISO freezes or fails | ||||
Description | Any of the latest 2019.1 ISO's all appear to have the same issue. When freshly downloaded (SHA256 matched) and used in VMware Fusion Version 10.1.5 (10950653) or VMware Fusion Version 10.1.4 will boot and then hang on the first screen of the GUI installation screen. The text install will go further but still fail on a mounting of the cd-rom drivers. There is no obvious indication to me why this is happening however the clue might be in the fact the text install of the 32bit version does appear at least to install fully, but in my experiments it failed to reboot and would not work. | ||||
Steps To Reproduce | 1. Download fresh (any) iso from the site 2. create new VM and assign it decent settings of ram and cpu etc and point to the new iso 3. boot the vm 4. select graphic install 5. observe neither mouse nor keyboard functions in order to select further steps. 1. Download fresh (any) iso from the site 2. create new VM and assign it decent settings of ram and cpu etc and point to the new iso 3. boot the vm 4. select install 5. observe that keyboard function works to confirm steps, however it will fail after a few asking to install cd-rom drivers 1. Download fresh 32bit iso from the site 2. create new VM and assign it decent settings of ram and cpu etc and point to the new iso 3. boot the vm 4. select gui install 5. observe that mouse fails to function but keyboard function works to confirm steps, installation appears successful, and will not reboot. | ||||
Additional Information | My versions tested OSX - Mojave 10.14.2 Vmware Fusion 10.1.4 Vmware Fusion 10.1.5 ISOs: Kali Linux 64 Bit HTTP | Torrent 3.2G 2019.1 5596f2b5da66a45a6e6d14510cedc3fc20980f21d01c18059809ef651e6726dd Kali Linux 32 Bit HTTP | Torrent 3.3G 2019.1 da9f4a9ae7be7f35ca924160104944e03935a2e0e4c422e5e463ba70683d7c77 Kali Linux Xfce 64 Bit HTTP | Torrent 3.0G 2019.1 f86b3c6cc98af2d2d86e829fb8a3b08b4d5c4f376d6b8b1e108c58fcfdb46229 I also tried the same steps with kali-linux-2018.4-amd64.iso 2018-10-16 16:08 2.9G kali-linux-light-2018.4-amd64.iso 2018-10-16 17:05 867M this issue does NOT appear in 2018.4 | ||||
|
After expressing this issue on twitter a bunch of people jumped in with other helpful information: Dist-ugrade appears to work fine so going from 2018.4 to 2019.1 works ok. "Installed on Win10 with VMware Workstation Pro 14.1.5 build-10950780 without issue." "I had the mate version do the same thing on GUI install. Text install worked" "I tried installing on Workstation Pro 15 and either got unresponsive GUI or unable to detect the ISO to mount during CLI install. That was 64 bit. Haven't tried 32 bit." |
|
I suspect the issue to be the version of VMware used. If you were to try to update your fusion version to 11.0.x (what we use for testing), it should work. Would anyone be able to test this? |
|
Testing on VMware Fusion 10.1.2 with Mojave version 10.14 I experience the same issues. When I use the updated VMware Fusion, 11.0.2, I experience no bugs of that sort. I did not test with the 2018.4 as I already have a VM of that version. |
|
Correction, I messed up and didn't select the right iso on the 11.0.2 test. On an 11.0.2 VMware Fusion version with Mojave 10.14.1 I am unable to use the mouse during graphical install of the 2019.1 64 Bit iso. |
|
I have this same exact problem. This is far as I get. |
|
@Gamb1t Can you reproduce the same issue with this Debian ISO ? https://cdimage.debian.org/cdimage/buster_di_alpha5/amd64/iso-cd/debian-buster-DI-alpha5-amd64-netinst.iso |
|
I tried to reproduce the issue on a computer with Windows 10 and VMWare Workstation Pro 12.5.9. On my first try, I was not able to reproduce the problem with the mouse and the keyboard. Neither with the main Kali 2019.1 image nor with the Debian Buster Alpha 5 image (each time on amd64). On my second try with the Kali image, the mouse was not working but the keyboard was working. On my third try with the Kali image, the mouse was again working but the installer failed to identify the network card (I had to go back and let it retry the auto-detection so that it works). When I compare the "dmesg" output of both cases, I get this interesting output: $ diff -u kali-{failed,working}-mouse-dmesg-no-timing --- kali-failed-mouse-dmesg-no-timing 2019-02-26 10:41:53.669165986 +0100 +++ kali-working-mouse-dmesg-no-timing 2019-02-26 10:42:05.077218497 +0100 @@ -1279,6 +1279,8 @@ hub 2-0:1.0: USB hub found hub 2-0:1.0: 2 ports detected mptbase: ioc0: Initiating bringup + input: VirtualPS/2 VMware VMMouse as /devices/platform/i8042/serio1/input/input3 + input: VirtualPS/2 VMware VMMouse as /devices/platform/i8042/serio1/input/input2 libata version 3.00 loaded. ata_piix 0000:00:07.1: version 2.13 scsi host0: ata_piix @@ -1301,16 +1303,16 @@ usb 2-1: Product: VMware Virtual USB Mouse usb 2-1: Manufacturer: VMware hidraw: raw HID events driver (C) Jiri Kosina - usbcore: registered new interface driver usbhid - usbhid: USB HID core driver scsi 2:0:0:0: Direct-Access VMware, VMware Virtual S 1.0 PQ: 0 ANSI: 2 scsi target2:0:0: Beginning Domain Validation + random: fast init done scsi target2:0:0: Domain Validation skipping write tests scsi target2:0:0: Ending Domain Validation scsi target2:0:0: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 127) - input: VMware VMware Virtual USB Mouse as /devices/pci0000:00/0000:00:11.0/0000:02:00.0/usb2/2-1/2-1:1.0/0003:0E0F:0003.0001/input/input2 + usbcore: registered new interface driver usbhid + usbhid: USB HID core driver + input: VMware VMware Virtual USB Mouse as /devices/pci0000:00/0000:00:11.0/0000:02:00.0/usb2/2-1/2-1:1.0/0003:0E0F:0003.0001/input/input4 on usb-0000:02:00.0-1/input0 - random: fast init done 41943040 512-byte logical blocks: (21.5 GB/20.0 GiB) Write Protect is off Mode Sense: 61 00 00 00 It looks like that when it works it detects a PS/2 mouse and a USB mouse, and when it doesn't work in only detects an USB mouse. I'm attaching both dmesg output. |
|
dmesg.zip (37,491 bytes) |
|
Well this is good news (or bad) I guess, as the original theory was that this was a Vmware Fusion issue. Now the behaviour has been spotted on mac and windows I feel a bit vindicated at least. |
|
Despite multiple tries, I was not able to reproduce the problem (on Win 10 with VMWare WS Pro) with the Debian Buster Alpha 5 ISO image. And yet the amount of difference with the Kali image is not big... they have been created about at the same time. The Debian Buster one uses Linux 4.19.12, the Kali one 4.19.13. They have the same version of udev/systemd I think (240-4). |
|
I then tried with a daily build of Debian Installer: http://cdimage.debian.org/cdimage/daily-builds/daily/20190226-1/amd64/iso-cd/debian-testing-amd64-netinst.iso This one uses Linux 4.19.16. I was also not able to reproduce the problem with Windows 10 and VMWare Workstation Pro 12.5.9. I'm keen to know the result for those 2 ISOs on VMWare Fusion. Despite the fact, that I can reproduce the non-working mouse on Windows, there seems to be a big difference in terms how often the problem triggers (i.e. I can work around the issue by rebooting and doing another try) and in terms of impact as well (for me it's only the mouse, the keyboard was working fine). |
|
Coming back to the problematic case where the mouse is not working, since I have the keyboard that works I can switch to a text console (CTRL+ALT+F2) and typed "lsmod" and I saw that the "psmouse" module was not loaded (whereas it was correctly loaded in the working case). So a simple work-around is to run "modprobe psmouse" in that console and I can switch back to the graphical console (CTRL+ALT+F5) and there the mouse works now. Now we should try to understand why it doesn't get loaded but I think that my first try will be to build a new image with a newer kernel image (4.19.20 that we have available in kali-experimental) and see if it's enough to solve the problem. |
|
I tested out both Debian ISOs and did not experience the problem on either of them even after multiple attempts. I can also confirm that the "modprobe psmouse" re-enables the mouse and it works just fine after that. |
|
So I tried with a new daily ISO (which now uses Linux 4.19.20) and I can no longer reproduce the problem. http://archive.kali.org/kali-daily-images/ So now the question, do we want to regenerate the 2019.1 ISO images to include Linux 4.19.20 ? |
|
2019.1a is out to address this issue |
Date Modified | Username | Field | Change |
---|---|---|---|
2019-02-22 10:10 | freakyclown | New Issue | |
2019-02-22 10:14 | freakyclown | Note Added: 0010352 | |
2019-02-22 13:53 | muts | Note Added: 0010353 | |
2019-02-22 20:37 | Gamb1t | Note Added: 0010355 | |
2019-02-22 20:48 | Gamb1t | Note Added: 0010356 | |
2019-02-26 03:43 | aschenix | File Added: 02.PNG | |
2019-02-26 03:43 | aschenix | Note Added: 0010365 | |
2019-02-26 09:12 | rhertzog | Note Added: 0010366 | |
2019-02-26 09:53 | rhertzog | Note Added: 0010367 | |
2019-02-26 09:54 | rhertzog | File Added: dmesg.zip | |
2019-02-26 10:09 | freakyclown | Note Added: 0010368 | |
2019-02-26 10:27 | rhertzog | Note Added: 0010369 | |
2019-02-26 10:49 | rhertzog | Note Added: 0010370 | |
2019-02-26 10:59 | rhertzog | Note Added: 0010371 | |
2019-02-26 10:59 | rhertzog | Assigned To | => rhertzog |
2019-02-26 10:59 | rhertzog | Status | new => assigned |
2019-02-26 17:12 | Gamb1t | Note Added: 0010372 | |
2019-02-28 16:26 | rhertzog | Note Added: 0010379 | |
2019-03-05 17:05 | g0tmi1k | Note Added: 0010394 | |
2019-03-21 15:10 | rhertzog | Status | assigned => resolved |
2019-03-21 15:10 | rhertzog | Resolution | open => fixed |
2019-03-21 15:10 | rhertzog | Fixed in Version | => 2019.1 |
2020-12-01 10:48 | g0tmi1k | Priority | high => normal |