Abbas Mehdi's questions

I have made several attempts of performing a fresh installation of Ubuntu 20.04, but somehow, I am unable to. The installation abruptly crashes before any prompt/user-input screen could appear. Irrespective of whether I let the installer perform the disk scan or I simply skip it, the installer abruptly terminates within 15 seconds.

That is, when I create a bootable USB through Rufus. When I try to make a bootable USB through Unetbootin, it does not boot at all.

It would be really appreciable if anyone could help me getting my Ubuntu installed.

I have been seeing this problem for a long long time in Ubuntu!

Whenever the system (re)boots, the first login (i.e. the time between entering the password and hitting Enter and the desktop appears) is about equal (or sometimes more) than the boot time (i.e., the time the entire booting process takes until the login screen appears).

I haven't seen this behaviour on any other OS!

Why is it so? Is there something inappropriately set in the system settings? How to see exactly which process takes how much time in the login process (just as we use systemd-analyze for monitoring startup processes and times)? Is there any workaround to reduce this login time?

Any assistance is greatly appreciated.

My machine keeps prompting of "Invalid Signatures Found" at every single boot. I knew of two kernel modules that had invalid signatures, the NVIDIA display driver module and the vboxdrv module, and I signed them as well. And I am pretty sure they are appropriately signed (as, after appropriate signing, I don't see the symptoms in these two modules), yet I keep getting the "Invalid Signature Found" prompt at every boot. Which, most probably, means that there are some other modules that need appropriate signing.

Is there any method to enlist all such modules that need signing, which may be causing the "Invalid Signature Found" prompts at every boot?

MSI machines support just a single method for updating the firmware, and that is through .exe files released by MSI.

Since MSI officially supports just the Windows operating system, all there support and services are centred around it.

Is there any known procedure for updating the firmware on an MSI machine running Linux (esp. Ubuntu)?

I don't think trying to run the updated firmware .exe file through Wine or PlayOnLinux would be a safe thing to do!

Can it be done through a virtual machine running on my Ubuntu?

I have apache2.service enlisted in the output of systemd-analyze critical-chain, taking more than 5.5 seconds!

Why is apache2 even installed on my system when I am not running a web server?

Response to Tomasz Gandor

Thanks, Tomasz. Here is the output response:

$ aptitude why apache2
i   phpliteadmin-themes Depends    phpliteadmin                 
i A phpliteadmin        Recommends apache2 (>= 2.4.6-4~) | httpd

And I think it's just a theme, so it would be safe to remove it. Should I?

Response to PerlDuck

Thanks, PerlDuck. Here is the output response:

$ apt-cache rdepends --installed apache2
apache2
Reverse Depends:
  libapache2-mod-php7.2
 |phpliteadmin
 |javascript-common
  libapache2-mod-php7.2

Now, I am not very much certain about what to do!

Also, there is one thing to be noted in the response of apt-cache rdepends, and that is the | sign before phpliteadmin and javascript-common. What does this indicate?

And why is libapache2-mod-php7.2 listed twice in the output, once at the top and once at the bottom of the list?

I searched the internet, and could not find any significant information about it.

Making a wild guess, it performs a daily check for available updates. Is it so?

But then, it significantly slows my startup!

Also, I have disabled automatic updates, and have a habit of checking for, and installing, updates every time I start my computer.

So..... Isn't it wise to stop this service?

Edit: Response of 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 @30.394s
└─gdm.service @29.795s +598ms
  └─systemd-user-sessions.service @26.524s +361ms
    └─network.target @26.521s
      └─networking.service @20.093s +6.427s
        └─apparmor.service @15.701s +3.970s
          └─local-fs.target @15.699s
            └─boot-efi.mount @15.389s +310ms
              └─systemd-fsck@dev-disk-by\x2duuid-1860\x2d9879.service @14.786s +574ms
                └─dev-disk-by\x2duuid-1860\x2d9879.device @14.785s

Any guidance is really appreciated.

Regards, Abbas.

When I checked my system's boot logs, I noticed that each of the dev-loopx.device takes a good 3-5 seconds to boot, and I have a total 20 such loopx devices lines up during my boot, which ultimately slows down my boot.

To get further details on these loopx devices, I ran the following command

$ df -a -h -T

And the most important part of the output was:

Why are some applications (or part of them) is being loaded during boot, which I don't even use in every session?

For example, the gaome-calculator application, the gtk-common-themes, the gnome-system-monitor.

Why are there multiple entries of some of the applications (and each one of takes a good 3-5 seconds, and even more)?

How can I disable and/or remove some of these loopx devices when I don't use the associated application/services very often? This would definitely speed up my boot process!

Any help and guidance are really appreciated.

Abbas.

It seems that this bug is an old one, and a really persistent one, as has been reported by several users. It was also reported that the bug has been resolved in patch updates, but, somehow, I am still facing the same problem!

Machine: MSI GV62 7RD Processor: Intel® Core™ i7-7700HQ CPU @ 2.80GHz × 8 Graphics: GeForce GTX 1050/PCIe/SSE2 Operating System: Ubuntu 18.10 Kernel: 4.18.0-15-generic

Sorry about the limited details, but I am not Ubuntu expert (not a novice either).

I am filing this bug report as I was asked to file a new bug report.

Also, please note that I have already tried all the workarounds to this problem available on the internet (including disabling the Secure Boot from the BIOS as well completely purging and reinstalling the nvidia-driver-390), but nothing worked till now!

Expecting the Ubuntu team to resolve this soon.

With best regards, Abbas.

Edit: Found the latest driver, but couldn't install it!

After looking at Nvidia's official website, I found out that the latest driver they have release is 410.93. After downloading the .run file, I proceeded as follows:

1. Purged all Nvidia packages, including nouveau, as well as xorg.
2. Made the .run file executable.
3. Stopped the gdm service.

4. Tried to install it. Got stuck here:

5. Reinstalled all the dependencies of the driver package, as described here.

6. Repeated steps 3 & 4. Got the same response.

The installer gets stuck at 5% infinitely until the terminal window is forcibly closed.

Any idea what's going on?

Details!

Every time I run the installer (.run file), I get this prompt:

The distribution-provided pre-install script failed! Are you sure you want to continue?

Does this hold any significance?

Found the culprit!

Although I had all the dependencies installed already, as mentioned earlier, something definitely wasn't right! With this thought, I rechecked each of the dependencies through the commands mentioned on the same page. What I found was glibc could not be found, even when I had the latest version installed. I researched the internet and found that I am not the first one facing this issue, and the NVIDIA driver is not the first package making this mistake.

Actually, the NVIDIA driver was looking for glibc in

/lib/

While it was installed in

/lib/x86_64-linux-gnu

So, I solved the problem by creating a simlink, using the following command.

# ln -s /lib/x86_64-linux-gnu/libc-2.13.so /lib/libc.so.6

This allowed the installation to proceed beyond the 5% mark (where it was stuck, as reported in my last update).

A bigger problem!

Well, the driver installation proceeds beyond the 5% mark, but this doesn't lead to a happy ending! The installer concludes with the following message:

ERROR! Unable to load the 'nvidia-drm' kernel module. Installation Failed!

And..... I haven't been able to find a solution to this, yet!

Reply to heynnema's reply #2

I even tried the latest version (418.43) and that also fails with the exact same message.

A good news!

I think it must be reported that I do not see any pkcs #7 messages at the startup anymore. Though I am not sure which of my experiments cured it!

Another attempt

I even tried the latest NVIDIA-Linux-x86_64-418.56.run.

I would also like to mention that I am trying to install the drivers in rescue.target in order to avoid any conflicts with the running applications.

This time, the ERROR: Unable to load the 'nvidia-drm' kernel module message was accompanied with a bit more detail.

[227.245253] CPU4: Core temperature above threshold, cpu clock throttled (total events = 1)
[227.245255] CPU4: Package temperature above threshold, cpu clock throttled (total events = 1)
[227.245258] CPU6: Package temperature above threshold, cpu clock throttled (total events = 1)
[227.245260] CPU5: Package temperature above threshold, cpu clock throttled (total events = 1)
[227.245260] CPU1: Package temperature above threshold, cpu clock throttled (total events = 1)
[227.245261] CPU2: Package temperature above threshold, cpu clock throttled (total events = 1)
[227.245262] CPU7: Package temperature above threshold, cpu clock throttled (total events = 1)
[227.245263] CPU3: Package temperature above threshold, cpu clock throttled (total events = 1)
[227.245264] CPU0: Package temperature above threshold, cpu clock throttled (total events = 1)

It would be really great if someone could help me with this NVIDIA driver installation!

Best Regards, Abbas.

I am having real troubles sorting this out!

Why is the blkid output flooded with so many instances of /dev/loopx: TYPE="squashfs"?

No significant information is available on the internet!

Any help would be really appreciated.

Abbas.

I have been tirelessly trying to install Ubuntu-18.04 since the last 2 days, but every attempt turned out to be negative. Apart from other GUI based problems, which I am reporting here.

When mounting the ISO using the inbuilt Disk Image Mounter utility, and attempting the GUI base upgrade method (from within Ubuntu-16.04.1).

I get a pop-up saying

Oops! There was a problem running this software. Unable to locate the program.

When mounting the ISO and attempting an upgrade through the terminal, the gksu sh /cdrom/cdromupgrade command leads to a blurred screen prompting for the password and then does nothing. Replacing gksu with sudo returns cdromupgrade command not found.

When booting from a live flash drive (created from the same ISO), the installation freezes at the network page after I enter the password for my wifi. When using a wired connection, the network page does not appear. The installation freezes at the page where it asks for Normal or Minimal installation. It even has options for Install Updates and install Third-Party Drivers etc (the 3rd page of the installation). I have tried different combinations of options, but the installation never proceeds further. Sometimes, it even freezes at the keyboard selection page (the 2nd page of the setup).

I have already verified the integrity of the downloaded ISO through a checksum verification. It is perfectly OK.

Current OS: Ubuntu-16.04.1 (latest kernel, as per apt-get) Machine : MSI GV62 7RD