The kernel problem with recent updates has been solved. Find the solution here

Important information
-- Required MX 15/16 Repository Changes
-- Information on torrent hosting changes
-- Information on MX15/16 GPG Keys
-- Spectre and Meltdown vulnerabilities

-- Introducing our new Website
-- MX Linux on social media: here

Current releases
-- MX-18.3 Point Release release info here
-- Migration Information to MX-18 here
-- antiX-17.4.1 release info here

New users
-- Please read this first, and don't forget to add system and hardware information to posts!
-- Here are the Forum Rules

SOLVED - Grub Customizer - Assignments not working in order

User avatar
Forum Novice
Forum  Novice
Posts: 81
Joined: Wed Jun 27, 2018 11:17 am

SOLVED - Re: Grub Customizer - Assignments not working in order


Post by HessenZone » Wed Jul 04, 2018 3:23 am

dolphin_oracle wrote:
Tue Jul 03, 2018 12:44 pm
ps -aux |grep systemd would be what I would check. things like udev-systemd and logind will be running under both sysvinit and systemd, but there should be a systemd process with a PID of 1 if systemd is running.
It's getting stranger yet. I would suggest that everyone who uses a double or a triple boot setup might want to check their currently loaded setup via terminal. I went ahead and used grub-customizer to revert to the original settings without making any other changes. Just a simple reversal by clicking the button for that. Before saving the file, I could clearly see how MX Linux was now the top choice again, with MX Linux (systemd) being the second choice. Then I rebooted the machine.

At the grub screen, the order was now correct. MX Linux without systemd was the default and I went ahead and let it boot into MX Linux without pausing the process. 5 seconds is more than enough time to see which session was the highlighted session that the system was going to boot into. After logging back in, I went ahead and tried to use the app which won't work correctly without systemd, and yet again everything was fine with the app. Too good to be true? Of course! So I checked the system once again with ...

Code: Select all

ps -aux |grep systemd
And got this returned to me ...
(that's directly after rebooting, within 60 seconds of having logged in)
Grub Menu with Grub Customizer and Grub Menu during reboot, both had MX Linux *WITHOUT* systemd as the default. Yet here we are again with systemd. What's going on? Do I really need to re-install MX in order to get MX without systemd back, or is this something that we can correct manually within the terminal?
You do not have the required permissions to view the files attached to this post.
Last edited by HessenZone on Wed Jul 04, 2018 5:00 am, edited 1 time in total.

MX Linux Rocks, in America, in Europa, in Australien, einfach ÜBERALL. :linuxlove:

User avatar
Posts: 5165
Joined: Sun May 27, 2007 5:37 am

Re: Grub Customizer - Assignments not working in order


Post by asqwerth » Wed Jul 04, 2018 4:35 am

HessenZone wrote:
Wed Jul 04, 2018 2:17 am
I was thinking that I could edit the grub file manually in order to achieve the correct order? Why is it only possibly to set the grub file from the "primary" of the three linux installations? That doesn't make sense to me since grub is supposed to be installed in the root of the drive, as that's always the default. That would indicate to me that there's only one grub file. Manjaro was the second OS which was installed of the three, yet when I boot the computer, a Manjaro logo still appears anyway and the manjaro/grub settings were more jumbled than the others. This would appear to indicate that Manjaro left some kind of trace which impacts the graphical/visible gui grub settings.
If there's only one grub file as I suspect there should only be one, then I should be able to edit that via terminal.
Off to search I go, will return shorly ...
Errr... if you installed a grub bootloader in root partition instead of MBR, then it's not controlling grub of your PC.

Non-tech explanation follows.

I'm assuming you use legacy-boot:

1. For each distro that comes with grub (the program) already on the iso, that distro will have its OWN grub.cfg file in its OWN root partition under /boot [except for Solus, which is weird]

2. during installation of a particular distro X, if you chose to install that distro's grub as bootloader In the Master Boot Record (MBR) instead of in root partition, that distro's grub will be written onto the MBR of your main hard drive and take charge of booting the whole computer. Its grub.cfg FILE still remains in /boot of the root partition but the necessary stuff is also written on the MBR to make it the controlling grub.

3. so if distro Y was installed earlier and USED TO control grub because its grub was written on MBR, that is now no longer the case. The most recent distro installed on your PC will control grub if you always choose to install grub on MBR.

4. grub-customiser (I think) sets up its own folders with some sort of copy of the grub.cfg file, and then all changes and edits are made to this folder rather than the actual grub.cfg file. But it's only affecting the grub settings/configs of the particular distro on which you installed grub customiser. Thus, let's say you have grub customiser installed on MX. But the very last distro you installed was Mint and you chose to install its grub bootloader on MBR. Thus Mint's grub has seized control of the MBR bootloading duties from MX. In such a case, booting into MX and changing MX's grub settings using MX's grub customiser is not going to affect the controlling grub.

5. you will need to make MX's grub seize back control of bootloading duties. How? From within MX, enter

Code: Select all

sudo grub-install /dev/sda 
(I'm making the assumption that your MBR is on the device called /dev/sda).

This will write MX's grub.cfg file back onto the MBR.

6. Alternatively, you install grub-customiser onto the distro that is currently controlling grub and edit your grub settings from within that distro.

7. Manjaro is a special case because its grub menu entry needs to have an additional command (on the "initrd" line) to load intel ucode in addition to loading the .img file from the kernel. Of course its own grub when updated knows how to add this command in its grub.cfg file, but if you have another distro's grub as controlling grub, it won't know how to generate a correct grub menu entry for Manjaro.

If you boot with UEFI:

1. all distros' grub bootloaders are "dumped" into the ESP partition if you choose to install that distro's grub onto ESP instead of root partition. The actual grub.cfg file is still stored in /boot/ folder

2. but it doesn't mean that when you reboot your machine, your machine will choose to boot from the newly-installed distro's bootloader.

3. Your machine's BIOS will still choose to boot from whichever bootloader in ESP was set as number 1 in boot priority.

3. there are a few ways to change the boot order/priority of the various bootloaders in ESP - through the BIOS settings or using a command in terminal from within a distro.

Based on all the above, it could be that you keep changing MX's grub settings using grub-customiser but MX's grub is no longer the controlling grub on your PC. So every time you boot up, you are seeing the other distro's grub menu, which hasn't been changed yet.

Or you installed MX's bootloader in root partition, so the controlling grub in MBR is still Manjaro's.
Desktop: Intel i5-4460, 16GB RAM, Intel integrated graphics
Clevo N130WU-based Ultrabook: Intel i7-8550U (Kaby Lake R), 16GB RAM, Intel integrated graphics (UEFI)
ASUS X42D laptop: AMD Phenom II, 6GB RAM, Mobility Radeon HD 5400

User avatar
Forum Novice
Forum  Novice
Posts: 81
Joined: Wed Jun 27, 2018 11:17 am

SOLVED - Re: Grub Customizer - Assignments not working in order


Post by HessenZone » Wed Jul 04, 2018 4:59 am

Thank you so much for that very informative & educational response. Definitely one to hold onto for the future. The command ...

Code: Select all

sudo grub-install /dev/sda 
... did the trick. First I double-checked, just to be safe, and then I went ahead and had MX take over the grub. After rebooting, the troublesome app which would not work in default MX Linux is once again not working. :bawling: It's no problem though, because now I can get back in touch with their support staff, to see if they can help me to figure things out. If the app works with systemd, I would imagine that it can't be too big of a deal to get it working with default MX. It's not some monster software application like libreoffice or gimp, but rather something small & basic that all of us in our household make use of.

MX Linux Rocks, in America, in Europa, in Australien, einfach ÜBERALL. :linuxlove:

Post Reply

Return to “Desktop Environment”