Hello everyone, hope you all are doing good.
First of all, I need to get my Kubuntu installation fixed.
Second of all, I would appreciate it if someone can explain to me how to properly move and resize the partitions so it doesn’t break the install partition. I’m pretty experienced with computers, but all the various idiosyncrasies with storage drives are what I would call my achilles tendon.
Ubuntu Version: Ubuntu 25.04
Desktop Environment: KDE Plasma
Problem Description:
I have an issue with my Kubuntu install. I was using KDE Partition Manager to resize the Kubuntu partition to be larger (on a live install disk), but first the partition had to move to the beginning of the sector (I think thats how it works). I was a bit concerned that it had to shrink the partition before growing it, so I cancelled the operation, but the partition still moved to the beginning of the drive, and so when I rebooted all I saw was a GRUB prompt.
Relevant System Information:
I have a pastebin with the Boot-Repair info here: Ubuntu Pastebin
Screenshots or Error Messages:
GNU Grub version 2.12
Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists possible device or file completions. To enable less(1)-like paging, "set pager=1".
grub>
What I’ve Tried: Nothing aside from Creating a Boot Info Summary from the Boot-Repair utility.
Update: I have used the R-Linux utility to restore my file system on a new partition. As a result, the boot-repair utility output has changed. It looks like running it may fix my install. Here’s the new output: Ubuntu Pastebin
Welcome to Ubuntu Discourse 
Comparing the two pastebin outputs it certainly does appear that things have changed for the better.
The original one showed no OS installed (never a good sign).
As far as I can tell from the second output, if you run the recommended repair it should fix the issues and allow you to boot again.
If you run into more problems let us know but in any event if the outcome is a success, it would be great to know that too.
Good luck!
Thanks rubi1200. I ran the boot-repair utility and it gave me an error. Here are the results: Ubuntu Pastebin
It looks like there’s a lot of permission denied errors. Not sure how to go about dealing with that.
Line 80 from your latest report offers a suggestion:-
Please disable SecureBoot in the BIOS. Then try again.
Also, it may be worthwhile to disable TPM (or similar security options) before trying the recommended repair again.
1 Like
I disabled Platform Trust Technology and Secure Boot and this was the output: Ubuntu Pastebin
It looks like the message that has the Secure Boot is not present, but the error (126) still pops up at the end of the scan.
yancek
7
Your boot repair output shows a new uuid was created for partition 4 on the nvme drive with Kubuntu but your grub and fstab files still have the old uuid. line 231 in boot repair shows the correct uuid from the blkid output: nvme0n1p4 ext4 0d401b62-9b67-4f01-a760-6bcc5df64d73. This is not the uuid shown in either grub.cfg file or in the /etc/fstab file so try changing that and editing the files in /boot/efi/EFI/ubuntu/grub.cfg, /boot/grub/grub.cfg and /etc/fstab as root (using sudo) with whichever text editor you prefer.
2 Likes
I edited those files, but when I tried to boot, it gives me a kernel panic.
“Attempted to kill init! exitcode=0x00000100”
The boot repair doesn’t work either now. It says "Please enable a repository containing the [grub-efi-amd64-signed] packages in the software sources of Ubuntu 25.04 (/dev/nvme0n1p4). Then try again.
This is the output of the Boot info: Ubuntu Pastebin
Line 120:- 1:1049kB:263MB:262MB:fat32:EFI :boot, esp, no_automount;
I’ve never seen this no_automount
flag for an ESP before.
Using the partition editor, I would remove the no_automount
flag from the ESP.
Then, try the recommended boot-repair again.
Could be lucky, let’s see…
Sorry, which partition editor are you talking about? I think you mean changing the mount point on KDE partition manager, but it warns me that it will overwrite the existing file on my hard drive (I can only assume its the fstab file)
No, I didn’t mean changing the mountpoint, I was referring to the partition flags.
If you look at lines 144 - 146 of the latest boot-repair report, you’ll see that there is no entry for the ESP.
- Using Gparted > Right click partition > Manage Flags
- Using KDE Partition Editor > Right click partition > Properties > Flags at the bottom of the window
Now, I did an experiment and set my ESP with the no_automount
flag.
Using KDE Partition Manager in a “Try Lubuntu 24.10” live session, the flag was not listed.
Gparted shows the complete flag list (enabled and disabled)
You can install Gparted in a live session and try again
sudo apt install gparted
My observations about no_automount
involve a large amount of guesswork, so I’m not completely sure if my suggestion will help.
Finally, while you are using a "live"session, please backup your personal data (a re-install may be just around the corner)
I’m unfamiliar with R-Linux and I wonder what it actually did to your OS during the restore process.
1 Like
Yeah, unfortunately removing the flag didn’t fix the boot-repair. For context, I used R-Linux because the partition I had was completely corrupted and unusable, so I used R-Linux to retrieve my files from the end of the hard drive, which was where my files originally were, then reformatted the partition and moved my files there. That’s why boot-repair detected an OS in the second pastebin, but not the first one. So its likely not what R-Linux did to the files, but what the hard drive did. It was either that or photorec, but photorec is a complete mess for file recovery.
I gotta admit, its pretty disappointing that I have to reinstall just because I wanted more storage space, and simply moving the partition around and canceling the operation removed one partition and left me with a useless corrupted one. I figured that kind of activity was routine, but I suppose I was mistaken. Whats even worse is that every tutorial with fixing grub involves the chroot utility, but I kept getting the same errors as in the boot repair. It kept saying permission denied. Every single time.
I don’t even think fixing GRUB will solve my problem at this point, as a kernel panic sounds like an issue with the install itself. But even if I somehow figure out what causes the kernel panic, if I have an issue with GRUB in the future, its not like chroot is gonna work better just because the kernel panic is avoided.
Probably gonna switch to Debian or something.
Update 2: Looks like this is gonna be a reinstall.
I realized that when I recovered my files there was a TON of broken symbolic links just scattered around the file system. For whatever reason I cant imagine, some of the symlinks worked while others didn’t. I believe the cause of the broken symlinks was because when I recovered the files I copied them to an external hard drive before copying them onto the main hard drive, causing the symlinks to point to directories on my external drive, which obviously don’t lead anywhere. Now that I think about it, I might be able to modify my fstab to try and auto-mount the external drive just to see if it will boot, but at this point, I’m good. I did find out the cause of the kernel panic, at least. It was saying that the run-init process couldn’t execute /sbin/init: permission denied. I found this from editing my Kubuntu entry at boot time, getting rid of the “quiet splash” part of the boot command.
I’m glad at least through this roller coaster ride I was able to pick up and learn a few things along the way. Here’s to a more stable and solid future install. Its gonna be a lot easier this time since it’s not sharing a flat with Windows
1 Like
@takomaki Glad you got it sorted. I second @tea-for-one’s suggestion of installing gparted. Although I love Kubuntu, the gparted utility is far superior than kde’s utility and much more intuitive. After a fresh install, it’s the first thing I install, along with synaptic, l3afpad and kaffeine.
1 Like
system
Closed
15
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.