Fixing Mint partition with GParted [CHANGED TITLE]

[Halvor Raknes]

Following step-by-step the instructions at https://gparted.org/display-doc.php?name=help-manual&lang=C#gparted-fix-grub-boot-problem I get an error at section 5.

The partition (containing Mint 19.3) that I am trying to fix is at /dev/sda8. As I read the instruction I shall then enter grub-install /dev/sda (I also tried with sda8, but got the same result) and this was the output:

root@ubuntu:/# grub-install /dev/sda Installing for x86_64-efi platform. grub-install: error: cannot find EFI directory.

As the instructions have no mention of this possibly happening and what to do then, I ask here!

(This issue comes on the back of this thread)

 

[DexTheDog]

Is the Linux install legacy?

 

[Halvor Raknes]

Is the Linux install legacy?

As I wrote, it is Linux Mint 19.3. I'm not sure that is what you're asking. Please clarify (as maybe I should remain in the Beginners Forum…)

 

[dos2unix]

As I wrote, it is Linux Mint 19.3. I'm not sure that is what you're asking. Please clarify (as maybe I should remain in the Beginners Forum…)

Not all computers use EFI. Some older ones use BIOS. What is the output of
df -h

 

[Halvor Raknes]

What is the output of
df -h

Filesystem Size Used Avail Use% Mounted on /dev/sda8 146G 128G 5.2G 97% / udev 1.9G 0 1.9G 0%

also, the outpur of ls /sys/formware/efi confirms that the system uses UEFI. (I checked how to check)

 

[captain-sensible]

in theory - unless hard drive has been wiped , then there will be no /sys/firmware.


You can also install dmidecode pkg from your repo and run :

[andrew@darkstar:~][1]$ sudo  dmidecode 3.0 | grep '64'                   (12-21 19:33)
    Runtime Size: 64 kB
        64-bit capable
[andrew@darkstar:~]$

let me also throw this in I had some trouble re-installing grub to an uefi PC; i got success by booting Slackware live from a usb stick then :

mount      /dev/mmcblk0p2         /mnt  
mount   /dev/mmcblk0p1          /mnt/boot/efi
mount --bind /dev   /mnt/dev &&
mount --bind /dev/pts  /mnt/dev/pts &&
mount    --bind /proc /mnt/proc && 
mount --bind  /sys  /mnt/sys
# chroot /mnt
grub-install --target=x86_64-efi  /dev/mmcblk0
# grub-install --recheck /dev/mmcblk0
# grub-mkconfig -o /boot/grub/grub.cfg

above is for endeavour , an Arch based system but there are a couple of things that may be in common


eg

mount   /dev/mmcblk0p1          /mnt/boot/efi
// here /dev/mmcblk0p1   is my fat32 efi partition , and i mount it to /mnt/boot/efi

 

[dos2unix]

Normally you will see a EFI partition

#> df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 32G 0 32G 0% /dev
tmpfs 32G 67M 32G 1% /dev/shm
tmpfs 13G 1.9M 13G 1% /run
/dev/nvme0n1p4 30G 16G 15G 52% /
tmpfs 32G 544K 32G 1% /tmp
/dev/nvme0n1p3 1.3T 73G 1.3T 6% /home
/dev/nvme0n1p5 20G 2.2G 18G 11% /var
/dev/nvme0n1p7 510G 3.6G 507G 1% /space
/dev/nvme0n1p2 2.5G 295M 2.3G 12% /boot
/dev/nvme0n1p1 197M 6.1M 191M 4% /boot/efi

#> mount | grep efi
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
/dev/nvme0n1p1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=winnt,errors=remount-ro)

 

[Halvor Raknes]

You can also install dmidecode pkg from your repo and run :

$ sudo dmidecode 3.2 |grep '64' Runtime Size: 64 kB Maximum Capacity: 64 GB Total Width: 64 bits Data Width: 64 bits Data Width: 64 bits 64-bit capable

I'm sorry for being unable to relate to the rest of your reply. If it is necessary please advice what info or actions you would need from me!

Also, I didn't get why you needed the output from the dmidecode command in relation to the subject of my overall request for help, so please, if you could explain that to me!

 

[Halvor Raknes]

Normally you will see a EFI partition

#> df -h
.
.
.
#> mount | grep efi

$ df -h Filesystem Size Used Avail Use% Mounted on udev 1.9G 0 1.9G 0% /dev tmpfs 381M 12M 370M 3% /run /dev/sdb1 2.9G 2.9G 0 100% /cdrom /dev/loop0 2.1G 2.1G 0 100% /rofs /cow 1.9G 974M 930M 52% / /dev/disk/by-label/writable 12G 42M 11G 1% /var/log tmpfs 1.9G 0 1.9G 0% /dev/shm tmpfs 5.0M 8.0K 5.0M 1% /run/lock tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup tmpfs 1.9G 500K 1.9G 1% /tmp /dev/loop1 56M 56M 0 100% /snap/core18/2128 /dev/loop5 33M 33M 0 100% /snap/snapd/12704 /dev/loop3 51M 51M 0 100% /snap/snap-store/547 /dev/loop4 66M 66M 0 100% /snap/gtk-common-themes/1515 /dev/loop2 219M 219M 0 100% /snap/gnome-3-34-1804/72 tmpfs 381M 104K 381M 1% /run/user/999 /dev/loop6 56M 56M 0 100% /snap/core18/2253 /dev/loop7 44M 44M 0 100% /snap/snapd/14295 /dev/loop8 219M 219M 0 100% /snap/gnome-3-34-1804/77 /dev/loop9 62M 62M 0 100% /snap/core20/1270 /dev/loop10 55M 55M 0 100% /snap/snap-store/558 /dev/loop11 248M 248M 0 100% /snap/gnome-3-38-2004/87 /dev/loop12 128K 128K 0 100% /snap/bare/5 /dev/loop13 66M 66M 0 100% /snap/gtk-common-themes/1519


$ mount |grep efi efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)

 

[Halvor Raknes]

To clarify, the last two replies from me to captain-sensible and dos2unix, respectively, shows output from a straight boot with the memory stick. The outputs that I have shared in comments above these are from booting with the memory stick and the going through steps 3, 4 and 6 of the GParted Manual. The manual is actually confusing me as it asks:

Determine which partition contains the / file system for your GNU/Linux distribution.

Use GParted to list the partitions on your disk device. Look for a partition that contains your GNU/Linux / file system.()99

I have two (three) partitions now with "/" file systems; the one relating to the present boot via memory stick and the Linux Mint 19.3 which I am trying to fix (as well as a newly created Ubuntu 20.04 LTS partition))

 

[captain-sensible]

ok I had a check look at your previous post and probably its a good time to clarify things, with your help .
When you had your laptop with windows on all you had to do was get an external hard drive with Fat32 and i think that would have been ok to back data stored on a ntfs file from your PC system to Fat32 on external drive. Although its been a while since i used Windows

I'm almost certain your PC is uefi . it looks like you have booted from a linux OS on a usb. it would be good to get a screen shot using the live OS of your PC , on your live OS open up gParted and use drop down to get gParted to show your PC partitions, should be fairly obvious from size which are which . Then take a screenshot of your PC partitions. So you did once have i'm sure, an efi partition of type Fat32 and thats going to be involved in the install step of grub.


One approach is going to be using a live Linux OS from a USB. you would mount the PC partition if you still have one and I think the main linux install partition , you then chroot the mounted partiton which means that when you use a shell terminal it would be as if you had booted from Linux OS and where using a terminal from your running PC linux OS. Thats the essence of chroot. So you would be able to re-install grub package if you need to but also install grub. Now I think your Linux is Mint , so Mint guys will have to come in on this , but on Arch the install of grub is like :

grub-install --target=x86_64-efi  /dev/mmcblk0

in the above its telling grub that the efi partition is /dev/mmcblk0

regarding dmidecode that was just giving you an alternative eg also to check for uefi eg

[andrew@darkstar:~][1]$ sudo dmidecode 3.0 | grep 'UEFI'                  (12-22 14:19)
        UEFI is supported
[andrew@darkstar:~]$

 

[Halvor Raknes]

In principle, there will be no /sys/firmware unless the hard drive has been cleaned.

From what I have shared already there clearly is a /sys/firmware/ and the hard drive has not been cleaned (if by 'cleaned' you mean deleted).

You may also use your repo to install dmidecode package and execute it.

As I have shared already I do have dmidecode and I have shared the output from it.

 

[Halvor Raknes]

ok I had a check look at your previous post and probably its a good time to clarify things, with your help .
When you had your laptop with windows on all you had to do was get an external hard drive with Fat32 and i think that would have been ok to back data stored on a ntfs file from your PC system to Fat32 on external drive. Although its been a while since i used Windows

Sure, but my predicament was that I didn't have sufficient storage media to backup those files. In any case, I had decided I was getting rid of Windows, so I went ahead and deleted Windows OS files. Then I proceeded to consolidate the numerous partitions using GParted. And, as I have described initially, it was during these actions that the Linux Mint partition would no longer boot. And at that time I had no other OS installed and no usb live OS either. It was only when I managed to find someone who could make me a usb live Ubuntu 20.04 LTS that I could go on with the matter of attempting to fix the broken boot of the Linux Mint OS. And then I stumbled into the issue which is described in the first post in this thread,

I'm almost certain your PC is uefi . it looks like you have booted from a linux OS on a usb.

Indeed I have. I have stated so on many occasions throughout this thread, I believe.

it would be good to get a screen shot using the live OS of your PC , on your live OS open up gParted and use drop down to get gParted to show your PC partitions, should be fairly obvious from size which are which . Then take a screenshot of your PC partitions. So you did once have i'm sure, an efi partition of type Fat32 and thats going to be involved in the install step of grub.

SDA8 is the troubling Linux Mint partition.

One approach is going to be using a live Linux OS from a USB. you would mount the PC partition if you still have one and I think the main linux install partition ,

Isn't that what I have described doing following the GParted Manual?

you then chroot the mounted partiton which means that when you use a shell terminal it would be as if you had booted from Linux OS and where using a terminal from your running PC linux OS. Thats the essence of chroot. So you would be able to re-install grub package if you need to but also install grub. Now I think your Linux is Mint , so Mint guys will have to come in on this , but on Arch the install of grub is like :

grub-install --target=x86_64-efi  /dev/mmcblk0

in the above its telling grub that the efi partition is /dev/mmcblk0

regarding dmidecode that was just giving you an alternative eg also to check for uefi eg

[andrew@darkstar:~][1]$ sudo dmidecode 3.0 | grep 'UEFI'                  (12-22 14:19)
        UEFI is supported
[andrew@darkstar:~]$

 

[captain-sensible]

ok great now you need to have a little more patience with me, the others on here know why ..so Mint is /dev/sda8
and whats on /dev/sda6 and /dev/sda5 ?

 

[Halvor Raknes]

ok great now you need to have a little more patience with me, the others on here know why ..so Mint is /dev/sda8
and whats on /dev/sda6 and /dev/sda5 ?

No, that's all fine. The possibilities for ambiguities here are legion.

sda6 is Ubuntu 20.04 LTS (not live, so I have two copies of this OS, one on sda6 and one on the live usb).
sda5 only contains data that I moved over from the ntfs partitions that are now gone, almost exclusively media files.

 

[captain-sensible]

ok a couple of ideas :

unallocated + /dev/sda5 equals circa 187.31 gig a fair size to install another OS. So if you used gParted from a live Linux OS on a usb , delete /dev/sda5 then format the remaining space of unallocated and /dev/sda5 which will also be unallocated . Now some Linux SO , slackware for instance doesn't need extra home , it only needs on a uefi an efi , you have that and one partition for root install. If you boot up from a usb a Linux OS of your choice , then on Desktop click install and install to the new partition of unallocated , then if the grub install goes ok , before re-booting you then run

sudo update-grub

that should add Mint on /dev/sda8 to the grub boot options. So on re-booting you should then be able to boot from either the new OS or the old Mint .if The old Mint doesn't boot up from the newly installed grun menu , then its worth a try using fsck - but lets leave that for now.


That way you have two OS and the new one should set up grub and update it to include the old OS. Now i'm a bit vague on choices but if at the install grub stage, it mentions uefi then choose that .

One other possibility is that as long as /dev/sda8 partition is not corruped then I think you can get that up , using rEFInd i've tested that on Both Windows10 and Slackware boxes abd it can get then up . Download here :

https://sourceforge.net/projects/refind/files/0.12.0/refind-flashdrive-0.12.0.zip/download

You will have to after unzipping dd the img file , to a usb, then boot from that usb and see what options it gives you. if you can get Mint up, then you can have another go -re-installing grub and installing to efi. Then you can still have the option of installing another OS .PS i'm om Arch and have a hd with only 60 gig but i have an SD slot , which gets changed a lot!

 

[captain-sensible]

Don't know where all the Mint / Debian derivative guys are .. maybe they all switched to Arch ?

 

[Halvor Raknes]

ok a couple of ideas :

unallocated + /dev/sda5 equals circa 187.31 gig a fair size to install another OS. So if you used gParted from a live Linux OS on a usb , delete /dev/sda5 then format the remaining space of unallocated and /dev/sda5 which will also be unallocated . Now some Linux SO , slackware for instance doesn't need extra home , it only needs on a uefi an efi , you have that and one partition for root install. If you boot up from a usb a Linux OS of your choice , then on Desktop click install and install to the new partition of unallocated , then if the grub install goes ok , before re-booting you then run

sudo update-grub

that should add Mint on /dev/sda8 to the grub boot options.

Mint is already among the grub boot options. The problem that started this was described in the other thread to which I have provided a link in the first post in this thread. However, I suppose it suffices to recount that the Mint boot halts with the following appearing:

You are now in recovery mode. After loggin 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): <blinking cursor>

more details about what happens when I choose the various options there are described in this comment in that thread.

 

[Halvor Raknes]

I have changed the title of the thread because I sense that the basic problem I came here to find assistance with seems to go largely unnoticed and the solutions and directions being suggested to me don't address the issue with attempting to following the instructions in the GParted Manual for Fixing Operating System Boot Problems.

Now I am starting to suspect that the problem doesn't lie with GRUB 2 but arises later in the boot sequence.

As I have now managed to parse the output of journalctl -xb to a file,

I will close this thread and open a new thread at the linuxmint.com forum: Mint 19.3 boot halts after work with GParted