# Can't shut down after kernel upgrade

## Astronome

Ever since upgrading to 4.9.6-r1 from 4.4.39, my system hangs on shut down. (At least I'm pretty sure that's when it started.) The screen turns off and the hard drive spins down, but my fans keep spinning. It stays like this until I hold down the power button to kill it.

At first, I thought it was just an issue with XFCE power manager. I tried shutting the system down from the command line and had the same issue. I also tried exiting X entirely and doing it from the terminal, again with no luck.

As part of a kernel upgrade, I always run `make silentoldconfig` and usually there's nothing to change. However, with this upgrade I had to answer at least a hundred questions. I must have set something wrong, but I'm not sure what. Here's the diff:https://dpaste.de/x3UN/raw

Also, in case it helps, here's `emerge --info`: https://dpaste.de/eYNQ/raw

rc.log looks okay during shutdown, although it seems to be logging everything twice for some reason: https://dpaste.de/9pn0/raw

----------

## ShyPixie

Do you can post a unified diff please? (diff -u)

----------

## khayyam

 *Astronome wrote:*   

> Ever since upgrading to 4.9.6-r1 from 4.4.39 [...] As part of a kernel upgrade, I always run `make silentoldconfig` and usually there's nothing to change. However, with this upgrade I had to answer at least a hundred questions

 

Astronome ... for major kernel version jumps you should start your config from a clean slate (or use a kernel seed from a version in the same series). Why? Well, I don't expect 'oldconfig', and friends, to get it right when so much may have changed, and have seen too many reports of a similar nature to yours to think otherwise.

best ... khay

----------

## Astronome

 *khayyam wrote:*   

> 
> 
> Astronome ... for major kernel version jumps you should start your config from a clean slate (or use a kernel seed from a version in the same series). Why? Well, I don't expect 'oldconfig', and friends, to get it right when so much may have changed, and have seen too many reports of a similar nature to yours to think otherwise.
> 
> 

 

Wow, really? That explains why I find it so hard to manage. I've spent many, many hours on my kernel, and I don't remember exactly what I've changed. I find .config diffs incredibly hard to understand. Sounds like I need to keep a list and manually reapply those changes for major upgrades. It will probably take many more hours to figure that out.

At what point does all this become too much of a chore? Is anyone else here ever tempted to switch back to Ubuntu?

----------

## ct85711

 *Quote:*   

> At what point does all this become too much of a chore? Is anyone else here ever tempted to switch back to Ubuntu?

 

I don't think updating the kernel is really much of a chore when the options I want doesn't change.  Think about the hardware you have in your computer, does it really change much?  I know for my system, I haven't changed any of the hardware in over a year; and none of it is new stuff that just came out.  This means nearly all of the new kernels has few to no new changes for your hardware.  So unless you are using the bleeding edge stuff, you may want to stop worrying about updating the kernel so often.

I know for my machine, I'm using ~amd64 branch, and have some new kernel version almost every week (I sync once a week too).  Even then, I am still running either 4.4.x or 4.6.x series kernel.  Anymore, I update my kernel about once or twice a year, otherwise I leave my kernel alone.

I know you or someone else is going to ask about some potential security vulnerability.  Frankly on that, you need to look at your threat profile.  A good portion of the vulnerabilities are local.  For my threat profile, local threats are of little concern, it's the remote threats that is of some concern.  As long as I keep my self covered so no one hacks into my machine, local vulnerabilities is of little concern.  My thinking is that if someone already hacked into my machine, the system is compromised either way regardless of some kernel vulnerability.  Once my system is considered as compromised, the only way I can consider it safe is wipe it clean and start over.

As for Ubuntu, I personally don't care for that distro.  The biggest gripe I have on Ubuntu, is of the ads they put in the package manager.

----------

## Astronome

 *ct85711 wrote:*   

>  *Quote:*   At what point does all this become too much of a chore? Is anyone else here ever tempted to switch back to Ubuntu? 
> 
> I don't think updating the kernel is really much of a chore when the options I want doesn't change.  Think about the hardware you have in your computer, does it really change much?  I know for my system, I haven't changed any of the hardware in over a year; and none of it is new stuff that just came out.  This means nearly all of the new kernels has few to no new changes for your hardware.  So unless you are using the bleeding edge stuff, you may want to stop worrying about updating the kernel so often.
> 
> I know for my machine, I'm using ~amd64 branch, and have some new kernel version almost every week (I sync once a week too).  Even then, I am still running either 4.4.x or 4.6.x series kernel.  Anymore, I update my kernel about once or twice a year, otherwise I leave my kernel alone.
> ...

 

You make a very good point. When you do finally upgrade your kernel, do you manually reapply your driver selections and all that?

 *Quote:*   

> As for Ubuntu, I personally don't care for that distro.  The biggest gripe I have on Ubuntu, is of the ads they put in the package manager.

 

There are a ton of things I dislike about Ubuntu, which is why I run Gentoo. But the lure of "it just works" is always tempting, especially when basic, fundamental things break on my Gentoo box.

----------

## khayyam

 *Astronome wrote:*   

>  *khayyam wrote:*   
> 
> Astronome ... for major kernel version jumps you should start your config from a clean slate (or use a kernel seed from a version in the same series). Why? Well, I don't expect 'oldconfig', and friends, to get it right when so much may have changed, and have seen too many reports of a similar nature to yours to think otherwise.
> 
>  
> ...

 

Astronome ... as the saying goes: "YMMV" :) ... but that is what I do. However, I don't chase the latest and greatest kernels, I'm still using 3.12.x so I have't had to do much except copy the last config and type 'make oldconfig'. If, or when, I move to 4.x I'll start with a kernel seed and enable what needs enabled (as ct85711 pointed out, once you know your hardware, and what stuff you normally use, it shouldn't take that long).

 *Astronome wrote:*   

> At what point does all this become too much of a chore? Is anyone else here ever tempted to switch back to Ubuntu?

 

Back? I've never used the stuff. Some of us have been using gentoo since before Ubuntu existed.

best ... khay

----------

## ct85711

Like khay, I simply copy my old config that is known to be working to the new kernel and just do make xconfig and just look over any new features otherwise write to the config and compile it.  I do admit that I have a bad habit of not bothering to do make oldconfig, and I do NOT recommend anyone to do that either.  For me, I learned how to configure and compile my own kernel before these "seeds" came about (I first did it, back on kernel 1.x-2.x, before Gentoo came about), so I never used any seed kernel to configure my kernel.  I will admit my kernel has a lot of extra useless stuff included that I don't need, but I haven't bothered to care enough to mess with an configuration that is working perfectly fine.  When I finally upgrade my system to either a skylake or ryzen (or newer CPU), configuring the kernel will take some time, and more likely several recompiles until I get everything I need. Until then, I probably won't update my kernel until >5.2.x is released or I identify an actual need to do so (like nvidia-drivers requiring a newer kernel).

----------

## Astronome

So I figured out where all my modifications were and applied them on top of `make defconfig` but the system still hangs on shut down/reboot. Also I noticed the hard drive doesn't always spin down, just sometimes. For now I'm running the 4.4.39 kernel.

 *ShyPixie wrote:*   

> Do you can post a unified diff please? (diff -u)

 

http://pastebin.com/TXq3xUQs

----------

## Tony0945

Too big a jump. Go from 4.4 to 4.8 first.  

Always  *Quote:*   

> General setup  --->
> 
>    [*] Kernel .config support
> 
>    [*]   Enable access to .config through /proc/config.gz

 

I find most kernel problems on this forum are the result of mis-identification of the actual kernel config or failing to run the kernel that was just built. If the config is stored in the kernel, you always know what it was built with. The RAM and disk space are trivial unless you are running an embedded system.

I semi-automate my builds with a script:

```
#!

cd /usr/src/linux

zcat /proc/config.gz >.config

# At this point we should compare kernel versions and make oldconfig if the base version has updated

make oldconfig

make menuconfig   &&  make -j5 && make -j5 modules_install && make -j5 install && echo "Don't forget to update boot loader menu"

emerge --nodeps net-misc/r8168

```

  Adjust -j5 for your processor. Notice that I build an out of kernel module after building the kernel. If you have no out of kernel modules, erase the last line. If you do, having them in the script keeps you from forgetting to build them.

IIRC, I had problems with 4.9 if I didn't shutdown from the GUI, i.e. "halt" or "reboot" from another terminal. Not having that problem in 4.10

----------

## Astronome

 *Tony0945 wrote:*   

> Too big a jump. Go from 4.4 to 4.8 first.

 

I don't see gentoo-sources:4.8.x here: https://packages.gentoo.org/packages/sys-kernel/gentoo-sources

 *Quote:*   

> I find most kernel problems on this forum are the result of mis-identification of the actual kernel config or failing to run the kernel that was just built. If the config is stored in the kernel, you always know what it was built with. The RAM and disk space are trivial unless you are running an embedded system.

 

I'm sure you're right but I always verify that I'm running the correct kernel with `uname -rv`.

 *Quote:*   

> IIRC, I had problems with 4.9 if I didn't shutdown from the GUI, i.e. "halt" or "reboot" from another terminal. Not having that problem in 4.10

 

It fails to shut down whether I do it from the XFCE menu, xterm inside XFCE, or completely shut down XFCE and do it in the terminal.

----------

## khayyam

 *Tony0945 wrote:*   

> Too big a jump. Go from 4.4 to 4.8 first.

 

Tony0945 ... that is fine if using 'make defconfig' (as is the case), or when using a kernel seed created for 4.9.

 *Astronome wrote:*   

> I'm sure you're right but I always verify that I'm running the correct kernel with `uname -rv`.

 

@Astronome ... ok, but how do know the version build (denoted by the #{n}) actually corresponds with the particular build (and so .config) you've booted? Its easy to forget how many kernels of a release you may have built, and so being able to query /proc/config.gz is IMO preferable to relying on the  output of 'uname -v' ... and your memory. As Tony0945 stated, it uses practically no aditional resources, and you are guarenteed that /proc/config.gz reflects the .config from the booted kernel.

 *Astronome wrote:*   

> [...] but the system still hangs on shut down/reboot.

 

Hangs where ... hwclock? localmount? ... it may not be the kernel, but something init expects but isn't present.

best ... khay

----------

## Tony0945

They've already taken them down (sigh?)

Then go to 4.4.53 (it'll build fine) then 4.9.4 then 4.9.14 running oldconfig all the way.

I'm glad I didn't delete my 4.8 sources.

----------

## khayyam

 *Tony0945 wrote:*   

> Then go to 4.4.53 (it'll build fine) then 4.9.4 then 4.9.14 running oldconfig all the way.

 

Tony0945 ... I wouldn't advise anyone do this, yes 96% of the time it may work, but 4% of the time you will end up with subtle breakages in the build system.

best ... khay

----------

## Astronome

 *khayyam wrote:*   

> 
> 
> @Astronome ... ok, but how do know the version build (denoted by the #{n}) actually corresponds with the particular build (and so .config) you've booted? Its easy to forget how many kernels of a release you may have built, and so being able to query /proc/config.gz is IMO preferable to relying on the  output of 'uname -v' ... and your memory. As Tony0945 stated, it uses practically no aditional resources, and you are guarenteed that /proc/config.gz reflects the .config from the booted kernel.
> 
> 

 

```

$ uname -rv

4.4.39-gentoo #1 SMP Sat Mar 11 23:28:27 MST 2017

```

This is the last kernel I built last night at 11:28. But, yeah, point taken  :Smile: 

 *Quote:*   

> 
> 
> Hangs where ... hwclock? localmount? ... it may not be the kernel, but something init expects but isn't present.
> 
> 

 

That's the hardest part. I have no idea. There's no display. I don't see anything obvious in /var/log/messages or /var/log/rc.log when I reboot. Where should I be looking?

----------

## khayyam

 *Astronome wrote:*   

>  *khayyam wrote:*   Hangs where ... hwclock? localmount? ... it may not be the kernel, but something init expects but isn't present. 
> 
> That's the hardest part. I have no idea. There's no display. I don't see anything obvious in /var/log/messages or /var/log/rc.log when I reboot. Where should I be looking?

 

Astronome ... /var/log/rc.log is only written if you have rc_logger="YES" in /etc/rc.conf ... however that may not catch it as you may be after filesystems are unmounted. So, from console run 'shutdown -h now', or 'shutdown -r now', and see if the process hangs at some service (ie, hwclock).

best ... khay

----------

## Tony0945

 *khayyam wrote:*   

> Tony0945 ... I wouldn't advise anyone do this, yes 96% of the time it may work, but 4% of the time you will end up with subtle breakages in the build system.

  About all that can be done, short of starting all over, since they ripped all the intermediate kernels out of the tree. I've been doing it incrementally, maintaining 4.4, 4.8, and 4.9 weekly. Just shifted recently from 4.9 to 4.10 when that become the tip. The others are long term support. I see they have dumped 4.8 long term support in favor of 4.9  IMHO, 4.8 was a better kernel than 4.9

Kernel.org has been issuing kernels unusually fast. I wonder how they can call something stable after a week of in-house testing. I would call it no more than beta.

If the OP has the same hardware as I, even the same mobo, I would be glad to post a config, but he probably has something different.

----------

## khayyam

 *Tony0945 wrote:*   

>  *khayyam wrote:*   Tony0945 ... I wouldn't advise anyone do this, yes 96% of the time it may work, but 4% of the time you will end up with subtle breakages in the build system. 
> 
> About all that can be done, short of starting all over [...]

 

Tony0945 ... but that is exactly what you need to do to be sure that subtle breakage doesn't occur.

best ... khay

----------

