DisplayLink Not Installing In Parrot OS

[DizKiller]

Not installing on parrot 3.10 this is what i get: ./displaylink-debian.sh

--------------------------- displaylink-debian ----------------------------

DisplayLink driver installer for Debian based Linux distributions:

• Debian GNU/Linux
• Ubuntu
• Elementary OS
• Linux Mint
• Kali Linux
• Deepin

Options:

[I]nstall [U]ninstall [R]e-install [Q]uit

Select a key: [i/u/r/q]: R

---

Checking dependencies

unzip is installed linux-headers-4.14.0-parrot2-amd64 is installed dkms is installed lsb-release is installed linux-source is installed

---

Unsuported platform: Parrot intruder

This tool is Open Source and feel free to extend it GitHub repo: https://github.com/AdnanHodzic/displaylink-debian/

---

How can i force parrot to install, in light of parrot is a kali derivative..

[DizKiller]

UPDATE: Added this into displaylink-debian.sh : :# Parrot elif [ "$lsb" == "Parrot" ]; then if [ $codename == "intruder" ]; then echo -e "\nPlatform requirements satisfied, proceeding ..." else message exit 1 fi I re-ran it. downloaded fine, got this error, and i am not quite sure how to proceed.

Installing driver version: 1.4

DisplayLink Linux Software 1.4.210 install script called: install Distribution discovered: Parrot 3.10 - Intruder Unsatisfied dependencies. Missing component: Linux headers for running kernel, 4.14.0-parrot2-amd64. This is a fatal error, cannot install DisplayLink Linux Software.

I'm thinking the bolded characters is the problem, but im coming up blank.. How should i proceed?

[ralphyz]

Try: sudo apt install linux-headers-$(uname -r)

I had to do that on Kali.

[redjamesg]

Make sure your /lib/modules/4.14.0-parrot2-amd64/sources is pointing to the right source tree, I dont know the exact layout of the file structure in Parrot, but it's probably located some where like: /usr/src/linux-headers-4.14.0-common

[DizKiller]

@ralphyz Do you think this is safe to do to Parrot? reason i ask is because this is my main OS, and it rocks as it sits.. EDIT: I tried the script. results:

Reading package lists... Done Building dependency tree
Reading state information... Done linux-headers-4.14.0-parrot7-amd64 is already the newest version (4.14.7-1parrot7). linux-headers-4.14.0-parrot7-amd64 set to manually installed. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

@redjamesg could you clarify a bit further, and be a bit more detailed. Thank you.

[redjamesg]

Since evdi is a driver or more precise a module that is being loaded into your kernel stack at runtime, it needs to be compiled specific to your current running kernel.

This is why you need to have linux-headers-uname -v installed.

The kernel modules needs to be located at a specific location in your environments file structure , since many are loaded during boot and needs to be accessible the moment the kernel recognises the root partition.

This has from earlier times been defined as /lib/modules/uname -v

In some of the first kernels the kernel layer prevented dynamic loading of modules, which is why for the most part modules were compiled/hard linked into the kernel and only very few existed as 'at runtime loadable modules', even today if you compile your own kernel you can select the drivers/modules as modules or build static linked into the kernel.

Using a kernel with dynamic module loading provides support for a large variety of hardware and provider specific components without a specific kernel build to each PC. This yields in a much smaller footprint of the kernel and gives the linux distribution maintainers ability to only provide one compiled structure of kernel modules while giving support to any user having a PC running with the architecture the modules are compiled against (i386/arm/arm64/amd64/mipsel/alpha/etc)

Since the Linux distribution is tailored towards the majority that is just using the maintainers precompiled packages, it still gives the user the ability to custom compile anything specific towards the current running PC, when talking kernel modules the kernel source and specific kernel headers are provided.

Think of the kernel headers as being instructions telling the modules what they can use from the surrounding system, ie: not everything needs to know how to print the letter 'e' to the screen; All the buffers used, addressing the correct screen memory that is used on the next redrawing of the image transferred to the monitor, no, most parts just needs to know if they say "print e" it will be displayed on the screen.

In a more complex way it is the same with the parts of the kernel every module is relying on to try and provide the support their instructions are ment for in the current system.

During this specific compilation of the modules, their instructions in the code is matched up against what the rest of the kernel can provide, like the print instruction, so without knowing how the underlying actions are carried out, the instructions know they can rely on something being written on the screen as long as it is predefined by the keyword print.

These available routines are mentioned in the header files, which is why the package conveniently is named headers and since it is specific to the current running kernel, it has the current version in the name, hence the uname -v command in the name.

The location of these header files can be anywhere you want them to be, yet the compilation process needs to know how to find them.

Since the modules location is predefined as /lib/modules/uname -v the easiest thing is to provide the location as a simple pointer in that location, so simply put, the /lib/modules/uname -v/sources is just a link or if you wish a pointer to where the linux-headers-uname -v package places it's files.

And since the displaylink driver installer essentially is tailoring the evdi module to your kernel, it needs to know the presence of these header files.

Sorry for the long post, but I hope it gives more sense into why we are suggesting the things mentioned here.

[DizKiller]

Ok, i will try... thank you for defining that for me.

[AdnanHodzic]

Closing due to inactivity, please feel free to re-open if you have additional input/comments.