[SOLVED] Boot Up Problem 20.04

[stuarte]

Hi all,

I have been running Kubuntu 20.04 for some time without any problems. However, very recently, the system has shown corruption during boot up.

To try and help fix the problem I went into the GRUB edit screen, found the line that started with linux and replaced "ro quiet splash $vt_handoff" with "rw init=/bin/bash", and then pressed "Ctrl-x" to boot the system.

During that boot up I noticed that many lines of white text (but not all !) were right-shifted and preceded by many auto-inserted semicolons.

Has anyone ever seen this type of behaviour before and know how to correct it ?

I don't know if it is connected but on reaching the login screen, many characters are auto-inserted into the username and/or password text entry boxes.

Finally, when I was able to successfully login, the KRunner single line gui appeared at the top of the screen and auto-filled withe "dd"s. I know it was this command because on a rare occasion the KRunner gui expanded onto a second line and halfway along that line I saw the dd command.

As I have the 20.04 iso on dvd I could just re-install from that. However, I would not learn anything from doing so. It would mean losing, at least temporarily, all the updates and packages currently installed. For obvious reasons I would rather that not happen.

Best regards,

Stuart

[claydoh]

Why use the 'rw init=/bin/bash' instead of the normal recovery mode tools in grub? It is booting bash instead of the normal init, allowing for read/write earlier in the boot. ie full root and read/write access during boot, for debugging and editing purposes, and I am guessing is not meant for GUI usage on an actual desktop login. Usually just removing the "quiet splash" part of the boot parameter should show proper info for a normal bootup.

What exactly is happening during boot for you? What is meant by 'shown corruption' specifically? Is this odd graphical behavior happening on a regular boot up?

[stuarte]

Hi all,

@claydoh:

First, thanks for such a swift reply.

Why use the 'rw init=/bin/bash' instead of the normal recovery mode tools in grub? It is booting bash instead of the normal init, allowing for read/write earlier in the boot. ie full root and read/write access during boot, for debugging and editing purposes, and I am guessing is not meant for GUI usage on an actual desktop login. Usually just removing the "quiet splash" part of the boot parameter should show proper info for a normal bootup.

I was following the advice given in the article "Ubuntu 20.04 reset root password" located on website "LinuxConfig.org". Consequently I was aware that this would cause the system to boot into a bash-based cli environment. This was to be my first step in the process of diagnosing what the problem actually was/is. I was doing this as I was having problems logging in due to the system auto-inserting characters into the username and/or password text entry boxes shown in the gui-based login screen.

What exactly is happening during boot for you? What is meant by 'shown corruption' specifically?

Once I boot into the non-graphical environment, the usual white text appears and scrolls up the screen as usual. However, some of those text lines are offset to the right and preceeded by many semicolons auto-inserted by the system. This is what I meant in my original posting about showing corruption during (cli-based) boot up. To be fair, I had not made myself explicitly clear that I was booting into a cli-based environment. Please accept my apologies for that.

Is this odd graphical behaviour happening on a regular boot up?

On a regular boot up "quiet splash" are in effect so, in that situation, I don't get to see all that white text that scrolls up the screen during a non-graphical boot up being corrupted as I detailed in my original posting.

I hope that this has clarified the situation at least somewhat.

Best regards,

Stuart

[claydoh]

You might want to get a live usb and load that to check your drives for errors.

In your Kubuntu install, accessing recovery mode via the grub menus would have been the standard, official, and built-in way to gone to a root shell to do things like changing your password, check drives, etc.
You can do this from the live usb's grub menus.

[stuarte]

You might want to get a live usb and load that to check your drives for errors.

I have never made a live usb drive and so do not know how to set this up. Also I do not have nor can I afford to buy a spare usb flash drive that I can use for this.

In your Kubuntu install, accessing recovery mode via the grub menus would have been the standard, official, and built-in way to gone to a root shell to do things like changing your password, check drives, etc.
You can do this from the live usb's grub menus.

I believe that is what I did. If you check out the screenshots for step 1, step 2, and step 3 at https://linuxconfig.org/ubuntu-20-04...-root-password you will see exactly(!) what I did. At the end of step 3 I pressed "Ctrl-x" instead of "F10" to start the usual boot sequence, as it states in the bottom section of the screenshot for step 3.

I am thinking that there must be a corruption somewhere in the boot up scripts. I just do not know what that corruption is, what the contents of the uncorrupted scripts should look like, or where in the Kubuntu 20.04 install to look for those boot up scripts.

Best regards,

Stuart

[claydoh]

No, you did not access the built in recovery menu at all.
If you look at the Advanced options in the grub menu,m there is a sub menu for recovery mode, which has various options for things like a root shell, checking disks, etc.

It appears tome that one of the many dubious tips and tricks websites used some weird, but not necessarily inaccurate info that is doing things the hard way as opposed to the long standing built in way, and all the other janky websites simply copy-pasta the info. And in the process clogging google with this strange process.


If you have the install disk you used for kubuntu, whether a cd/dvd or USB flash drive, the same menu can be accessed from booting that.




This has been in Ubuntu since day one, and has never been any different.

[stuarte]

Hi claydoh,

Thank you for another very informative reply.

I have managed to enter recovery mode as you show in the screen shots in your latest reply.

I am currently working on using my mobile phone to capture exactjy what happens when I select either "grub update grub bootloader" or "fsck check all file systems" as shown in your last screenshot. Now that I have found the icon that allows a video file to be attached to a forum posting, I hope to have those files uploaded on either Monday or Tuesday of next week.

Do you happen to know the size restriction of such a video file ?

Is it allowed to have more than one video file attached to s single forum posting ?

Best regards,

Stuart

[stuarte]

Hi claydoh.

So, this morning I boot up the laptop into recovery mode ready to produce small videos of what has been happening. Even had the mobile phone set up ready to capture the errant behaviour. What happens ? The perishing machine boots up almost normally.

This posting, btw, was generated on the errant system, albeit with an external keyboard. I used this same keyboard last week and could not even login although I was (!) able to access the Recovery menu using this same external keyboard. This morning's misbehaviour consists of not being able to access the auto-repeat that occurs when a key is held down.

I still think that their is something weird with the boot up scripts. This morning, while the system is still running, I will go online and try to find out where in the /boot partition I will find the boot up scripts,

Anyway, thank you very much for your patience and all your help. It is very much appreciated.

Best regards,

Stuart