This procedure is a sequel to a previous thread, t=2462583, entitled
“Installing Ubuntu 20.04 Official Flavours on old PC’s which use nvidia-304
drivers”.
The test machine is HP Pavilion Media Centre m8247c which has the NVIDIA
GeForce 6150 SE Graphics card.
************************************************** **************
Because the test machine has a traditional legacy BIOS implementing disk
partitioning, it does not have a Reserved boot area required for the standard
EFI installation of Ubuntu 22.04 derivatives. Fortunately, a web video suggested
that to install a Ubuntu 22.04 derivative, the .iso should be loaded to modifiable
boot media such that the EFI directory can be deleted.
(I used the Unetbootin702-64bit software to load the Xubuntu-22.04.4 .iso to
a USB). On booting up from the USB and starting the installer, a warning
message appears about needing an EFI partition, but it can be ignored, and the
installation will complete normally.
With the installer, the minimal basic system configuration was chosen.
************************************************** **************
Choice of kernel for kernel downgrade
I was made aware by Robin, an antixforum expert, of the group of 10 patches
authored by Jorge Maidana which support installing nvidia-304 drivers up to
kernel level 5.6. The link to those patches is
This availability is significant because the ability to support the exFAT file system
for USB sticks was, if selected, made part of the Linux kernel starting with kernel
level 5.4. Such a capability is very desirable given the ever-increasing prevalence
of large video files and some remastered .iso’s which exceed 4GB in size.
A preliminary test was conducted with Bodhi-7.0.0 using the 5.6.17 kernel
met both requirements, the implementation of nvidia-304 drivers and the
mounting and read/write capability with exFAT USB sticks.
The hesitancy with the mainline kernels was that all kernels in the 5.4 to 5.6
range were designated as being in the test state; none were designated as stable.
It was considered important to use a kernel with a proven track record for the
intended purposes.
The LMXFCE-20.3 distribution used a 5.4 kernel, and having had a favourable
experience with it, I booted up the live DVD and attempted to sudo apt-get
download the installed linux-image package as the first step in assembling all
the packages relevant to the kernel. What was downloaded instead was the
file linux-image-unsigned-5.4.0-91-generic.tar.gz.
Unpacking the tarball produced a directory linux-image-unsigned-5.4.0-91-generic
with the following contents:
Code:
install.sh
linux-generic_5.4.0.187.185_amd64.deb
linux-headers-5.4.0-187_5.4.0-187.207_all.deb
linux-headers-5.4.0-187-generic_5.4.0-187.207_amd64.deb
linux-headers-generic_5.4.0.187.185_amd64.deb
linux-image-5.4.0-187-generic_5.4.0-187.207_amd64.deb
linux-image-generic_5.4.0.187.185_amd64.deb
linux-image-unsigned-5.4.0-91-generic_5.4.0-91.102_amd64.deb
linux-modules-5.4.0-187-generic_5.4.0-187.207_amd64.deb
linux-modules-extra-5.4.0-187-generic_5.4.0-187.207_amd64.deb
It seemed to be a very complete assembly of the kernel components with an
install script provided. The linux-image-unsigned package seemed to be a
redundant misfit with the rest of the modules, and after some trial-and-error,
the following kernel packages were installed:
Code:
crda_3.18-1build1_amd64.deb
install.sh
libssl1.1_1.1.1f-1ubuntu2.22_amd64.deb
linux-generic_5.4.0.187.185_amd64.deb
linux-headers-5.4.0-187_5.4.0-187.207_all.deb
linux-headers-5.4.0-187-generic_5.4.0-187.207_amd64.deb
linux-headers-generic_5.4.0.187.185_amd64.deb
linux-image-5.4.0-187-generic_5.4.0-187.207_amd64.deb
linux-image-generic_5.4.0.187.185_amd64.deb
linux-image-unsigned-5.4.0-91-generic_5.4.0-91.102_amd64.nopdeb
linux-modules-5.4.0-187-generic_5.4.0-187.207_amd64.deb
linux-modules-extra-5.4.0-187-generic_5.4.0-187.207_amd64.deb
wireless-crda_1.16_amd64.deb
The crda, libssl1.1, and wireless-crda packages were focal additions required to
complete the installation.
************************************************** ****************
NB: BEFORE installing the 5.4 kernel, it is essential to edit the
/etc/initramfs-tools/initramfs.conf file and change the parameter COMPRESS=zstd
to COMPRESS=gzip. Modern kernels use the former, but older kernels (eg. 5.4)
typically use the latter. Without this change, rebooting into the 5.4 kernel will fail,
and it is required for the sudo initramfs -u at the end of the driver install to work
correctly.
************************************************** ***************
Deleting Newer Kernels
After rebooting and selecting the 5.4 kernel, there were packages in 3 newer
kernels installed that were deleted, 6-level packages with synaptic, 5.15-level
with dpkg:
-with synaptic, completely remove linux-headers-6.8.0-generic, linux-headers-
6.5.0-generic, linux-image-6.8.0-generic, linux-image-6.5.0-generic, linux-
modules-6.8.0-40-generic
-sudo dpkg --remove linux-image-5.15.0-118-generic linux-generic linux-image-
generic linux-modules-extra-5.15.0-18-generic linux-modules-5.15.0-118-generic
-reboot: there should be only the 5.4 kernel left
-from command line,
sudo apt-mark hold linux-image-5.4.0-187-generic
sudo apt-mark hold linux-headers-5.4.0-187-generic
sudo apt-mark hold linux-modules-5.4.0-187-generic
sudo apt-mark hold linux-modules-extra-5.4.0-187-generic
-lock these same packages from synaptic
************************************************** ****************
Downgrade graphics (xorg) to bionic level
The procedure is as described in previous threads.
************************************************** ***************
Perform enigma9o7‘s “nvidia won’t install procedure, slightly modified.
************************************************** *******
NB - BEFORErunning enigma9o7‘s procedure, with the XFCE interface,
it is essential to disable the compositor and screen saver; if this is not done,
a blank screen will result when booting the system after completion.
(Having forgotten this step on several occasions: the after-the-fact correction
is to boot the system in command-line mode, and using the nano or other text
editor, access the /home/user/.config/xfce/xfce4/xfconf/xfce-perchannel-xml/
xfwm4.xml file, and change property use_compositing value to false).
************************************************** ***********
-The required components were assembled in a directory, /usr/share/NVIDIA5.4:
0001-disable-mtrr-4.3.patch
0002-pud-offset-4.12.patch
0003-nvidia-drm-pci-init-4.14.patch
0004-timer-4.15.patch
0005-usercopy-4.16.patch
0006-do_gettimeofday-5.0.patch
0007-subdirs-5.3.patch
0008-on-each-cpu-5.3.patch
0009-remove-drmp-5.5.patch
0010-proc-ops-5.6.patch
disable-nouveau.conf
NVIDIA-Linux-x86_64-304.137
NVIDIA-Linux-x86_64-304.137.run
(The NVIDIA-Linux-x86_64-304.137 directory is created after running
sudo NVIDIA-Linux-x86_64-304.137.run -x)
(enigma9o7‘s original procedure shows only one patch command:
in this case, the first 8 of Jorge’s 10 patches are run in succession immediately
followed by the sudo initramfs -u command).
************************************************** ***********
sudo ./nvidia-installer
Normally, in the nvidia-installer dialog, it’s best to answer yes/ok to every
prompt. In this case, 2 “no” reponses are required:
-re: registration of kernel with dkms
-re: version check of compiler being used to modify kernel versus
that of compiler used to build original kernel -- “no” means
carry on, don’t abort.
After installation, sudo lshw -C video and sudo inxi -Gxx commands confirm
that the nvidia-304 driver is in place
************************************************** ***************
Difficulty with remastering using systemback
On initiating a systemback live system create, systemback aborted almost
immediately with the message “critical changes in the file system”. Then,
firefox stopped working. A sudo snap remove firefox removed the snap
package, the firefox focal .deb package was downloaded on another distro,
transferred onto xubuntu 22.04.4 via a USB and local installed. The systemback
live system create process was restarted and ran to completion, producing a
3.99GB .sblive file.
************************************************** ****************
Systemback normally has an option in its interface to convert the .sblive file to an
.iso file, but it doesn’t work if there is insufficient space in the partition. The
amount of space required is 3 times the size of the .sblive file. For the systemback
run for live system create for xubuntu 22.04.4, this meant 3.99GB for the .sblive
file, another 3.99GB for the directory containing the de-compressed .sblive file,
and finally 3.99GB for the resultant .iso.
Fortunately, the systemback creator, Kendek, devised a procedure to allow moving
the .sblive file to another, larger partition, and completing the conversion to .iso
there. The procedure is described in the article
entitled “How to build more than 4GB Live System ISO for USB/CD/DVD of
Ubuntu 16.04 using systemback”. The title explains the true purpose of Kendek’s
procedure, but it is the solution to the insufficient space problem as well.
************************************************** ****************
When rebooting xubuntu-22.04.4 again in preparing to copy the .sblive file to a
usb, it seemed that the focal firefox version had been automatically replaced by
the firefox snap version. Again, sudo snap remove firefox.
Via a usb, I transferred in a copy of the latest seamonkey tarball, and installed
seamonkey to provide a working browser. I reran systemback live system create
again, and the resultant .sblive file was 4.7GB in size !??
Following the procedure in a web article, “Removing Snap Ubuntu 22.04 LTS”,
I removed all snaps, including snapd and reran systemback live system create.
An astounding result ! The resultant sblive file was 2.83 GB in size and was
converted to an .iso successfully in the confines of the current partition.
************************************************** ***********
A web browser using the google search engine (as Firefox does) is a useful
package. (Seamonkey uses DuckDuckGo). The latest opera-stable version
wouldn’t run properly when installed. I found that the newest opera-stable
version that would run properly on Rocky-8.10 was opera-stable-98. I
installed it on xubuntu-22.04.4 and it worked fine.
************************************************** **********
Given the peculiar manner in which the linux-image-unsigned-5.4.0-91-generic.tar.gz tarball was downloaded with the LMXFCE-20.3 live DVD,
I tried to replicate the download but could not. It turns out that the
user/group ownership of the tarball is systemd-coredump, which means the
original download attempt inadvertently caused an abnormal termination.
To guarantee a reliable kernel on any future xubuntu-22.04 customizations,
Len E.
Adv Reply
Bookmarks