The officially official Devuan Forum!

siva

Member

Registered: 2018-01-25

Posts: 282  

SOLVED - chroot live build - kernel panic

I installed a live build of jessie from chroot and everything works okay.  However, when I installed the backported kernel, the system spit out a kernel panic at boot.  I suspect I missed a step, and would be skeptical of refractasnapshot only if it also kernel-panicked with the stock jessie kernel as well. 

Procedures (all as root):

apt-get -t jessie-backports install linux-image-amd64
(update-initramfs loads automatically)
(update-grub runs automatically)
refractasnapshot

SOLUTION: install/backport the ascii+ versions of live-boot live-config live-config-sysvinit live-boot-initramfs-tools.  Backporting/installing the former two will also backport/install the latter.  For convenience, I've uploaded them to the crunkbong github page here, but I don't intend to maintain it after ascii reaches stable.

Last edited by siva (2018-05-06 20:07:04)

fsmithred

Administrator

Registered: 2016-11-25

Posts: 2,486  

Re: SOLVED - chroot live build - kernel panic

What do you mean by "installed a live build from chroot"?

There's something wrong in the initrd. Is this installed on a removable drive? ? Or from a snapshot that was made on a system that has a swap partition or an encrypted partition?

Edit: If you make a snapshot of a system that has more than one kernel, you may need to copy the extra kernel and initrd to $work_dir/iso/live/, and if you want both kernels available in the live iso, they must be named differently and you must create boot menu entries for the extra kernel.

siva

Member

Registered: 2018-01-25

Posts: 282  

Re: SOLVED - chroot live build - kernel panic

what do you mean by "installed a live build from chroot"

Sorry if that was unclear.  I debootstrapped a system and develop it through chroot; that includes running refractasnapshot within the chroot environment, and accessing the iso from the host filesystem later on.  I don't believe this approach uses swap in the way you inquired below.  Also, nothing is encrypted.

With the normal jessie kernel, the iso produced works as expected, whether I'm entering the live environment through a virtual machine (qemu), or dd-ing the iso onto a removable drive (usb).  Actually, you would know, since you tested it for me.
https://dev1galaxy.org/viewtopic.php?pid=8241#p8241

One thing I forgot to mention in the original post is that I'm trying to replace the kernel altogether, although I do intend to experiment with a version that includes two kernels in the future.  For now, I'm inquiring about replacing the jessie kernel with a backported one.

Using the procedures in the original post, I've tried:
a. removing the jessie kernel and then installing the backported one, and
b. installing the backported one and then removing the jessie
Both produce the same kernel panic message.  What I also find weird is that, no matter what, when I uninstall the bpo and re-install jessie's, it goes back to working as expected.  I did not attempt a snapshot which included both jessie's kernel and the bpo.

Researching the panic led to ambiguous results, not to mention the screen cuts off because it's something like a 640x480 resolution.  My gut tells me that this is an initrd error, but I've never encountered an issue like this before.  I've even manually ran the initrd and grub update commands after the bpo kernel is installed, even though it runs those during installation anyway.

Last edited by siva (2018-05-01 20:10:23)

fsmithred

Administrator

Registered: 2016-11-25

Posts: 2,486  

Re: SOLVED - chroot live build - kernel panic

cp /boot/initrd.img-4.14-whatever .
mkdir extracted
cd extracted
zcat ../initrd.img-blah  | cpio -i

Then examine the files in conf/conf.d/. Look for something that has a wrong uuid or device name.

When you install a newer kernel, it takes over the symlinks, /vmlinuz and /initrd.img, which will be used by refractasnapshot. It copies them to  work/iso/live. The usual procedure is to install the new kernel first, then remove the old kernel. There are two reasons for doing it in this order: 1. Usually, the old kernel is running when you do this, so you can't remove it until you boot into the new kernel. 2. In case the new kenel doesn't work, you can still boot the old one. Since you're doing this in a chroot, it shouldn't matter.

If you want more than one kernel in the iso, you need to copy it to the same place with a different name, and you need to make a boot entry for it. Make sure you have set save_work=yes in the config file.

siva

Member

Registered: 2018-01-25

Posts: 282  

Re: SOLVED - chroot live build - kernel panic

I checked everything and nothing seemed weird.  I also removed both kernels and reinstalled the bpo amd64.  However, this recent build is giving some weird issue about aufs:
https://preview.ibb.co/m4CsB7/Screensho … _04_AM.png
This bug report suggested that the post-jessie kernels no longer use aufs, and have replaced it with overlayfs.  It didn't offer a real solution, though. 
https://bugs.debian.org/cgi-bin/bugrepo … =844749#30

sed -i "s/LB_UNION_FILESYSTEM=\"aufs\"/LB_UNION_FILESYSTEM=\"overlay\"/g" config/chroot

where config/chroot is an ambiguous directory, which is unhelpful.

I find this weird because I can run the backported kernel on my build system (devuan jessie) just fine.

Last edited by siva (2018-05-04 01:44:17)

fsmithred

Administrator

Registered: 2016-11-25

Posts: 2,486  

Re: SOLVED - chroot live build - kernel panic

There's no more aufs in the kernel (4.9 or 4.14)

You may need a newer version of live-boot* and live-config*. 20170112 should work (works for me) and is in ascii.
If you have a union=aufs (or union=anything) in your boot command, remove it.

The fix in that bug report was for live-build, which is not used here.

siva

Member

Registered: 2018-01-25

Posts: 282  

Re: SOLVED - chroot live build - kernel panic

There's no more aufs in the kernel (4.9 or 4.14)

That's the gist I got :\

You may need a newer version of live-boot* and live-config*. 20170112 should work (works for me) and is in ascii.

Thanks, I noticed that jessie's versions are considerably older, live-config in particular.  I'll try the live-build backport just in case.  If it still fails, and manually backporting isn't worth it, I'll just consider upgrading to ascii sooner than anticipated.

If you have a union=aufs (or union=anything) in your boot command, remove it.

There is no union=* in the boot command.  A few sites suggested to try union=overlay, which I tried, but that failed.

Last edited by siva (2018-05-04 13:24:36)

fsmithred

Administrator

Registered: 2016-11-25

Posts: 2,486  

Re: SOLVED - chroot live build - kernel panic

If the backports version doesn't work, try the ascii version. You should be able to install it in jessie. In the past (couple years ago) I used the sid version in debian jessie.

siva

Member

Registered: 2018-01-25

Posts: 282  

Re: SOLVED - chroot live build - kernel panic

Well, I manually backported both of them, and that solved the first chunk of problems.
https://github.com/souperdoupe/crunkbon … -backports

Sadly, it's still complaining about ehci-orion not being in modules.dep.  I'm not sure if this can/should be patched or if it's available in some other package.
https://ibb.co/h9o2yn
The 3.16 modules.dep file doesn't contain ehci-orion at all, either, but it doesn't err.  This seems to be an issue that keeps popping up with the 4.9+ kernels.

Last edited by siva (2018-05-05 19:08:27)

fsmithred

Administrator

Registered: 2016-11-25

Posts: 2,486  

Re: SOLVED - chroot live build - kernel panic

still complaining about ehci-orion not being in modules.dep

It always says that when there's a problem. Don't chase that ghost. What was in conf/conf.d/ in the initrd? That's usually where the problem is.

siva

Member

Registered: 2018-01-25

Posts: 282  

Re: SOLVED - chroot live build - kernel panic

still complaining about ehci-orion not being in modules.dep

It always says that when there's a problem.

Why does it give that particular message?  It seems way too vague.

What was in conf/conf.d/ in the initrd? That's usually where the problem is.

The folder conf contains two files and one folder:
arch.conf contains one line: DPKG_ARCH=amd64
conf.d is completely empty.
I uploaded initramfs.conf to pastebin.  Not really sure what any issue would be...
https://pastebin.com/ChjY6Kzm

Edit: I compared it with the jessie (3.16) initrd.img.  The results were exactly the same, including the contents of conf.d and initramfs.conf.

Last edited by siva (2018-05-05 22:36:39)

fsmithred

Administrator

Registered: 2016-11-25

Posts: 2,486  

Re: SOLVED - chroot live build - kernel panic

I think the ehci-orion message just happens to occur near the point when init tries to switch-root, and that's a common place for problems.

I can confirm that your basic procedure works. I have a new install of desktop-live on my hard drive, so I chrooted into it and started making isos. I had to do a little more, because it's an encrypted install, (remove conf/conf.d/cryptroot from initrd). Installed 4.15 from backports, did not remove 4.9, made another snapshot and it boots 4.15 normally.

Oh yeah, I had to remove intel-microcode before I could unpack and repack the initrd.

And I didn't backport anything. Just running ascii and chrooting into another ascii install. Maybe something else in jessie needs to be upgraded for this to work.

fsmithred

Administrator

Registered: 2016-11-25

Posts: 2,486  

Re: SOLVED - chroot live build - kernel panic

Just noticed something while closing tabs - you only did live-boot and live-config. You might need to add live-config-sysvinit and live-boot-initramfs-tools. I'm pretty sure you can install the newer versions without backporting them.

siva

Member

Registered: 2018-01-25

Posts: 282  

Re: SOLVED - chroot live build - kernel panic

My hero

Those two packages did the trick.  Also, it turns out they were compiled alongside live-boot and live-config -- they were residing in the same directory as the compiled debs.  So, backporting live-boot/config built them, and all I had to do was install them.  Shame on me for not checking the other debs that were originally created and should have been installed lol.

Problem solved -- even works with the newest liquorix kernel.

Last edited by siva (2018-05-06 20:10:37)