Mageia forum

I have worked out that if I take some of the lines out of the boot sequence such as:

insmod gzio
insmod part_gpt
insmod ext2

...my machine boots more reliably.

By pressing e at boot and editing them out. So, I'd like to make those changes permanent. I looked at this page:

which seemed to suggest you can edit /etc/default/grub, but that doesn't contain any of those types of lines.

/boot/grub2/grub.cfg has such lines, but it says you can't edit them.

It does say:

It is automatically generated by grub2-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub

However, I can't work out what to do with these scripts.

It all seems ridiculously complicated for just wanting to edit out a few lines. Is there an easy way to accomplish this please?

Thanks!

By the time you are doing insmod, you are past grub and the kernel is loaded, and probably you are running out of the initrd. To remove those modules, you have to build a new initrd, or else edit your existing initrd.

I suggest you study the working of the command dracut. I have not tried to prevent loading specific kernel modules at boot time, so I can't tell you in detail how to do it (other than blacklist them) but the information you need should be found in the dracut command.

Well by golly, I just looked in a grub2 file, and grub.cfg does do all that stuff.

I boot using grub legacy, so I was not aware of that.

So as for what I wrote in my previous post...never mind...

Would you mind adding the actual reason on WHY you want to remove those modules from the boot sequence?

doktor5000 wrote:Would you mind adding the actual reason on WHY you want to remove those modules from the boot sequence?

Yep, it boots with these lines taken out.

With them in I get all sorts of problems such as kernel panics.

With them in I get all sorts of problems such as kernel panics.

These modules are in fact to help you boot without errors.
If these are removed and you do not get errors, then for example, it should be "insmod part_msdos" instead of "insmod part_gpt"
or "insmod xfs" instead of "insmod ext2" if you are indeed using msdos partitioning and xfs file suystem.
You should file a bug report that grub.cfg is not generated correctly.

If in the more likely case that the modules are correct, then the kernel panics are not cause by these modules, but by other things.
like, for example, 'nokmsboot' should be there when it shouldn't?
or 'nokmsboot ' shouldn't be there when it should?
Or 'noiswmd' is unnecessary for non-raid systems
Or.....

Only you can tell us what other causes there might be.

Is there an easy way to accomplish this please?

/etc/grub.d/00_header and /etc/grub.d/10_linux

But not recommended and discouraged particularly by people not familiar. It may really mess up the system.

Or more simply, just manually edit grub.cfg despite the warnings.
It's just like grub-legacy where we merrily edit its menu.lst
And just like grub-legacy, remember it will revert back and needs re-editing again whenever there's an update-grub.

Finally, instead of removing, for example insmod part_gpt, we can insert insmod part_msdos without removing any
Grub can load up modules even if it isn't needed (and actually load modules when needed even if not specified)
Try it out. Load unnecessary modules and remove needed modules. That will work.
So no offense, I really doubt that is the cause of kernel panics though I do not doubt your sincerity.

Cheers.

gohlip wrote:These modules are in fact to help you boot without errors.
If these are removed and you do not get errors, then for example, it should be "insmod part_msdos" instead of "insmod part_gpt"
or "insmod xfs" instead of "insmod ext2" if you are indeed using msdos partitioning and xfs file suystem.[
You should file a bug report that grub.cfg is not generated correctly.

It's a tricky one this, because when you're trying to track down a really obscure issue like this, you get so many conflicting opinions on what it could be. Before I managed to get M6 latest pre-release installed and sometimes booting, I had all sorts of advice on Linux Questions about what to try, one of which was removing modules to see what might have it boot. So, I did that and found removing these made it much more reliable.

I am using neither ext2, FAT, or indeed anything other than ext4. I am using Legacy boot, so don't have a FAT partition. So quite why I would need ext2 I don't know. I don't even know what gzio or part_gpt are and can find no page anywhere that lists all these different options and what they mean.

gohlip wrote:If in the more likely case that the modules are correct, then the kernel panics are not cause by these modules, but by other things.
like, for example, 'nokmsboot' should be there when it shouldn't?
or 'nokmsboot ' shouldn't be there when it should?
Or 'noiswmd' is unnecessary for non-raid systems
Or.....

Only you can tell us what other causes there might be.

Well, I decidedly can't tell you what the cause is. I've never had a machine that didn't just boot before and have never had the cause to even look at any of these boot options. Whether there should be a nokmsboot or where it should be I have not the foggiest. Nor would I know where to put something like nokmsboot or why I might need it.

gohlip wrote:

DiBosco wrote:Is there an easy way to accomplish this please?

/etc/grub.d/00_header and /etc/grub.d/10_linux

But not recommended and discouraged particularly by people not familiar. It may really mess up the system.

Or more simply, just manually edit grub.cfg despite the warnings.
It's just like grub-legacy where we merrily edit its menu.lst
And just like grub-legacy, remember it will revert back and needs re-editing again whenever there's an update-grub.

Finally, instead of removing, for example insmod part_gpt, we can insert insmod part_msdos without removing any
Grub can load up modules even if it isn't needed (and actually load modules when needed even if not specified)
Try it out. Load unnecessary modules and remove needed modules. That will work.
So no offense, I really doubt that is the cause of kernel panics though I do not doubt your sincerity.

Cheers.

I thought that is exactly what I was doing by removing these. ie Removing unnecessary modules?

What is hugely frustrating is that even removing these, even though it boots far more often without them, it still doesn't always boot without a panic or it fixing a recursive fault and no-one here or on Linux questions or hours and hours of Googling can give me any clue as to what it might be. At least removing these lines makes it boot more often than not.

Thanks

I Googled nokmsboot and came across something that mentioned /etc/default/grub and noticed mine had this line it:

GRUB_ENABLE_CRYPTODISK=y

Presumably this is something to do with having encrypted disks? I certainly don't have one Could that possibly be an issue?!

Full file in case it helps is:

Code: Select all

GRUB_CMDLINE_LINUX_DEFAULT=" splash quiet noiswmd resume=UUID=3762059c-a20d-4fbd-a8a5-bb7b993047a6"
GRUB_DEFAULT=saved
GRUB_DISABLE_OS_PROBER=false
GRUB_DISABLE_RECOVERY=false
GRUB_DISABLE_SUBMENU=n
GRUB_DISTRIBUTOR=Mageia
GRUB_ENABLE_CRYPTODISK=y
GRUB_GFXMODE=1024x768x32
GRUB_GFXPAYLOAD_LINUX=auto
GRUB_SAVEDEFAULT=true
GRUB_TERMINAL_OUTPUT=gfxterm
GRUB_THEME=/boot/grub2/themes/maggy/theme.txt
GRUB_TIMEOUT=10

I Googled nokmsboot and came across something that mentioned /etc/default/grub and noticed mine had this line it:

GRUB_ENABLE_CRYPTODISK=y

If you do not have encrypted disks, then comment this out.
So go to /etc/default/grub, comment this out and at terminal

Code: Select all

# grub2-mkconfig -o /boot/grub2/grub.cfg

This (encryption) is most likely the cause of your slow boot.


Other things ---
o re : noiswmd - Also if you not use raid, remove 'noiswmd', but generally it is safe to leave it there even if you not use raid. It is ignored, if not applicable.

o As for 'nokmsboot', Mageia has a unusual way of implementing this. In Mageia 5, it needs it, in Mageia 6, it has to be taken off.
In Mageia 4... In mageia 3.., are all different. So whatever your version of Mageia, try it with and without. But since it booted, let it remain unchanged first.
Good implementation of dkms modules should not require 'nokmsboot' anywhere.

o insmod ext2 - that is the module for ext formats including ext4. so this module applies. That's because /boot , if on separate partition is better on ext2 than in ext4, so leave it alone, it's correct.

o so generally, "insmod <module>" is not the cause of problems. And generally speaking, wrong kernel parameters are usually ignored too - except the case of 'nokmsboot'. We need to get this right (in Mageia).

o swap -resume line - the usual problem for slow boot is the uuid for swap which does not correspond to the actual uuid.
Check with blkid and the "resume=UUID=3762059c-a20d-4fbd-a8a5-bb7b993047a6" in /etc/defaut/grub as well as the uuid in /etc/fstab.
Make sure all are the same as in 'blkid'
Also in /etc/fstab, check other entries, especially ntfs partition entries. comment them out to check if boot improves.
Usually windows has hiberfile enabled and needs to be disabled.


Good luck.

gohlip wrote:o As for 'nokmsboot', Mageia has a unusual way of implementing this. In Mageia 5, it needs it, in Mageia 6, it has to be taken off.
In Mageia 4... In mageia 3.., are all different. So whatever your version of Mageia, try it with and without. But since it booted, let it remain unchanged first.
Good implementation of dkms modules should not require 'nokmsboot' anywhere.

nokmsboot only relates to the video driver selection for the X server later, I've never heard about it preventing booting initrd/kernel at all.

doktor5000 wrote: I've never heard about it preventing booting initrd/kernel at all.

Have you tried to remove 'nokmsboot' in Mageia5? Does that boot?
Did you put 'nokmsboot' in Mageia 6? Does that take a loooooong time to boot? After 'detecting new hardware'?

Please try out first, alright?
Try not to speak out until you've tried or tested.
It's not the first time, doktor5000,
I don't mind being corrected, if I am wrong. In fact,I welcome and thank those who do so.
But please do not shoot and ask questions later. (like Bush
Cheers.

[edit] - some google searches on nokmsboot
https://bugs.mageia.org/show_bug.cgi?id=8540
http://alt.os.linux.mageia.narkive.com/ ... boot-again

If I remember correctly on Mageia 2,3,4
All of M2,3,4 require 'nokmsboot' except one of them, and I forgot which one. M4 most likely, but I am not sure.
But it's good to see M6 don't require it now. Good.

gohlip wrote:Have you tried to remove 'nokmsboot' in Mageia5? Does that boot?

Yep. As I'm using grub2, I know this boots, as I needed to add it later on manually.
And as you can see from the bug report, this is about X starting or not, not about booting at all. Which was my point.

gohlip wrote:Did you put 'nokmsboot' in Mageia 6? Does that take a loooooong time to boot? After 'detecting new hardware'?

Nope, not tested under mga6, but my point was that you mentioned that mga5 needs this or it will not boot.
And why would you add it manually in mga6 when it's not needed nor present by default?

Unfortunately, the latest set of 800 or so updates have stopped it booting at all now (before I got the chance to try any of those things). Neither of the two possible kernels to boot into helps. No amount of editing the boot option helps. (Well, none that I could find.)

I would say, that slow boot was never the problem. It either booted nicely or didn't boot at all. With the network install of M6 I finally got it booting more often than not, but yesterday there was a batch of about 800 updates and that's just totally borked it. It gets as far as the screen below. I realise though, that this is now getting off topic from the original boot question.

Google searches show people with Ubuntu have exactly the same issue.

Debian Jessie 8.5 boots OK regularly, but the kernel is too old to support the wi-fi card.

Okay. This may not be a case of bad grub parameters and could just be booting up the wrong kernels.
Provide the contents of /boot and the main entry of Mageia in grub.cfg
I am assuming now that you're using Mageia grub to boot and not using Jessie boot, otherwise provide Jessie grub entry for Mageia.[1]
One entry is fine (not the whole grub.cfg).
Also check if uuid is correct in /etc/fstab and in grub.cfg (if unsure provide "# blkid)

So
o Mageia grub entry
o ls /boot/ (of Mageia partition of course)
o cat /etc/fstab (of Mageia partition of course)
o # blkid


ps: I have no problem with huge updates.
ps: from your input, looks like you're using Mageia 6. If wrong, please correct.
[1] - if using Jessie grub to boot, perhaps it's just a matter of "# update-grub" in Jessie to get the new Mageia kernels in it,
May be that simple.

doktor5000 wrote:

gohlip wrote:Have you tried to remove 'nokmsboot' in Mageia5? Does that boot?

Yep. As I'm using grub2, I know this boots, as I needed to add it later on manually.
And as you can see from the bug report, this is about X starting or not, not about booting at all. Which was my point.

Okay. It boots for you, not for me. Perhaps I am using proprietary drivers and you, intel

doktor5000 wrote:

gohlip wrote:Did you put 'nokmsboot' in Mageia 6? Does that take a loooooong time to boot? After 'detecting new hardware'?

Nope, not tested under mga6, but my point was that you mentioned that mga5 needs this or it will not boot.
And why would you add it manually in mga6 when it's not needed nor present by default?

To test, of course. I wanted to see why it works now without 'nokmsboot' and what if I deliberately put it in.
I'm still on proprietary drivers.

Cheers, doktor5000, good to have you in this forum.
Not sure what would happen to this forum if you are not here. Shudder the thought.
Thanks for contributing so much.

Debian Jessie has been totally and utterly wiped from the HDD. This is purely Mageia 6. Mageia 5 won't even install, let alone boot.

I'll boot to that laptop with the live stick and give you details of the /boot partition etc in a bit.

gohlip wrote:

doktor5000 wrote:

gohlip wrote:Have you tried to remove 'nokmsboot' in Mageia5? Does that boot?

Yep. As I'm using grub2, I know this boots, as I needed to add it later on manually.
And as you can see from the bug report, this is about X starting or not, not about booting at all. Which was my point.

Okay. It boots for you, not for me. Perhaps I am using proprietary drivers and you, intel

Nope, using nvidia proprietary drivers from the repos with a GTX970, no issue booting without nokmsboot on mga5 (or before)

Not sure whether I installed the proprietary drivers on my cauldron install though, and didn't fiddle with nokmsboot there yet.

Nope, using nvidia proprietary drivers from the repos with a GTX970, no issue booting without nokmsboot on mga5 (or before)

In my case where 'nokmsboot' is required (in all Mageia versions), it won't boot at all if I removed it.
There will be a message (in a text box) something like "dkms modules required" and boot stops there.
Trying to booting to prompt (no graphics - so I can startx) won't succeed either.
Where it is not required (like in M6), if I put it there, boot will continue after a long pause - I check it is detecting new hardware - and boots up.

Not sure why it behaves differently from yours (or yours from mine).
Perhaps the links in my earlier post can help? (the bug report)
Cheers.

OK, so it turns out it's actually a piece of cake to add what I eventually needed:

Just edit /etc/default/grub

And add/edit (as applicable) the line:

GRUB_CMDLINE_LINUX_DEFAULT="blah blah"

Then run

update-grub2

All as root, obv.

FWIW, this is also mentioned in https://wiki.mageia.org/en/Grub2-efi_an ... tion_files