Jump to content

Kernel education needed


j___r
Go to solution Solved by TRS-80,

Recommended Posts

Would someone mind educating me about kernels please?

I have a problem with my vpn Tailscale and it seems to be related to the kernel version.

Nov 12 12:07:30 odroidhc1 tailscaled[8259]: Starting userspace wireguard engine with tun device "tailscale0"
Nov 12 12:07:30 odroidhc1 tailscaled[8259]: Linux kernel version: 4.14.187-odroidxu4
Nov 12 12:07:30 odroidhc1 tailscaled[8259]: is CONFIG_TUN enabled in your kernel? `modprobe tun` failed with: modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/4.14.187-odroidxu4/modules.dep.bin'
Nov 12 12:07:30 odroidhc1 tailscaled[8259]: modprobe: FATAL: Module tun not found in directory /lib/modules/4.14.187-odroidxu4
Nov 12 12:07:30 odroidhc1 tailscaled[8259]: kernel/drivers/net/tun.ko found on disk, but not for current kernel; are you in middle of a system update and haven't rebooted? found: linux-image-legacy-odroidxu4: /lib/modules/4.14.202-odroidxu4/kernel/drivers
Nov 12 12:07:30 odroidhc1 tailscaled[8259]: CreateTUN: CreateTUN("tailscale0") failed; /dev/net/tun does not exist
Nov 12 12:07:30 odroidhc1 tailscaled[8259]: wgengine.New: CreateTUN("tailscale0") failed; /dev/net/tun does not exist

 

In armbian-config there are a large  number of kernels available. I'm currently on 4.14.187. This post makes me wary of upgrading.

How do I know which kernel to upgrade to to solve my issue with Tailscale?

How do I roll back if something is not right? I am running the os off the HC1's data drive

 

 

Link to comment
Share on other sites

I think Wireguard kernel modules were not included until 5.6.  Prior to that you have to use dkms (wireguard-dkms package in Debian) which might be pulled in if you install wireguard itself.  If you are on Buster, you should install from backports repository.

Link to comment
Share on other sites

https://github.com/armbian/build/blob/faedda310275334d4fe9b84ef50f99a5480f4910/config/kernel/linux-odroidxu4-legacy.config#L1858

CONFIG_TUN is there. You dont need to upgrade to 5.4 or later. Just get the latest 4.14 and you should be good to go.

Link to comment
Share on other sites

My comment was in general about Debian, as I am long time Wireguard user and dealt with these problems before.  But OP also did not state how he installed (Softy? Tailscale?) and I think Armbian includes some extra things already nowadays on top of vanilla kernel modules.  So perhaps Werner answer is more relevant.  Or maybe we need some more information from OP, or maybe I am just misunderstanding.

Link to comment
Share on other sites

I should add that it was working. Then I ran an update & upgrade from armbian-config and after that I couldn't boot. So I restored from a backup and I think that is when the issue started.

 

Now I am unsure how to proceed. @Werner are you saying I should use armbian-config to change to 4.14.202?

Link to comment
Share on other sites

Yeah. However I still wonder if 187 is that old because if you check blame this has been added two years ago...

https://github.com/armbian/build/blame/faedda310275334d4fe9b84ef50f99a5480f4910/config/kernel/linux-odroidxu4-legacy.config#L1858

 

If you are unsure make a full backup of your system beforehand.

Link to comment
Share on other sites

1 hour ago, j___r said:

To be honest Werner, I'm not sure what that shows.

This shows the default legacy kernel configuration used for the XU4 which is 4.14.x at the moment.

blame does not only allow to see who modified a file at a specific date but also allows to do that for each and every single line in a file. That is why I can now tell that CONFIG_TUN has not recently modified but two years ago from Igor. So this must have been there for quite some time now and it is hard to believe that your kernel is that old that it does not include it yet.

Link to comment
Share on other sites

I only set up this server during June this year. I am pretty sure I used Armbian_5.83_Odroidxu4_Ubuntu_bionic_next_4.14.111 which means I should have config-tun.

So something has happened between the bad upgrade and the restore. 
I just restored my sd card, yet the system os is residing on my data drive. Is there a way I can restore the kernel configuration?

Link to comment
Share on other sites

6 hours ago, Werner said:

Then I have no idea where you dug out this old image. Armbian has new versioning since November '19...

Yes, I wonder...

The two most prominently displayed images on the download page are 4.14

You have to scroll further down to find others with more recent kernels.

Can I upgrade the os on my sata drive without overwriting current configuration and user files?

Screen Shot 2020-11-15 at 10.15.45 am.png

Link to comment
Share on other sites

1 hour ago, guidol said:

but I think you cant upgrade this via armbian-config from 4.1.4 to Kernel 5.4.x

It is not recommended either since 4.14.x is running more stable.

If you run armbian-config which kernels can you choose from? Btw. did you do a causal apt update && apt upgrade recently?

Link to comment
Share on other sites

3 hours ago, Werner said:

Btw. did you do a causal apt update && apt upgrade recently?

Not sure what you mean by causal? 

I did a firmware upgrade via armbian-config and couldn't boot afterward. That was why I restored the SD card from a backup. It seems like the fstab file had been changed in the upgrade.

Link to comment
Share on other sites

5 hours ago, guidol said:

but I think you cant upgrade this via armbian-config from 4.1.4 to Kernel 5.4.x

This is not good news.

Quote

on the page for the hc1 is written that it is a down-stripped version of the Odroid xu4, 

Yes, I knew this. They should probably all be bundled together for this reason. Having said that, like the HC1 downloads page the two most prominent downloads for the XU4 as show on the page are both for the 4.14 kernel. See the note *kernel 5.4 is still considered experimental.

If it is so old why is it being presented as the main option?

Perhaps I should've gone with a ubuntu image direct from hardkernel?

Screen Shot 2020-11-15 at 9.13.48 pm.png

Link to comment
Share on other sites

I suggest do choose the most recent 4.14 kernel, 202 to say.

Even though these kernel switches are usually safe it is always good practice to create a backup of your current configuration (simply create an image of your sd card via dd)

Link to comment
Share on other sites

16 hours ago, Werner said:

I suggest do choose the most recent 4.14 kernel, 202 to say.

So it is true there is no upgrade path beyond 4.14?

Is this true with all types of Linux distributions?

My studies will end soon for summer. Perhaps I am best to start over with Ubuntu or something very mainstream?

Link to comment
Share on other sites

8 minutes ago, j___r said:

So it is true there is no upgrade path beyond 4.14?

Is this true with all types of Linux distributions?

My studies will end soon for summer. Perhaps I am best to start over with Ubuntu or something very mainstream?

 

I think you might not be understanding difference between legacy and current (and dev).  Unfortunately only link I could quickly find was here and it's not what I was expecting (and I think about writing something better).  It seems to me this has been addressed better somewhere, but I can't seem to put my finger on it at the moment.

 

Also not sure what you mean by "start over with Ubuntu or something very mainstream" as that could be interpreted couple different ways?

 

There are some particulars of these little boards that need to be learned, this ecosystem is not exactly the same as x86 GNU/Linux.  However it is worth it IMO, for the benefits one gets in return (small. low power, inexpensive, etc.).

Link to comment
Share on other sites

6 hours ago, TRS-80 said:

I think you might not be understanding difference between legacy and current (and dev).

I do find it not very clear. That page you linked to for example describes current as 'fully supported', but then states that kernel support is dependent on the board family - fair enough, this is a resourcing issue and completely understandable.  It then recommends to use a legacy kernel if there are problems - so are legacy kernel images more or less supported than current?

It then goes on to say - confusingly in my opinion - that testing images are, somehow, simultaneously, 'made from stable branches' but also 'not very well tested'.

 

I guess what I desire is to be on a stable version but to also have the ability to upgrade to a more recent version when that newer version has matured and is considered suitable for non-testing, non-experimental machines.  This is what I am used to I suppose in the macOS environment. I am not interested in the bleeding edge at all but I am now in a situation where a software service that I was using is now - for reasons I don't understand - no longer working, and it seem I have no path to  upgrade to a more modern kernel version to try and get that software service working again.
I started out with a legacy kernel, because I wanted stability (see my posts above about the prominence on the download pages of the images with the 4.14 kernel. But now I find myself in a bind because of this decision with Werner seeming to imply that I had made a bad decision in one post by saying 

Quote

Then I have no idea where you dug out this old image. Armbian has new versioning since November '19...

 

and then a few posts later saying (about upgrading to the newer version).

Quote

It is not recommended either since 4.14.x is running more stable.

 

 

By starting over with Ubuntu I thought might get me that ability, backed by a larger community, wouldn't see me having to deal with these issues.

I think also that for non-professional users such as myself the Linux realm suffers from not having a clearly defined path to knowledge. There is a lot of assumed knowledge among those who deal with this stuff everyday which is natural in any niche industry but it does make it difficult for others.

 

 

 

 

Link to comment
Share on other sites

  • Solution

I think your assessment of that page is pretty spot on.  I started working on improving the docs recently, so I will add this to the list.

 

I could swear I read this somewhere before, but I will try and give a brief summary (and if nothing else, use it as genesis for improving docs):

 

Legacy is the kernel that comes from the mfr at the time the board is released.  Some times it can include certain drivers (particularly multimedia) that can make it better for certain use-cases (i.e., desktop).  Some times, with passage of time, the kernel gets older and older for various reason (some times not receiveing good ongoing support from the mfr, poor documentation so community can not write F/LOSS drivers (and thus get them into mainline kernel), etc.).

 

Current is based on current mainline kernel, and therefore includes whatever is supported in mainline.  This is best for long term support, and things which have good F/LOSS drivers (or even good docs from mfr) will often end up well supported here for a long time.  However until all that is working well there is some period of time where you might be better off on Legacy (and particularly for certain use-cases).

 

Which is better for someone's needs?  Hopefully you can appreciate it's not such a clear cut decision.  It also varies per board and over time.  Hopefully that was at least a little bit helpful, I will work on polishing that up and getting it back into the docs.

 

Whatever is on the download page for a particular device is the currently recommended kernel to use.  This is periodically re-evaluated, but basically it is the current consensus of developers what to recommend at this time.  And so, this is why Werner is recommending that one.  If they are not recommending 5.x current, there is probably some reason for that.  But you would have to go digging through some threads to find out why (FWIW, I also have an ODROID-XU4 and I am not even sure the full reasoning).  Having said that, maybe you try 5.x and it works great for you.  If so, please report back your findings.  Make sure and back up any important data (as always).

 

These Single Board Computers (SBCs) are quite a niche (and complicated) area within the broader GNU/Linux community, and a lot of what is done here at Armbian is quite cutting edge.  I really do not think you will find better support (for SBCs, at least) within the broader community.  Fact is, without Armbian, we would actually even be much worse off (if you can believe that).  I don't think it will probably ever be anything like a MacOS sort of experience, but I agree some things could surely stand improvement.  Which is why (personally) I try and contribute what and where I can.  Because I really enjoy these little devices.  There is no company, no business model, no nothing behind Armbian.  Just a handful of interested hackers and frens spread all over the world.  I'm actually amazed some times we accomplish what we already do on such limited resources.  But that is the reality (to keep things in perspective).

Link to comment
Share on other sites

Thanks for your response and explanation.

I performed the backup and upgraded the kernel to 4.14.202 and it has gone smoothly.

And, Tailscale is back to it's happy self again.

 

I really enjoy these little devices too, so I will continue to try and learn more and more about them and Linux but sometimes it seems bottomless.
I appreciate the efforts of the contributors.

 

Jon

 

Screen Shot 2020-11-17 at 5.58.07 pm.png

Link to comment
Share on other sites

Thanks for reporting back.  I'm glad to hear it worked out!

 

To whatever extent you are able/willing, please consider helping out.  Armbian is just us, mate.

 

Cheers!

 

EDIT: Because title of OP was about kernel education, I took the liberty to mark my own answer as the solution, instead of one right above this, as thread was not directly about getting Tailscale itself working (rather that's a symptom).

Edited by TRS-80
add last paragraph
Link to comment
Share on other sites

Anything is appreciated.

 

I started working on docs recently, it's a little bit of set up with git and Markdown, maybe not for everybody.  Even if you notice something, make a post about or send me PM.

 

Newer people often think they can't contribute anything valuable but that's not true.  Newer people have the unique perspective of being new.  And thus if things are unclear (docs, etc.) please say so, as you are "target market" (for lack of better term) for these docs.  Not the devs who already know much more.  In that vein, you already gave me some good feedback which is what we need to make docs better toward new users.  So, if you have any more just make note, send me a note, start a new thread, come to IRC or whatever.

 

This goes for everybody!

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines