I was having odd issues with a fresh install of 14.1 stable so I decided to update to current with its new kernel, and just wanted to say that it boots much faster. Plus it seems my issues are gone, hopefully no new ones take their place.

Hey Pettijohne,

When you upgraded that system, you upgraded a lot more than the kernel, you may have installed optional dependencies without realizing it, which is why you've seen an increase in performance and a resolution to small problems. The idea that you encountered a kernel bug on the stable 14 release is remote and since the guys who invest thousands of hours in developing these kernel upgrades for little to no compensation (certainly nothing like they'd get if they worked in close source) are probably without question much better coders than I am an admin, I always start from the assumption it's me and not them.
And I haven't been wrong, it's always me being dumb, not an error in their code. Their is a process for reporting kernel bugs, you can even volunteer to beta test new kernel patches and upgrades (I wish I had the time to do that, it's a very in depth and educational process for the beta testers, no doubt). If you have an interest in kernel programming, perhaps you should subscribe to the mailing lists and if you have the time, jump into the beta testing group.

This thread got me slightly confused.

When encountering problems on your system, especially in Slackware, never assume the code is bad, it almost never is, it's normally a bad install (something is corrupt), you're missing a dependency (the ultimate dependency checker in Slackware is the guy behind the keyboard) or you've misconfigured the machine.
With that in mind, it's not nice to throw your issues on the maintainer or core team, especially when you can post no data to support the idea there is a bug ( I don't think that was PettiJohnes intention, but that's what he effectively did).
Be nice to your maintainer and core team, be respectful, they do a huge amount of work on this stuff and they are fantastic at what they do.
If it wasn't for the Slackware maintainer and the core team, I'd still be setting dishes and stringing cable. These guys led the charge from "big iron" to "x86" making a unix-like environment available to the unwashed masses, and they did it because of a desire to help others, not financial gain, so I tend to be defensive of them.

Anybody else has UEFI/GPT boot issues after upgrade slackware64 14.1 -> Slackware64-current? Was OK on fresh install of 14.1, but got kernel panic on boot(just on mount root it seems) after upgrade to current. Reverted to backup kernel(stock 3.10.17 huge? from 14.1) - boot OK. I use default EFI booting option - elilo & kernel on dedicated EFI partition (mounted as /boot/efi). Is there some well-known EFI boot problem of Linux kernel > 3.10.17? Maybe there are some EFI boot options to workaround it in 3.14.4? BTW, on old kernel(stock 14.1) also had EFI boot issues, but only when my old MBR HDD(having more than 4 logical partitions) is connected on boot. But this also causes windows 7 efi boot fail, so I considered it to be normal behavior [both old MBR & new GPT hdd are connected to the onboard SATA3 ASMedia controller in AHCI mode, MB is MSI PH61A-P35 (B3)). On 3.14.4 I get similar (but not the same stack trace) kernel panic even if old HDD is not connected, with a single GPT hdd!

Hi Dad.

The first thing I'd do is check to see if the kernel compiled with the config_efi_partition=y switch. If you can boot off the huge kernel, but not off the kernel that just patched, it would seem it probably didn't.

I'll check, but I believe any stock slackware kernel (even in current) has all the necessary EFI options enabled, see here:

Isn't it more likely to be related to the following kernel bug ? This bug report has attached screenshot of kernel panic with very similar stack trace.(but I'll have to compare with mine to be sure)
Has anybody successfully booted slackware64-current using EFI/elilo?

and you're saying it's present in 3.14.4?
Kernel panics look like panicing kernels, at least to me.
I'd go through the compilation process and check each of the settings and then follow the directions on the slackware site, step by step. Some of the settings are supposed to be default, that doesn't mean you don't have to check them and document what your doing every step of the way.
If that still doesn't work, take a nap, go for a walk, whatever will give you a fresh set of eyes when you go back to square one of the process and repeat it. verifying the match between the directions, your actions the first time you tried it and the current actions.
I've gone as far as the third peice of that process, the repeat after nap section, before finding some dumb mistake I made that created this problem, and I've put this stuff on a lot of oddball architecture over the years.
If you get to the end of phase three and you have not found the issue, then I might consider contacting the distros maintainers and the bug list for kernel.org and asking for any further direction. But those are all busy, busy folks and I would be loathe to waste their time because I can't follow directios.
Try it, I've been in situations where bug lists were not an option, it had to work tomorrow, and it's never failed me.

I dunno, maybe, version stated in the bug report means that the bug was first found in that version. The bug is not fixed yet, so it may be present in later versions, even in 3.14.4?

Stack trace may sometimes have some helpful information. I'll check it.

I did NOT compile this kernel myself - it's a stock kernel image included with slackware64-current. I only got the image and copied it to the EFI boot partition. So if some EFI options are not included - it's a slackware-current bug. The exact steps I did:

1. Clean Installation of Slackware64 14.1 from DVD with elilo and EFI/GPT boot options. EFI Boot OK.
2. Upgrade to slackware current using slackpkg.
3. Copy new kernel image replacing the old image in /boot/efi/...(renamed & stored old image for backup). BTW these images do not use initrd. And old image boots successfully even without modules.(my fault - forgot to backup them )
4. Reboot - get kernel panic just before mount root.
5. reboot to UEFI shell(on USB flash drive) - edit elilo.conf to point to old kernel image.
6. boot old kernel image with no modules.

As you can see - no compilation process is involved at all. So I suppose all the necessary options are already included by the Slackware team.

We looked at a bug ticket, Dad, that doesn't mean there is a bug, it means a bugs been reported. However, that said, the statement above is exactly true.

My mistake.
I'm just always mindful of how many people are using that hardware platform and running this software on it. You'd think if they'd all blown up, there'd be a lot more people with 1st posts screaming "KERNEL PANIC:!!" on these threads.
If you read the instructions from the core team, they suggest bios settings, driver updates it's a list. At this point, I really wish I had on old EFI machine lying around, I'd like to see if I could replicate that issue and debug it.
I need to keep reading about the virtual machine software available in Linux and exactly what the limits of it emulation capabilities are, I'm not even sure you can debug below the operating system with it, or if you can, how you'd do it. Debugging a kernel in a virtual environment might be fun, especially if it wasn't my kernel (I'm screwed vs he's screwed, it's a big difference...)

Well, status of this bug is ASSIGNED. So it seems that kernel developers at some point decided that the bug is valid at least. Is it related to my problem or not - needs further investigation.


I also think so, but maybe not so many people are using 3.14.4(or specifically slackware64-current) with EFI boot and elilo. I think EFI is not so much used on linux, because linux supports GPT drives without EFI.(not the case with windows)

I'm sorry, it turned out I just copied the wrong image - vmlinuz-generic-3.14.4 instead of vmlinuz-huge-3.14.4 and generic requires initrd(panic is considered to be normal if initrd is missing) . Huge kernel 3.14.4 boots OK by ELILO. Switching to generic kernel is not so easy as just copying the image

when you upgraded to current did you remember to do a slackpkg install-new if not your missing a couple of things.

Thanks for reminding, but I have done it and it even installed some packages. BTW it doesn't affect kernel boot usually even if you forget it.

PS. Maybe I'm missing on some more automated installation and upgrade tool than slackpkg? For example debian package manager installs new kernels flawlessly with no need to copy images and manually configure bootloader and even updates initrd automatically. Slackware still doesn't offer such convenience? In 2014 slackpkg looks pretty outdated. Maybe I should try slapt-get or smth else?

Well, as you already know Slackware doesn't offer this kind of "convenience" (I quote this word because most Slackware users don't consider this level of automation being a convenience). Of course you are free to try a third-party tool like slapt-get, but I'm not sure it can help in case of a kernel upgrade (maybe someone who actually used it can tell you that).

About slackpkg, it can seem outdated if you want something more automated, but it does pretty well what it is intended to do.

Also, if you are not (yet) comfortable with Slackware, I'd suggest you stay with 14.1 at the moment instead of running -current, as its aim is mainly to test the future stable release.