Long shut down (~3 min) and reboot, plus boot problems

you have 2 partitions EFI ,
can you return last one , under manjaro

sudo cat /etc/fstab
sudo lsblk -fs
1 Like

Hi Stephane. The HDD that all my operating systems are on is dsb. I take it that you are referring to partition sdb10. But I don’t know what you mean by “return” it? I have entered the two commands you sent in a terminal and here is the output. Is that what you wanted?

[martin@Martin-Manjaro-Desktop ~]$ sudo cat /etc/fstab
[sudo] password for martin:

tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
/dev/disk/by-uuid/1605ce13-d5a7-4588-9bad-ea6b472ad96a /mnt/1605ce13-d5a7-4588-9bad-ea6b472ad96a auto nosuid,nodev,nofail,x-gvfs-show 0 0
/dev/disk/by-uuid/0b530154-5ad9-496b-9b26-ec16cf4217a0 /mnt/0b530154-5ad9-496b-9b26-ec16cf4217a0 auto nosuid,nodev,nofail,x-gvfs-show 0 0
/dev/disk/by-uuid/dd9e48bf-75fd-4122-a68f-116314bac08a /mnt/dd9e48bf-75fd-4122-a68f-116314bac08a auto nosuid,nodev,nofail,x-gvfs-show 0 0
LABEL=Windows /mnt/Windows auto nosuid,nodev,nofail,x-gvfs-show 0 0
LABEL=BOOTEFI /mnt/BOOTEFI vfat umask=0077 0 2
LABEL=Manjaro\04020.0 /mnt/Manjaro\04020.0 ext4 defaults,noatime,x-gvfs-show 0 1
LABEL=Mint_20_Cinnamon /mnt/Mint_20_Cinnamon auto nosuid,nodev,nofail,x-gvfs-show 0 0
LABEL=Data /mnt/Data auto nosuid,nodev,nofail,x-gvfs-show,x-gvfs-name=Data,x-gvfs-icon=Data,x-gvfs-symbolic-icon=Data 0 0
UUID=19429b29-fa52-4671-86a7-733968f2fe77 / ext4 defaults 0 0
[martin@Martin-Manjaro-Desktop ~]$ sudo lsblk -fs
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
sda5 ntfs Data B850C07750C03DBE 714.6G 62% /mnt/Data
└─sda

sdb1 vfat FAT32 SYSTEM
│ 5A48-F327 12.8M 87% /run/media/martin/SYSTEM
└─sdb

sdb2
└─sdb

sdb3 ntfs Windows
│ 704A95D64A959A04 72.8G 51% /mnt/Windows
└─sdb

sdb4 ntfs Windows RE tools
│ 0E2C4BC02C4BA217 61M 88% /run/media/martin/Windows RE tools
└─sdb

sdb5 swap 1 855f4f5c-cd81-4ae1-8cdd-1afafb5772d8 [SWAP]
└─sdb

sdb6 ext4 1.0 MintKDE18.3Root
│ 1605ce13-d5a7-4588-9bad-ea6b472ad96a 67.8G 23% /mnt/1605ce13-d5a7-4588-9bad-ea6b472ad96a
└─sdb

sdb7 ext4 1.0 MintKDE18.3 Home
│ 0b530154-5ad9-496b-9b26-ec16cf4217a0 26.9G 76% /mnt/0b530154-5ad9-496b-9b26-ec16cf4217a0
└─sdb

sdb8 ext4 1.0 MintCinnamon18.3
│ dd9e48bf-75fd-4122-a68f-116314bac08a 43.9G 66% /mnt/dd9e48bf-75fd-4122-a68f-116314bac08a
└─sdb

sdb9 swap 1 9f251590-1722-47cf-a22c-5803566606c2
└─sdb

sdb10
│ vfat FAT32 BOOTEFI
│ BBF6-4F95 458.7M 10% /mnt/BOOTEFI
└─sdb

sdb11
│ swap 1 82fcc5b1-e3f9-4981-b227-697757080f73
└─sdb

sdb12
│ ext4 1.0 Manjaro 20.0
│ 19429b29-fa52-4671-86a7-733968f2fe77 76.2G 42% /mnt/Manjaro 20.0
│ /
└─sdb

sdb13
│ ext4 1.0 Mint_20_Cinnamon
│ 5e5cf470-6c81-41c3-90a0-3baa90260015 7.8G 65% /mnt/Mint_20_Cinnamon
└─sdb

for outputs, please use btn </> and not

1 Like

OK. Thanks Patrick. (I’m learning … slowly.)
Should I resend the previous output, or is it OK as it is?

so you have created on same disk a second UEFI
on sdb ( sdb1 windows 10 , sdb10 other linux and …maybe windows …)

you have 3 DE linux ( manjaro, mint20 cinnamon , mint 18. cinammon )
the last one DE linux installed was not manjaro , so you dont boot with a grub manjaro

1 Like

You are mostly correct, Stephane, except for your final conclusion. I do indeed boot with Manjaro grub.

The computer is about 5 years old and came with a 2 TB HDD loaded with Windows 10. I installed Linux Mint 18 Cinnamon as a dual boot with the Windows 10 installation, and created a separate NTFS partition in which all the data documents were kept so that they could be accessed by either Windows or Linux Mint. Windows10 use the first 4 separate partitions, sda1 to sda4, and then came the DATA partition, so it was sda5. The Mint 18 Cinnamon partition(s) came later. Then I decided to try KDE and liked it so I installed it, adding another couple of partitions. Then, a couple of years ago, I bought a 1 TB SSD, which became sdb. I transferred all the Op Systems to it and when they seemed to be working well on the sdb SSD, I wiped them from the sda HDD and expanded the DATA volume to use most of that drive. That is why it is still sda5, even though there is no sda1 to sda4.
After I installed Manjaro (on sdb12) and had been using Manjaro for some time, I installed Linux Mint 20 Cinnamon (on sdb13) - which I didn’t like much, so haven’t really used - and then OpenSuse KDE (on sdb14) - which I like quite a lot, but had even more troubles with than I had with Manjaro. (In fact, I can’t even boot into it right now. It always freezes mid-boot.) So I have gone back to Manjaro as my main system. Yes, Mint20 and OpenSuse each have more recent grubs, but I have changed the boot priority order in the UEFI bios so that the Manjaro UEFI is first, so I do boot with the Manjaro grub.

Hello again, Stephane (or others).
I suspect that the reason I can’t boot into a more recent version of the Linux Kernel (e.g.5.12 or 5.13) is related to my not being able to update the grub because “sudo update-grub” always returns this error message:
/usr/bin/grub-probe: error while loading shared libraries: libzfs.so.2: cannot open shared object file: No such file or directory
I used to be able to edit grub by using the Grub Customizer app, but now when I try to run that app, I get the identical error message:
/usr/bin/grub-probe: error while loading shared libraries: libzfs.so.2: cannot open shared object file: No such file or directory
Do you have any idea how I could go about fixing that error?

Uninstall old or not official grub packages and install the official one:

sudo pacman -R grub-customizer
sudo pacman -R grub-vanilla
sudo pacman -S grub
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=manjaro --recheck

I think that should be enough

1 Like

Hello Christian, and thank you for your suggestion. I ran each of the four commands above. Then I rebooted. The Manjaro grub menu had, indeed, changed, but the first menu item was still Manjaro KDE, which I selected. Previously, the boot into Manjaro would start by telling me that it was loading Kernel 5.9… This time it gave me an error message saying that I needed to load a kernel first, and then it froze. I tried to reboot again and the same things happened. So I booted into Manjaro from my live USB stick and ran Timeshift to undo the changes. Now Manjaro boots up again, but still with kernel 5.9, and with the same error message from Grub Customizer and from sudo update-grub. So I’m back at square one, I’m afraid.

I think I forgot to add, that you must also run

sudo update-grub

to update grub’s config accordingly to your actual kernels. Right now you have some version from grub-customizer. Don’t use grub-customizer with Manjaro. It will produce problems sooner or later.

Try again and tell how it went :slight_smile:

Edit: Let’s see how it goes, but maybe you have to purge some files from /etc/grub.d, because grub-customizer has added files there or has modified some existing files there.

2 Likes

Aha! Thank you Christian. That finally did it!. I now have a new grub with Manjaro running on kernel 5.13 (and 5.12, 5.11, 5.10 and 5.9 available as “advanced options”). I am very grateful for your assistance.

However … I still have a question. The new grub menu has the items that I would have expected and that work, but it also has many other items, including a number of duplicates and some items that lead to old back-ups that I had made on other drives and that don’t work properly. This is where, in the past, I would have used Grub Customizer to delete the unwanted items and alter the wording for some of the remaining items so that they are more descriptive. I can live with the grub menu the way it is, but if there is a way to edit it safely, I would be happy to do that.

Also, the issue of my running an EOL kernel and update-grub not running and therefore my not being able to update the kernel was something that stephane noticed in the process of trying to help with my original two problems. Those two original problems are still with me. (See the top of this thread.) The new kernel hasn’t fixed them, I’m afraid. If you have any suggestions about those particular problems, I would be very happy.

I would say that they can come from two sources:

  1. One possible source is some old setting from grub-customizer. update-grub uses the scripts in /etc/grub.d. Using Manjaro’s default settings nothing else should be added to grub config. But grub-customizer has probably added or modified some files in /etc/grub.d.
    I think that the best way to deal with this is delete/move the old script folder and recreate it reinstalling grub:
sudo mv /etc/grub.d{,.bak}
sudo pacman -S grub 
sudo update-grub
  1. The other possible source is that you have some old EFI entries in the EFI partitions. You should manually remove them to avoid detection. I mean, browse your EFI partitions and search for old folders that can be deleted. (AFAIK you have two EFI partitions /dev/sdb1 and /dev/sdb10/)

After checking this two things, you shouldn’t have anything else than your Manjaro’s kernels and other OSes detected.

BONUS: You can also delete old UEFI entries with

sudo efibootmgr -b XXX -B

being XXX the entry number you want to remove (sudo efibootmgr -v to show entry list)


I will try to look into your original problems

1 Like

I think you should provide your system logs to analyze possible problems. Next time you boot this way, execute this:

journalctl -b | curl -F 'sprunge=<-' http://sprunge.us

And post here the link.

This requires something similar. Next time you shutdown or reboot and it takes too much time, boot again and execute this:

journalctl -b -1 | curl -F 'sprunge=<-' http://sprunge.us

And post here the link.


In any case you can examine yourself the logs with journalctl -b (current boot) and look for errors or coredumps (usually in red). But it’s quite large and not so easy to understand.

1 Like

Here are the “transcripts” from the two commands you suggested, Christian. Below, I will describe what happened, from my point of view.

martin@Martin-Manjaro-Desktop ~]$ journalctl -b | curl -F 'sprunge=<
-' http://sprunge.us
http://sprunge.us/EkZvNJ
[martin@Martin-Manjaro-Desktop ~]$ journalctl -b -1 | curl -F 'sprung
e=<-' http://sprunge.us
http://sprunge.us/73h0Js
[martin@Martin-Manjaro-Desktop ~]$

This morning, the first boot into Manjaro was OK - i.e. Manjaro booted up fully.
I pressed “Restart” - shut down took about 90 seconds before re-starting the boot process.
2nd boot was also OK
Pressed “Restart” again. This time shut down took just over 90 seconds before boot process restarted.
3rd boot also OK.
Pressed “Restart” again. Took 105 sec before restarting the boot process.
4th boot: this time (finally!) it did NOT boot fully. The clock widget and desktop background image appeared but no task bar and pressing the windows key did nothing. However, as usual, cntr-alt-del did bring up the shut-down/restart/log-out screen. Pressed “Restart.” It took 25 seconds before the desktop closed and screen went black and a further 100 seconds before the reboot started.
5th boot went OK. So that’s when I entered the two commands shown.

(It is rare for me to get three complete boots in a row, as I did this morning. I think it is the law of annoying intermittent problems that when one is trying to demonstrate the problem to someone, the problem doesn’t occur. That always happens when I take my auto to the mechanic, also!)

I hope you are able to do something with these logs. Thanks for your help.

Aug 30 09:46:52 Martin-Manjaro-Desktop systemd[1]: udisks2.service: State 'final-sigterm' timed out. Killing.

This seems to be the culprit of your long shut down process (90 seconds to timeout). It’s a service that mounts different partitions for your user under /run/media/$USER. You are mounting some NTFS partitions and it seems that they can’t be cleanly unmounted for some reason.

Aug 30 09:46:52 Martin-Manjaro-Desktop systemd[1]: udisks2.service: Unit process 2196 (mount.ntfs) remains running after unit stopped.
Aug 30 09:46:52 Martin-Manjaro-Desktop systemd[1]: udisks2.service: Unit process 2215 (mount.ntfs) remains running after unit stopped.

Also /dev/sdc2 and /dev/sdf5 seem to have problems:

Aug 30 09:43:18 Martin-Manjaro-Desktop kernel: EXT4-fs (sdc2): warning: mounting fs with errors, running e2fsck is recommended
Aug 30 09:43:21 Martin-Manjaro-Desktop kernel: EXT4-fs (sdf5): warning: mounting fs with errors, running e2fsck is recommended
1 Like

Yes, I have 8 partitions altogether that are NTFS and that are usually auto-mounted at boot. 4 of those are on an external HDD and are backups that I really don’t need any more and should probably just delete, especially if they are causing problems. But the other four are all essential; one contains Windows, another Windows RE Tools (I don’t really know what that is) and the other two where I store all my Data or my Music files and are NTSF so that they can be accessed from either Windows or Linux.
Do you have any advice regarding what I can or should do?

/dev/sdc2 is an ext4 partition that contains all my Timeshift backups.
/dev/sdf5 I"m not sure about. Actually GParted doesn’t show any /dev/sdf drive, but there is a /dev/sde drive that has many partitions so I suspect that’s what it is. /dev/sde5 contains another back-up that it outdated and which I could delete without problem.

What is e2fsck and how does one run it?

Thanks.

Drive /dev/sdf appears in your fdisk -l output, as shown above.
/dev/sdf5 seems to be mounted on /run/media/martin/Mint-KDE-Root-BK

The NTFS partitions, that had problems in your log, were /dev/sdb4 (Windows RE tools) and /dev/sd10 (Windows-New-BAK). I would say that, at least, you don’t need to mount sdb4

Aug 30 09:43:21 Martin-Manjaro-Desktop ntfs-3g[2196]: Mounted /dev/sdb4 (Read-Write, label "Windows RE tools", NTFS 3.1)
Aug 30 09:43:21 Martin-Manjaro-Desktop ntfs-3g[2215]: Mounted /dev/sdf10 (Read-Write, label "Windows-New-BAK", NTFS 3.1)

My advice is that you only automount what you need, don’t automount everything.


e2fsck is a filesystem check utility for ext4. Follow the link to learn how to use or google or duckduckgo it, there should be plenty of information on the matter.


Your baloo daemon is core dumping. If you don’t use it (it’s the file indexer), disable it with:

balooctl disable

If you want to continue using it, the core dump maybe can be solved with:

balooctl disable
balooctl purge
balooctl enable

Also, if you don’t use Snap or AppImage, I recommend to uninstall them:

sudo pacman -Rscn snapd
sudo pacman -Rscn appimagelauncher
1 Like

Thank you very much, Christian.

First the great news: I changed the automount settings so that only those partitions that I really need are automounted, and that seems to have taken care of the slow shut-down problem and possibly also the problem of incomplete boots. (Since the incomplete boot problem was intermittent, I can’t be sure yet that it won’t show up, but I went through the restart cycle 4 times and it booted fully each time.) So, since this seems to have solved both of the problems that I had originally posted and that started this very long thread, I’m going to mark your last post as “Solution”. Thank you so very much for your help and your extreme patience.

With respect to whether or not I have a disk /dev/sdf, I don’t really understand how the assignment of letters (sda, sdb, sdc, etc.) to physical disks works. I have five disks running on my computer, two of them internal and 3 external HDDs. They are always labeled in the same order, but sometimes the 4th one is labeled sdd and other times sdd is skipped and they are labeled sda, sdb, sdc, sde and sdf. The disk in question is the 5th one so sometimes it is /dev/sdf and sometimes it is called /dev/sde. I don’t understand that, but I don’t think it’s a problem so I won’t worry about it.

I did run e2fsck on /dev/sde5 last night (which is now appearing as /dev/sdf5 again today!) and it fixed a few items and ran OK. Then I ran e2fsck on /dev/sdc2 and after fixing a couple of items it got hung up on something and I had to crash it. I will try running it again, but that partition (my partition for Timeshift backups - very important!) seems to be performing properly, as far as I can tell.

I don’t use baloo directly, but I understand that Dolphin uses it for file searches. Dolphin is my main file browser and I often do file searches with it, so I am reluctant to leave baloo disabled. Therefore I tried the set of instructions to disable, purge and enable. I don’t know what it is doing; it has been running for hours and coming up with hundreds of error messages. I think it is still writing a new message every 10 minutes or so, so it doesn’t seem to be hung up. I’ll just let it run, I guess.

I do use Snap occasionally but I don’t think I use Appimage, so I will uninstall Appimage (when the balooctl commands stop running.)

Thank you very much for all your help.

Cheers.

P.S. balooctl enable finally just finished running. I don’t know what to do about the hundred’s of error messages. Frankly, unless I notice a problem that I think might be connected, I’m inclined to ignore them and just move on.
I have run the command you suggested to uninstall Appimage.
And I have run e2fsck again on /dev/sdc2 and this time it ran smoothly.

Hi, happy to see that you solved your Manjaro problems! :blush:

Cheers!

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.