View Issue Details

IDProjectCategoryView StatusLast Update
0005270Kali LinuxGeneral Bugpublic2021-08-16 18:19
Reporterfreakyclown Assigned Torhertzog  
Status resolvedResolutionfixed 
Product Version2019.1 
Fixed in Version2019.1 
Summary0005270: Fresh Installation on Vmware Fusion from ISO freezes or fails

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.

  6. Download fresh (any) iso from the site

  7. create new VM and assign it decent settings of ram and cpu etc and point to the new iso

  8. boot the vm

  9. select install

  10. observe that keyboard function works to confirm steps, however it will fail after a few asking to install cd-rom drivers

  11. Download fresh 32bit iso from the site

  12. create new VM and assign it decent settings of ram and cpu etc and point to the new iso

  13. boot the vm

  14. select gui install

  15. 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

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

Attached Files (37,491 bytes)




2019-02-22 10:14

reporter   ~0010352

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."



2019-02-22 13:53

reporter   ~0010353

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?



2019-02-22 20:37

manager   ~0010355

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.



2019-02-22 20:48

manager   ~0010356

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.



2019-02-26 03:43

reporter   ~0010365

I have this same exact problem. This is far as I get.

02.PNG (133,759 bytes)   
02.PNG (133,759 bytes)   


2019-02-26 09:12

administrator   ~0010366

@Gamb1t Can you reproduce the same issue with this Debian ISO ?



2019-02-26 09:53

administrator   ~0010367

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.



2019-02-26 10:09

reporter   ~0010368

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.



2019-02-26 10:27

administrator   ~0010369

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).



2019-02-26 10:49

administrator   ~0010370

I then tried with a daily build of Debian Installer:
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).



2019-02-26 10:59

administrator   ~0010371

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.



2019-02-26 17:12

manager   ~0010372

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.



2019-02-28 16:26

administrator   ~0010379

So I tried with a new daily ISO (which now uses Linux 4.19.20) and I can no longer reproduce the problem.

So now the question, do we want to regenerate the 2019.1 ISO images to include Linux 4.19.20 ?



2019-03-05 17:05

administrator   ~0010394

2019.1a is out to address this issue

Issue History

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:
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