Liveslak upslak.sh question for custom kernel

Greetings
Rather than wade through a lot of trial and error or try to gain new experience with squashfs I figure it's just simpler to ask here what the preferred method might be for getting a newer kernel than is presently available as a package installed on a Live Slack USB.

Is it as simple as tar'ing a vmlinuz file and the appropriate /lib/modules/<kernel version> directory?

Apparently you never ran "upslak.sh -h" ? Tarring not required.

Originally Posted by Alien Bob Apparently you never ran "upslak.sh -h" ? Tarring not required.

Thanks Eric I will check out the help option but in just trying

 upslak.sh -k vmlinuz-foo -o /dev/sdc

I got a failure with an error message saying "it doesn't appear to be a tar file". I actually then did tar it up and it complained it "couldn't find vmlinuz-generic" (the kernel I want to install wasn't labelled generic). So I'm probably doing something very wrong and the help option might straighten me out since my problem basically is I don't understand working withing the squashfs system. For example must I use a generic kernel plus an initrd?... or can I use something like a Huge kernel or a custom one known to work on a specific box without any initrd?

Anyway I'll study help.

I'll have a look at the script code to determine why you get these errors.

A newer kernel without newer kernel modules would actually not make any sense and would break the Live USB.
A kernel file as argument to "-k" should work. A simple tar-ed up file would not work, because "-k" and "-m" will accept a real Slackware package as argument but not a tarfile you created yourself.

Can you share on a pastebin the output of

bash -x upslak.sh -k <yourkernel> -m <yourmoduledirectory> -o /dev/sdc

?

Not the OP but I was curious and had an old SLACKLIVE usb with the 4.19.50 kernel on it. I tried running the upslak.sh script to put the latest kernel on it and it worked fine when the kernel and modules were passed to the script as .txz packages.

Then I unpacked them and tried running the script again but passing -k boot/vmlinuz-generic-4.19.71 -m lib/modules/4.19.71 instead and got the "This does not look like a tar archive" error.

I took a look at the script and it seems to be related to this function going to the else condition:

# Accept either a kernelimage or a packagename,
# and return the path to a kernelimage:
getpath_kernelimg () {
  local MYDATA="${*}"
  [ -z "${MYDATA}" ] && echo ""

  if [ -n "$(file \"${MYDATA}\" |grep -E 'x86 boot (executable|sector)')" ]; then
    # We have a kernel image:
    echo "${MYDATA}"
  else
    # We assume a Slackware package:
    # Extract the generic kernel from the package and return its filename:
    tar --wildcards -C ${KERDIR} -xf ${MYDATA} boot/vmlinuz-generic-*
    echo "$(ls --indicator-style=none ${KERDIR}/boot/vmlinuz-generic-*)"
  fi
} # End of getpath_kernelimg

Here's the output from bash -x https://pastebin.com/GJ8yDvRr

Originally Posted by Alien Bob A newer kernel without newer kernel modules would actually not make any sense and would break the Live USB. A kernel file as argument to "-k" should work. A simple tar-ed up file would not work, because "-k" and "-m" will accept a real Slackware package as argument but not a tarfile you created yourself. Can you share on a pastebin the output of bash -x upslak.sh -k <yourkernel> -m <yourmoduledirectory> -o /dev/sdc ?

Thanks again, Eric, for your attention to my little problem. I had assumed that I had to use upslak.sh 3 separate times, one each for kernel, kernel-modules and intitrd (if it is required). So I doubt that command would do any good since I was stopped at the very first stage and never got to modules.


Perhaps I should've mentioned that this is something of an experiment. I want to see if Studioware has any advantages for me over what I have accomplished manually. I decided to do this on a boxen I use for testing rather than on my main, since I knew I was going to "play around" with it and didn't want to risk my Main. The other box happens to have a (gift) Creative Soundblaster Zx (ca0132) which requires an extremely new kernel to function in Linux. On a full Current install on that box I'm running kernel v5.2.10 and the SB Zx works very well with just one minor hangnail of having to run Alsamixer with every boot to hit the "M" key on the "HP-Speaker" fader since alsactl-store doesn't keep that set for some reason.

So after 2 days of trying to get a working 5.2.10 custom kernel to install in Live StudioWare to no success, I finally just bit the bullet and created a partition and did setup2hd and then upgraded the kernel to the 5.2.10, side-stepping squashfs. I still have a lot of work upgrading it from 14.2 to Current so I can do an easy Pure-ALSA and MultiLibs mod but at least 5.2.10 is in and sound works.

I'm still curious about how to accomplish a kernel upgrade on Live but it is no longer urgent and I'm very aware of how precious your time is. Thank you again.

Note: At this time I won't yet mark this thread as "Solved" since it really isn't yet and others may learn something useful on this subject and I'm still interested too. I just don't wish to take up your time for something that may only affect a few.

Note-2: Thank you 0xBF for your contribution. I think you may have nailed the problem even if we don't yet have a solution.

Originally Posted by enorbet Thanks again, Eric, for your attention to my little problem. I had assumed that I had to use upslak.sh 3 separate times, one each for kernel, kernel-modules and intitrd (if it is required).

Actually if you provide the kernel and its modules as the two arguments to the script, then the script will re-create the Live initrd, adding the modules for the new kernel that it needs to boot the Live system. There is no separate script argument to also provide an initrd. What you can do, using the "-i" parameter, is provide your own custom init script, i.e. the script that assembles the root filesystem from the various squashfs modules. That script will then be added into the initrd replacing the original init script.

I looked into debugging this a little further today. It seems that the command "file" doesn't like the escaped quotes and returns nothing even if a valid kernel file is passed to it, leading to running the else condition. I removed the backslashes and the script detected the kernel properly. I'm not sure what the original purpose of the escaped quotes were, maybe Eric can shed some light on this.

After that fix the script ran into a couple other hiccups using relative directory names from the getpath_kernelimg and getpath_kernelmods functions (the script cd's out and then can't find some files later). This only happens when not using .txz packages. I tweaked the code to use the absolute directory paths and everything works as expected now.

I know you're a busy guy Eric but if you want to look at the changes I've made I'll attach the output from diff.

Originally Posted by 0XBF I looked into debugging this a little further today. It seems that the command "file" doesn't like the escaped quotes and returns nothing even if a valid kernel file is passed to it, leading to running the else condition. I removed the backslashes and the script detected the kernel properly. I'm not sure what the original purpose of the escaped quotes were, maybe Eric can shed some light on this. After that fix the script ran into a couple other hiccups using relative directory names from the getpath_kernelimg and getpath_kernelmods functions (the script cd's out and then can't find some files later). This only happens when not using .txz packages. I tweaked the code to use the absolute directory paths and everything works as expected now. I know you're a busy guy Eric but if you want to look at the changes I've made I'll attach the output from diff.

Hi 0XBF, thanks for debugging.
I took a slightly different approach to determining the full path of the files (https://git.slackware.nl/liveslak/pa...a5133042345ea2) but thanks anyway for un-fuzzing that double-quote issue.

I just tested your patch out and it worked fine. I was wondering how to correct the file paths with the least intrusion to the script. I like your solution better though

Originally Posted by Alien Bob Actually if you provide the kernel and its modules as the two arguments to the script, then the script will re-create the Live initrd, adding the modules for the new kernel that it needs to boot the Live system. There is no separate script argument to also provide an initrd. What you can do, using the "-i" parameter, is provide your own custom init script, i.e. the script that assembles the root filesystem from the various squashfs modules. That script will then be added into the initrd replacing the original init script.

That's pretty damned brilliant, Brother. It also is coming at an opportune time, since one of my other projects is trying to learn to like initrd. I have avoided it for decades but since the US Atty General has pushed for backdoors into encryption, I conclude it's an important time to learn how to encrypt properly and effectively which requires initrd. I almost expected him to click his heels and shout "Vere are your papers!?!"

I'm also pleased that this thread has resulted in a solid patch that improves an already potent script. Thanks again to all involved.

Originally Posted by enorbet ... but since the US Atty General has pushed for backdoors into encryption...

Sorry for the short off-topic - I just got really worried.
Is there some legislation already in effect? I know debate&proposals were in the news for the last years, even here in EU, but nothing concrete until now. Besides, backdoors just won't make any sense and encryption is/will be uncontrollable:
https://www.schneier.com/blog/archiv...th_of_con.html

Originally Posted by abga Sorry for the short off-topic - I just got really worried. Is there some legislation already in effect? I know debate&proposals were in the news for the last years, even here in EU, but nothing concrete until now. Besides, backdoors just won't make any sense and encryption is/will be uncontrollable: https://www.schneier.com/blog/archiv...th_of_con.html

No, none in effect... yet, but obviously the pressure is there. No problem with a short tangent in my eyes. It's an important issue. It's why I'm "gearing up" now. Backdoors can't be retrofitted without forced updates impossible in Linux. They can be tied to other desirable updates, even made more compelling by lockouts, but it still requires opting in and I'll cross that bridge when I get to it. I'm never going to play the Sanction of the Victim game, and I don't see those in power ever playing it either. What's good for the goose...