# kernel panic after upgrading glib

## genterminl

I have a mostly amd64 system with a selection of ~amd64 packages.   I just updated glib from 2.48.2 (stable) to 2.50.3 (testing) to see if it solves a separate problem I'm having with a different application.  Kernel is currently 4.9.6, which has been working fine for a while.  When I rebooted after the upgrade, I get a kernel panic: no working init found.  My suspicion is that there are probably other packages I should have re-emerged before rebooting.  (At least I hope that's all it is.)  I did boot an old live-CD (most recent I have, but years old) and when I try to do a chroot, I get a FATAL: kernel too old, which makes sense because the kernel on the live-CD is 2.6.19.

I'm currently downloading a new live-CD, but on my slow DSL, that will take a few hours.  I was hoping someone might have a suggestion of something I might try before that, and also any thoughts on what specific packages should be rebuilt.  I didn't notice any mention of preserved libs after my upgrades, and I'll also try a revdep-rebuild, but hopefully I can be more direct at findind/fixing the problem.

Mounting my / under the live CD, /sbin/init is dated from last June, but I don't see anything that looks amiss about it.

Thanks for any suggestions.

----------

## khayyam

genterminl ...

I don't think it's related, dev-libs/glib provides nothing for sys-apps/sysvinit (which provides /sbin/init) ...

```
% equery belongs -e /sbin/init

 * Searching for /sbin/init ... 

sys-apps/sysvinit-2.88-r9 (/sbin/init)

% ldd /sbin/init

  linux-gate.so.1 (0xb7748000)

  libc.so.6 => /lib/libc.so.6 (0xb758f000)

  /lib/ld-linux.so.2 (0xb7749000)

% equery -NC depgraph =sys-apps/sysvinit-2.88-r9

 * Searching for sysvinit2.88-r9 in sys-apps ...

 * dependency graph for sys-apps/sysvinit-2.88-r9

 `--  sys-apps/sysvinit-2.88-r9  x86 

   `--  sys-libs/libselinux-2.6  (>=sys-libs/libselinux-1.28) x86 

   `--  virtual/os-headers-0  (virtual/os-headers) x86 

[ sys-apps/sysvinit-2.88-r9 stats: packages (3), max depth (1) ]
```

It sounds as though your root= points to the wrong partition, or perhaps the filesystem is corrupted.

best ... khay

----------

## genterminl

khayyam - thanks for the response.  

Based on history, it's bound to be something strange or obscure.  I just assumed the message referred to /sbin/init but all it actually says is no working init found.  Note that I do not use any "init thingy" (to steal someone else's term) and /usr is not separate.  I did mount both / and /boot from the liveDVD, so if one of them is corrupt, it a subtle thing, and not enough to prevent mounting and some searching.  There is no init= line in my grub (old grub, not grub2) line, and I actually did try two different kernels with the same result.  I also didn't think glib would be relevant here, but I suspect gtk+ even less, which is the only other thing I just upgraded.

I'm not home now, but hopefully I'll have a good, new livedDVD that will let me chroot and see what kind of other evidence I can find.  I'll post again once I find anything of interest.

----------

## genterminl

Well, I can confirm that the upgrade of glib was purely a red herring.  However, I'm now pretty confused.

It turns out everything seems to be working fine, just by changing /dev/sdbN to /dev/sdaN for specifying root= in grub.conf.  This seems odd to me, because the last time I played at all with moving drives around was  weeks ago when I had to replace my power supply, and I've rebooted several times since then.  I use UUIDs in /etc/fstab, but obviously something got flipped around.

Is there any way to avoid this in grub.conf?  I recall looking into this the last time I fixed up /etc/fstab, and don't remember any way around using /dev/sdXN for root=.  I suppose I've got some more reading cut out for me.  

At least I'm back in business.

----------

