20.04 Save working configuration and make it default configuration for next boot

[s1van]

(Resolved)

I installed focal fossa a week before its release, updated it. Boot issues relate to graphics card / monitor, and there are related display issues such as overlapping/corrupt graphics, unavailable processing power etc. However, intermittently the boot sequence leads to a 1024 resolution and some other configuration settings which results in a clean, working desktop environment. While I try to troubleshoot the graphics card / monitor and bios issues on this 12 year old hardware, is there a way of "freezing" the working configuration / "saving" this 'last-known good' configuration and ensure that the computer boots in the exact boot sequence that worked on this boot instance? I am on this clean desktop environment at the moment.

(posted in the wrong forum a moment ago, brought it here, apologies for repetition if seen already)

Thank you.

[dino99]

Can you tell us :
- which kind of gpu/igpu is it, and which driver is installed ? from which source ?
- which flavour/DE/session is it ?

[s1van]

Dear Eoan

Thank you. I have pasted outputs of inxi -G, glxinfo -B, lspci (trimmed) and cat etc release

https://paste.ubuntu.com/p/PVn9KvMmYP/

Thank you.

[CelticWarrior]

Graphics: Device-1: NVIDIA C61 [GeForce 6100 nForce 405]
driver: nouveau v: kernel
Display: x11 server: X.Org 1.20.8 driver: nouveau,vesa unloaded: fbdev,modesetting resolution: 1600x900~60Hz
OpenGL: renderer: NV4C v: 2.1 Mesa 20.0.4

This is the problem and unfortunately there's nothing to do about it.
Support for this old (way older than 12 years, I'm afraid you're seriously mistaken) iGPU/chipset stopped many years ago (Ubuntu 12.04 already had issues with this hardware).
Debian or MXLinux should work more reliably in this hardware. Nothing of the Ubuntu family is guaranteed.

[s1van]

Dear Celtic Warrior

Would these help? There are three problems, I know that life will be easier with another motherboard, but to give it another try:
(there are problems with bios + nvidia + a samsung monitor, not counting complex problems with lshw and lspci outputs)

https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/701772

https://www.nvidia.com/en-us/drivers/results/153832/#

https://packages.ubuntu.com/focal/amd64/flashrom/download

[CelticWarrior]

No, unfortunately.

If there was a Nvidia (proprietary) driver that could be used instead of the generic nouveau I would have pointed you in that direction. There's isn't. There was many years ago but Nvidia then decided to end support entirely for legacy products. And it's the same in Windows where it works with the Microsoft Basic Display driver only (in Windows 10) and the same problems you're experiencing are to be expected if not even worse. Windows 7 with an old driver might still work but it no longer supported.

It has nothing to do with the monitor either.

And finally there's nothing to install that can improve the situation.

[s1van]

Dear Celtic Warrior,

Thank you for taking the time to make me understand that it wouldn't be useful to try and fix this computer. Thank you.

[s1van]

Continued working, realizing that the information I provided was incomplete (not unnecessarily verbose). There were other issues such as bad disk partition, the installation was on an extended partition etc. This is what I did over as many as a hundred reboots:



rearranged my partitions using gparted, copied / deleted and installed 20.04 in a primary partition
allocated about 10 GB of swap, wasn't working, now enabled it.
edited grub several times, seems to work better with nomodeset
updated to version 20.04 28, then to 20.04.29, but erased the initramfs entry
tried ubuntu drivers, then found nvidia 390 / 304 driver which suited this older version of graphic processor, installed it
tried again and again to add / set new name using xrandr, the command doesn't work
installed lightdm, without uninstalling gdm3


After all these steps, 20.04 28 works on this old hardware, resolution is most of the times 1024x780 which is ok, but there are two problems:

while booting these are the errors that cause boot delay, shown below from quick handwritten notes. (will copy and paste the output of any commands as required):

blk-update request I/o error, dev fd0 ....

(hangs for about a minute here, and then)

Gave up waiting for suspend/resume. (moves on)
<question 1> Is there a way to tell the computer not to wait for suspend/resume?

failed to start Tell Plymouth to write out Runtime data

(hangs again repeating the error for about a minute)

<question 2> forum threads on Plymouth did not help. Is there an effective way to tell Tell Plymouth not to try to start?

Dependency failed for /dev/drive ... for swap
(due to some error while enabling swap)

Boots after the delay, gdm/lightdm works with 1024, In this mode, there is at least a slow computer, most of the time, on some reboots, Ubuntu hangs:


Top shows 90+% processor usage by systemd+

<question 3> Is there a way to limit background processes during and after boot?

Thank you.

[s1van]

All these issues in a computer from 10 years ago, I switched, on the same machine to another hard disk of the same machine (because by error I deleted the partition table of the hard disk on which I had 20.04 with all the problems as above); This hard disk, on the same hardware, has a 10.04 installation which works perfectly alright, without any of these boot issues nor display issues. Nvidia driver is installed and works fine, samsung 2030 monitor works fine. Now the question is what is it that makes the same hard ware work in 10.04 but not 16.4 or in 20.4?

Is the Ubuntu code programming obsolescence in the process of coming up with new releases? Why isn't the code backward compatible? Or, is there some reason bugs (or untraceable erroneous code seep into the code, such as the Plymouth error or the stop - start - stop - start error or the nvidia peristence error?

(Is there a separate forum to discuss issues related to open source policy and practices? Thank you.

[oldfred]

If you have floppy drive enabled in BIOS, but no floppy drive, then BIOS writes that you have floppy drive, operating system tries to load it and has to time out on failure.
Or floppy drive is defective, not connected or some other issue.

I found boot to be a bit faster with this boot parameter: noplymouth
I replace quiet splash. You then do not get Ubuntu screen but see boot process scroll by. Same info that is in log file for boot.

If you reinstall, do second install or change partitions around, you may have UUID issue in fstab. It then has to search for UUID and timeout when not found. I used to use swap partition, and new install reformatted it, or really just changed UUID. But then other installs had issues as UUID was different. Check all the UUIDs in fstab, if slow boot.

I found my GT620 video card was slower than the internal video with my Intel Haswell chip.
But very old hardware often loses support as drivers are not updated.

[s1van]

Dear Oldfred,

Apologies for not having noticed your reply. I couldn't see an option in the forum settings to create an email alert.


If you have floppy drive enabled in BIOS, but no floppy drive, then BIOS writes that you have floppy drive, operating system tries to load it and has to time out on failure.

But the grub entry includes --no-floppy. Doesn't that fix it?


I found boot to be a bit faster with this boot parameter: noplymouth

Will replace quiet splash with noplymouth.


Check all the UUIDs in fstab, if slow boot.

Will do. Need some more guidance at the moment. I accidentally deleted the partition table, happened because I ran gparted, chose an unformatted partition in the hard disk, and tried to create a new partition table, mistaking that a partition table can be created within a partition. Within a moment understood that it is a process for the entire disk, but the table was gone already. I switch off the computer in an attempt to save further damage, now need to find a way to safely restore the partition table.

Thank you.

[oldfred]

If you had not shutdown system, partition table is still in RAM and possibly can be restored.
Have you run Boot-Repair? It has text info on exact start & size of every partition which can be used to restore partitions.
Otherwise testdisk or parted rescue may be able to restore partitions.

Used parted rescue
https://ubuntuforums.org/showthread.php?t=2362656
http://ubuntuforums.org/showthread.php?t=2315405
backup partition table before any changes, so you can get back to current if changes not correct
sudo sfdisk -d /dev/sda > PT_sda.txt
So you know sectors:
sudo parted /dev/sda unit s print

https://help.ubuntu.com/community/DataRecovery
http://www.cgsecurity.org/wiki/TestDisk
repairs including testdisk info & links
https://help.ubuntu.com/community/DataRecovery#Lost_Partition

[s1van]

Dear Oldfred,

Still haven't learnt to visit the forum regularly to check for updates. I am late by 3 weeks to reply to your helpful solution. Before applying the boot repair / parted solution to the disk ( I will get to it this week ), I installed a new hard disk, began by installing 16.04, first with an attempt at hard disk encryption, update to 18.04 showed lvm errors, did not proceed smoothly, deleted the crypt partition, re-formatted the entire hard disk, proceeded to reinstall 16.04 without encryption, update to 18.04 was smooth, and as a solution to the display issue, followed a post and installed xfce4 which resolved almost all of the hardware issues that I posted in this and other threads, same old hardware, same samsung 2030 monitor, same nvidia graphics. Then proceeded to update to 19.10, then to 20.4 all by update-manager. With xfce4 there was no need to attempt any fix, such as install an old nvidia driver, or to blacklist noveau, or even a nomodeset, there were no plymouth errors, Top, with no application running showed less than 5% CPU usage, display works at 1600x900 on its own, no boot issues. Then I purged unity (might be unnecessary, but ubuntu's login screen was pixelated before I strugggled a bit with the invisible cursor to type my password for a clean xfce environment), installed xubuntu desktop, purged mate, (mate loaded with a corrupt display).

20.04 with XFCE4, XUBUNTU desktop work splendidly with the same 10 year old hardware with limited resources, without any fixes.

Saying this,

(1) in a manner of withdrawing the few posts, that might have given a few readers the impression that 20.04 has some issues. The issues probably had to do with the path of trying upgrades from the unsupported 10.04 installation, by a complex path of installing drivers, enabling third party repositories, and trying any fix found in the forum such as grub edit, blacklist...

2) This might be helpful to some who reported display issues, plymouth issues on 20.04, the solution could be found in choosing a desktop such as xubuntu or LXDE.

3) In trying to find bug fixes for plymouth or or for some versions of nvidia, the developers may find it useful to focus on the reasons why some display manager work and others don't.

Thank you.