Is new kernel faulty ??

[Schwarzer Kater]

550MB is not necessary at all for /boot/efi. We are talking about /boot/efi here - a partition for EFI only - not a seperate /boot partition.

304 or 320MB is a better and also sufficient size (bigger than 300MB, because there are installers/distributions out there that demand at least that size - for whatever reason, because there is no technical one AFAIK…). This way you are set for the future and this is why I recommed this size.

Practical examples concerning the "necessary" size of an EFI partition:

• Not even 90MB of the EFI partition would be used for 15 different systems including Windows ("secure boot" disabled).
• If one installs Windows first on a disk and lets Windows do the partitioning, as many people do, the EFI partition would be 100MB. This is more than sufficiant for a simple dual-boot installation with Linux (letting the installers/distributions aside that demand 300MB as mentioned above).

[stuarte]

Good morning all,

@Schwarzer Kater: No to bootable/install usb stick but yes to bootable/install dvd for Kubuntu 20.04.1. I carried out your suggestions for both lsblk and fsck. I also executed fsck twice. The first run fixed the problem and the second run stated that the partition was clean. Ultimately, this turned out to be such a simple fix.

I would like to express my gratitude to all(!) who have helped with this.

Update: Using the "live" distro, I used the Startup Disk Creator to set up my 8GB flash stick as bootable with Kubuntu 22.04.2 LTS. Using this I attempted to install 22.04 onto the laptop hdd. After the installer "verified" which partitions were to be set up, it informed me that as I had not specified an EFI partition the system might not boot. This turned out to be the case. I have just done a web search for appropriate size for efi partition and found a suggested size of 550 MB, as suggested at boot - How to know the proper amount of needed disk space for EFI partition - Ask Ubuntu. So I guess that is what I will use.

This will be easily fixed, now that I have a bootable usb stick. :-)

Once again, my thanks to all who have helped. It is very much appreciated.

Stuart

[Schwarzer Kater]

I understand you have no bootable USB stick but a bootable DVD?
Then boot from that DVD into a "live" session (choose "Try Kubuntu"). The example below is for booting from a Kubuntu 22.04 installation medium (if you boot from 20.04 you can leave out the "-e7" in lsblk, the rest remains the same).

Open the Konsole terminal emulator.
lsblk -f -e7 to determine the name of the partitions you want to check/repair.

sudo fsck /dev/name_of_the_partition_you_want_to check_and_repair - e.g. sudo fsck /dev/sda3 - and confirm the changes/repair fsck wants to do.
If fsck could repair the partition(s) do it again to be sure there is no additional corruption.

See fsck --help for a short list of options or man fsck for the man pages (or man fsck.file_system_type for the different file systems - e.g. man fsck.ext2 for ext2-4).

[stuarte]

Hi,

@Snowhog: wrt post 20, the installer was set to not(!) format /home, just to mount it..

@Schwarzer Kater: wrt post 21, I tried using fsck. It did not work. Please see my response to claydoh in post 19. /home contains things I would like to keep so I would very much not like to set up a new gpt partition table.

Stuart

[Schwarzer Kater]

[…]
"/home: Inodes that were part of a corrupted orphan linked list found."

Could this be fixed running fsck ? I might be able to do this using the Kubuntu 20.04.1 install dvd (I hope) in "live" mode.
[…]

[FAILED] Failed to start File System Check on /dev/disk/by-uuid/05fc8b01-a330-4c74-91ed-77f37aa16a9c.
[DEPEND] Dependency failed for /home.
[DEPEND] Dependency failed for Local File Systems.

Stuart

You definitely should try repairing your file system with fsck (for example from a "live" environment).
These are file system errors.

If there is no important data at all on your disk, alternatively you could also install a new gpt partition table (which will "wipe everything" on the disk!), and re-partition and format the drive afterwards.
Then the file system errors will also been gone (unless your disk is electronically/physically damaged "beyond repair" - what is very unlikely and is at least not reflected by those error messages).

PS: I think screenshots are not necessary anymore - it is quite clear where the problem is.

[Snowhog]

Are you having the installer format /home, or leaving /home intact?

[stuarte]

Good afternoon all,

The saga continues. I have just re-installed Kubuntu 20.04.1 LTS and as soon as I booted into that I was dumped directly into emergency mode with the following text.

"You are in emergency mode. After logging in, type "journalctl -xb" to view system logs, "systemctl reboot" to reboot, "systemctl default" or "exit" to boot into default mode.
Press enter for maintenance
(or press Control-D to continue):"

I did the "journalctl -xb" and, after single-stepping through the log, found that:
"/home: Inodes that were part of a corrupted orphan linked list found."

So, from this, it would seem that there is a breakage in a /home linked list of Inodes.

Could this be fixed running fsck ? I might be able to do this using the Kubuntu 20.04.1 install dvd (I hope) in "live" mode.

@claydoh: wrt post 17 above:
I finally got into the grub menu, into recovery mode and then into a command line. I then tried to do an fsck on the hdd with the following results.
root@kub-SATELLITE-L870-18V:~# sudo fsck /dev/sda
fsck from util-linux 2.34
e2fsck 1.45.5 (07-Jan-2020)
/dev/sda is in use.
e2fsck: Cannot continue, aborting.


root@kub-SATELLITE-L870-18V:~# umount /dev/sda
umount: /dev/sda: not mounted.
root@kub-SATELLITE-L870-18V:~# sudo fsck /dev/sda
fsck from util-linux 2.34
e2fsck 1.45.5 (07-Jan-2020)
/dev/sda is in use.
e2fsck: Cannot continue, aborting.

I have no idea about the contradiction shown above. The commands were entered one immediately after the other as shown above.

@Schwarzer Kater: wrt post 18 above:
I performed the "sudo less -R /var/log/boot.log" and found the following.

[FAILED] Failed to start File System Check on /dev/disk/by-uuid/05fc8b01-a330-4c74-91ed-77f37aa16a9c.
[DEPEND] Dependency failed for /home.
[DEPEND] Dependency failed for Local File Systems.

No, the partitions are not encrypted. No, I(!) did not change my partitions/mount points. No, I cannot boot from an external device/USB stick as I do not have one.

Screenshots are not available as I do not have a working camera(phone).

I re-installed Kubuntu 20.04.1 LTS with the hope of turning an old 8 GB flash drive into install medium. It has not worked out that way.
BTW, how big would a USB stick need to be in order to be usable as bootable medium ?

Stuart

[Schwarzer Kater]

[…]
Currently, the system displays a lot of white text on a black background. Some of this text is preceded by a green OK in square brackets at the beginning of a line. On two lines, these square brackets have the word "DEPEND" within them. I think one of them refers to /home and possibly refers to not being able to access/satisfy a dependency for the /home partition. What the other "DEPEND" refers to I cannot say as this text scrolls upscreen far to quickly to be read.[…]

This should actually mean you have passed GRUB…
Does the boot process take much longer than usual?
Can you spot an entry with [FAILED] in front of it? And if you can, what does it say?
What do the [DEPEND]… entries exactly say?

Are your Linux partitions encrypted?
Did you (or "something") recently change anything regarding your partitions/mount points? If so the entries in /etc/fstab could be wrong now and the system could refuse to boot.
Just guessing here again, of course.

To begin with you could also boot from an external device/USB stick and do an fsck on your Linux partitions to rule out plain file system corruption.

Screenshots could be helpful…

PS: If you could somehow get to a prompt you could sudo less -R /var/log/boot.log to view the boot messages again.
You could also read the boot log of your main system when booted from another device - you would have to mount your main system's / first etc., of course.

[claydoh]

Even more currently, the screen is, right this second, displaying a light blue (dos/ansi?) graphics screen showing a centrally located white box (with drop shadow) labelled "Recovery menu (filesystem state: read-only)". However this menu does not respond to the arrow keys and so I am not able to access the commands (clean, dpkg, fsck, grub, etc) on this menu.

I don't know why you are automatically booting to the recovery mode, let alone why it would be frozen and unresponsive. You are not getting a grub menu at all?
If you normally don't, you might try hitting <shift> just past the initial power-on splash screen. You can select different kernels there.

if you can't, you may need to use a live session and run boot-repair, or try a grub boot/rescue disk.

the system has been set to use a legacy CSM BIOS boot up. Could it be that this all-but-deprecated boot up process is part of the problem ?

Probably not in and of itself. But a broken or corrupted MBR is no fun.
UEFI doesn't use an MBR, but a normal FAT32 directory to house each OS's boot loader files.
I find UEFI more stable than I remember the legacy to be.

When running the system in CSM, you are actually emulating the old BIOS-style firmware.

But it really doesn't matter, though, in most situations. There is no compelling reason to switch unless one is starting completely from scratch, I think.


I do suspect a broken grub or MBR, and I think the repair tools may be useful.

[stuarte]

Good morning all,

@ Schwarzer Kater: I tried the steps 1 and 2 you gave in post 3 above. Sadly, they did not help. I was still dropped into the emergency mode. It would clearly seem that @claydoh was correct (and therefore I was clearly wrong) in that the system was not actually booting the kernel.

@ claydoh: with respect to post 5 above, yes the system has been set to use a legacy CSM BIOS boot up. Could it be that this all-but-deprecated boot up process is part of the problem ?

Currently, the system displays a lot of white text on a black background. Some of this text is preceded by a green OK in square brackets at the beginning of a line. On two lines, these square brackets have the word "DEPEND" within them. I think one of them refers to /home and possibly refers to not being able to access/satisfy a dependency for the /home partition. What the other "DEPEND" refers to I cannot say as this text scrolls upscreen far to quickly to be read.

Even more currently, the screen is, right this second, displaying a light blue (dos/ansi?) graphics screen showing a centrally located white box (with drop shadow) labelled "Recovery menu (filesystem state: read-only)". However this menu does not respond to the arrow keys and so I am not able to access the commands (clean, dpkg, fsck, grub, etc) on this menu.

I am now hoping to download a fresh copy of Kubuntu 22.04 LTS and "burn" this to an 8 GB flash drive. The BIOS in the laptop has USB set as the second boot drive.

Stuart

[claydoh]

So your thought in post # 5 is probably right and it could be MBR/BIOS.

More off-topic:

To install something from foo-backports (NOT related to the kubuntu-backports PPA in any way):

sudo apt install -t RELEASE-backports $PACKAGENAME

Moar infoses and stuffs (a little outdated in spots): https://help.ubuntu.com/community/UbuntuBackports

[claydoh]

However:

$ apt policy memtest86+
memtest86+:
Installed: 5.31b+dfsg-4
Candidate: 5.31b+dfsg-4
Version table:
6.10-4~bpo22.04.1 100
100 http://us.archive.ubuntu.com/ubuntu jammy-backports/main amd64 Packages
*** 5.31b+dfsg-4 500
500 http://us.archive.ubuntu.com/ubuntu jammy/main amd64 Packages
100 /var/lib/dpkg/status

​

Since jammy-backports are enabled by default in *buntu, and I definitely have it enabled.
Odd (and off-topic)

My 22.04 setup is 100% stock, with very little to no extra software or PPAs installed, even.

Oh, it came from backports? This could be the explanation why not everone has gotten it in 22.04 - because I have set backports to Pin-Priority: 500 on my machines.

Yeah, makes sense, though I don't remember that one needed to do this. Though it is not a topic I would pay attention to.

[Schwarzer Kater]

Oh, it came from backports? This could be the explanation why not everone has gotten it in 22.04 - because I have set backports to Pin-Priority: 500 on my machines.

So your thought in post # 5 is probably right and it could be MBR/BIOS.

PS: the default priority of *Ubuntu backports is 100.

[claydoh]

I have gotten Memtest86+ independently on three machines here at home in Kubuntu 22.04

I am not seeing it as I have not updated grub in a bit, I assume. I definitely do NOT have it in my grub menu.

[claydoh]

https://packages.ubuntu.com/jammy/misc/memtest86+

Wrong link , yours is for the OG version, which definitely does not support UEFI.
6.10 is in jammy-backports:

https://packages.ubuntu.com/jammy-backports/memtest86+