Solved Stuck in "Loading kernel modules" after build custom kernel

zamon

zamon

Hello all, it's 4 days since I trying to make custom kernel and fail with stuck in 'loading kernel modules' (no message just stuck in there). Because I'm curios why this happen, so I try to build another custom kernel without any modification at all, just copy paste the GENERIC as new file called ASUSX45U and the result is same, the kernel wont boot just stuck like previous. This is my hardware and software specification

1. Asus X45U, 2gb ram, 500gb hdd
2. FreeBSD 13.1-RELEASE GENERIC amd64

I have no issues when installing FreeBSD with KDE, and I already have backup the working kernel so I can go back to run buildkernel again like the handbook said.

Is there any people in here that have the same issues like me and solved it?
 
Is this a booting error ?
What is your /boot/loader.conf ?
Which modules do you load in /etc/rc.conf ?

Note : when building a kernel do an "su - root". So no environment settings are taken from the normal user.
 
This is my /boot/loader.conf
kern.geom.label.disk_ident.enable="0"
kern.geom.label.gptid.enable="0"
kern.vt.fb.modes.LVDS-1="1024x768"
cryptodev_load="YES"
zfs_load="YES"
autoboot_delay=5
fusefs_load="YES"
beastie_disable="YES"
boot_mute="YES"
verbose_loading="NO"
splash_bmp_load="YES"
bitmap_load="YES"
bitmap_name="/boot/mario.bmp"
Click to expand...

and this is my /etc/rc.conf

sendmail_enable="NONE"
hostname="mokondo"
wlans_ral0="wlan0"
ifconfig_wlan0="WPA DHCP"
create_args_wlan0="country US regdomain FCC"
sshd_enable="YES"
# Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable
dumpdev="AUTO"
dumpon_flags="-Z"
zfs_enable="YES"
kld_list="/boot/modules/radeonkms.ko"
sddm_enable="YES"
sddm_lang="en_US"
splash_changer_enable="NO"
Click to expand...

I'm using root when building the kernel, I know something wrong if boot failed maybe because I put wrong config when modify the text file, but this also happen when I just copy paste the GENERIC to another file without modifying the content. Right now I'm still tracking my false by looking the log file, but still I dont get it why this happen.
 
Try remove cryptodev & fusefs from loader.conf.
And add them to rc.conf.
In loader.conf only stuff needed to load the kernel (eg zfs/openzfs/opensolaris).

In rc.conf i have simply:
kld_list="radeonkms"
 
I try your suggestion and still no luck... Can you tell me if I want to read something like error log message from previous kernel load where I can find it in FreeBSD?
 
If you have no problem to boot from standard installation,
but when building a GENERIC kernel without any modification,
then the kernel's source files differ from your installed version (unclean update?),
or you may compiled from the wrong sources (e.g. arm64 instead of amd64)
because what you should get if you build an unmodified GENERIC kernel would be identical with the pre-compiled one from installation.

That's also the reason it makes no much sense to compile an unmodifed kernel by yourself,
since compilation is done by default by clang on LLVM which will produce the same machinecode anyway.

Or - as Alain pointed out - you may not have a kernel prob as such,
but have a classical mismatch in /etc/rc.conf or /boot/loader.conf
 
Profighost said:
If you have no problem to boot from standard installation,
but when building a GENERIC kernel without any modification,
then the kernel's source files differ from your installed version (unclean update?),
or you may compiled from the wrong sources (e.g. arm64 instead of amd64)
because what you should get if you build an unmodified GENERIC kernel would be identical with the pre-compiled one from installation.

That's also the reason it makes no much sense to compile an unmodifed kernel by yourself,
since compilation is done by default by clang on LLVM which will produce the same machinecode anyway.

Or - as Alain pointed out - you may not have a kernel prob as such,
but have a classical mismatch in /etc/rc.conf or /boot/loader.conf
Click to expand...
maybe I was wrong when doing check out from repository, but for the directory I'm sure I working in amd64. Based on your experience If something like this happens, then where and how you trace it? Maybe I can read some files like error message or something like that.

update: Double check the git branch, I checkout in branch 13/Stable
 
zamon said:
check out from repository
Click to expand...
Here may be your problem of getting the "wrong" - different - source-file-version.
The installer offers you the choice to install system's source files, which should match your installed system.

It should be possible to install those source afterwards:
as root:
# bsdconfig

As far as I view the forum most problems are from having mismatching versions:
packages updated, but not freebsd, or vice versa, only partially updates made or interrupted,
or manually installed (compiled) packages having conflicts with mismatching other packages/libraries...

In my experience as long as you have an installation made with the default installer, using pkg only, not mixing it up with ports (except you know exactly what you do, and why and how [ports also needed to be kept conform)),
and having it all smooth conform within a supported RELEASE (13.1-p7, not 14 at the moment) to the same update level,
there should be at least no problems with FreeBSD.

But if you want to understand by logfiles, there are several points where to look:
root # dmesg may give you a hint what last was loaded, when the system started, where it hung up.
Depending on what causes the prob you also may press ctrl-C while booting to break the loading of that module,
your computer may come up at least to get a shell or give you further messages where it stuck.
But as far as I may judge from your descriptions, there happend not a light mistake.
To me it smells you simply have tried to compile and run a kernel which does not match the rest of your system.
In my eyes it would be way easier to check and compare used versions than digging log files.

Let me put it in other words:

As long as you use a FreeBSD Release as described in the handbook:
default installation by default installer,
installing packages with pkg only,
and doing freebsd-update and pkg update,
keeping the system up-to-date and conform
it's very unlikely to have a real problem - with some third party software maybe (e.g. libreoffice, gimp, and such [Linux world 😁] produces often pain (libreoffice is a pain in the arse anyway, cause it copies MS Office which is even more pain - but this is a complete different offtopic story),
but not with FreeBSD itself.

app. 99% of all problems I had myself, and saw in the forums,
are caused by not doing it the official documented way,
by not having a conform system.
mostly caused by not reading the handbook or manpages properly (I include myself :cool:)

If you're experimenting - which of course you're not only free to do, but feel to be encouraged to do -
e.g. by manually downloading and compiling sources other as the recommend way by official documentation,
or compiling a kernel, what today is no need to do anymore, except you're experimenting, and in either way
know what you're doing, cause then you're formost on your own.
 
Yes indeed I only try with these custom kernel compilation following instruction from handbook, just curious how fast the boot if I custom the kernel for my hardware only, luckily I still have the working version. Maybe I need to stop now and continue exploring another interesting things like jail😅

Anyway thank you very much to all of you for the help and tips.
 
All FreeBSD guys I experinced in this forum are very helpful.
And most know way more than me (especially the guys you read seldom from - those have very special interests.)

Point is as in any forum nobody wants to do other's homework,
especially not if "doing the homework" is the whole point of the game.

As I said, anybody here is willing to help, but it's not always easy to distinguish,
where someone is too lazy to do it's homework, or having a "real problem",
and pointing/figuring this out without p#ssing someone of, which very most people here also not want, is highly sensitive.

Anyway it's always good if you solved your problem,
to post, what the cause was and how you got it solved.
By my own experience I know this sometimes can be embarrassing, if the cause was stupid and silly 😁.
But I guess we all started somewhere, or do silly mistakes sometimes.
Unix means keep on learning.
One cannot learn when not doing mistakes.

In your case you would not really see no significant difference in boottime by building a customized kernel.
First only the needed modules are loaded anyway,
and second most time for booting process is spent not to load the modules but to check which hardware exists.
Here you may increase booting speed significantly, by telling not to check, or reduce check times, and only to load specified modules.
BUT - WARNING! - herein is the next trap.
If one day some , even small change happens to your system, and you don't think of your customized kernel anymore, your system will not come up again.
So very "know what your doing and not relying on automatic"

After all, if you think it through, such things are only a real concern within embedded systems, where you know, there will be no hardware-changes or even updates.
On the normal desktop-computer it really don't matters, if the computer needs 1minute30 or 1minute15 to get up.
While that I'm in the kitchen and get me cup of tea anyway :cool:

There also may another explanation for your prob:
You may have tried to strip down your kernel tto much and simply may have excluded a crucial module from your custom config.
 
I would suspect the drm module, i would take it out of rc.conf or comment it and retry.

If it was the drm module then you probably missing the gpu-firmware or you need to rebuild the drm module against your custom kernel.
 
Profighost said:
All FreeBSD guys I experinced in this forum are very helpful.
And most know way more than me (especially the guys you read seldom from - those have very special interests.)

Point is as in any forum nobody wants to do other's homework,
especially not if "doing the homework" is the whole point of the game.

As I said, anybody here is willing to help, but it's not always easy to distinguish,
where someone is too lazy to do it's homework, or having a "real problem",
and pointing/figuring this out without p#ssing someone of, which very most people here also not want, is highly sensitive.

Anyway it's always good if you solved your problem,
to post, what the cause was and how you got it solved.
By my own experience I know this sometimes can be embarrassing, if the cause was stupid and silly 😁.
But I guess we all started somewhere, or do silly mistakes sometimes.
Unix means keep on learning.
One cannot learn when not doing mistakes.
Click to expand...

Yes, this is my first post in forum and I'm happy with the response... I know I still need to learn much more and I don't care if it fails many many times because of my curiosity (or my silly don't care bout it😅), right now I need to rest and working 😅 because 4 days trying to compile and boot without any luck (3 hours waiting when compiling). I will update this thread if I success doing this so people can learn from my silly mistake.

Alexander88207 said:
I would suspect the drm module, i would take it out of rc.conf or comment it and retry.

If it was the drm module then you probably missing the gpu-firmware or you need to rebuild the drm module against your custom kernel.
Click to expand...
Interesting, I will try... Thank you🙏
 
zamon said:
I try your suggestion and still no luck... Can you tell me if I want to read something like error log message from previous kernel load where I can find it in FreeBSD?
Click to expand...

/var/log/messages

I suggest adding these to /boot/loader.conf:

verbose_loading="YES"
boot_verbose="YES"

at least while finding any problems. You might also modify /etc/newsyslog.conf to have /var/log/messages be perhaps 1000 MB, and maybe 14 files rather than 7.

Changes will be picked up at the next hourly log rotation.

Yes, verbose booting - which can also be chosen from the boot menu - writes much bigger logs, during and after boot, but includes details otherwise not displayed.

Edit: and obviously with problems loading modules, 'verbose_loading' may help topic subject, hopefully.
 
zamon said:
update: Double check the git branch, I checkout in branch 13/Stable
Click to expand...
This is where the problem comes from: stable/13 isn't the same version as 13.1-RELEASE. It's the continuously updated stable branch, currently labelled 13.2-STABLE, which is already further away in development than the not yet released 13.2-RELEASE.

If you want to build a 13.1-RELEASE kernel you need releng/13.1 sources.
 
Hello all my problem is solve now... exactly like bsdduck said my problem comes from wrong branch. So last night I realised something that I miss, so once again I boot my system with working kernel and then "uname -a" and found "releng/13.1", I use that to check the branch on github and found that branch. Next I download to my machine, start building installing kernel and reboot. And it works (off course my mistake pick the wrong branch😅)

Anyway I'm happy now, thank you all for the tips

now how I mark this post as solved?
 
You must log in or register to reply here.
Back
Top