Script to download extensions+dependencies on other Linux distros

[Rich]

Hi GNUser

... I don't want the newbie user to get an error when they try to download  wireless-KERNEL  , for example.

I think we are on the same page. I was just pointing out that
the infrastructure for handling kernel versions is already in
place. However, it was only applied to the tree files
(dependencies), but not the extension being fetched.

[CNK]

Hi GNUser
If you recall, the title of this thread is:

Script to download extensions+dependencies on other Linux distros

If you are doing this using another distro, there is no way to determine
which kernel the user is running.

Well if you can find the vmlinuz/vmlinuz64 file then it is possible to extract the kernel version using "file" while running on another distro:

Code: [Select]

$ file vmlinuz64
vmlinuz64: Linux kernel x86 boot executable bzImage, version 6.6.8-tinycore64 (tc@box) #666 , RO-rootFS, swap_dev=0x5, Normal VGA

The trouble is finding it, especially on UEFI installations where it's probably on a different partition to the tce directory. You could have an optional variable that the user can set as their path to it though, such as "VMLINUZ=../../vmlinuz" if they're running from inside the tce/optional directory with vmlinuz in the root directory of the same filesystem.

What currently does not work is:

Code: [Select]

tc@E310:~/Fetch$ ./FetchExt.sh input-joystick-KERNEL
.
One or more errors occurred. See Log.txt after timestamp:
Fri May 16 17:21:02 UTC 2025

tc@E310:~
So what's currently missing is testing the file names on the
command line for  -KERNEL  in their file name.

I'll try to look into that later tonight.

Ah, so I wasn't imagining that. I remembered having that problem but I couldn't see how it could be given that the script replaces the kernel version with "-KERNEL" itself in BuildDependencyList().

I recently wrote my own version of your script modified to use zsync for upgrading extensions for new TC versions and keep extensions that haven't been changed. I find it easier to do upgrades "offline" that way than trying to run tce-update on the half-upgraded system. This year's script changes aren't tested yet though since I'm waiting for when I've got access to a more capable internet connection for my upgrade to TC16.

[Rich]

Hi CNK

... Well if you can find the vmlinuz/vmlinuz64 file then it is possible to extract the kernel version using "file" while running on another distro:

Code: [Select]

$ file vmlinuz64
vmlinuz64: Linux kernel x86 boot executable bzImage, version 6.6.8-tinycore64 (tc@box) #666 , RO-rootFS, swap_dev=0x5, Normal VGA

The trouble is finding it, especially on UEFI installations where it's probably on a different partition to the tce directory. You could have an optional variable that the user can set as their path to it though, such as "VMLINUZ=../../vmlinuz" if they're running from inside the tce/optional directory with vmlinuz in the root directory of the same filesystem. ...

It will be even harder to find if you are not running it on the target machine.

When I wrote the script, I made a few assumptions:
1. The users Tinycore install lacked internet connectivity.
2. The user had access to some other Linux release with internet access.
3. The user might be running the script on a different machine.

[CNK]

Well I'm not running on the target machine - in that example I ran "file" on a different Linux distro, but reading "vmlinuz64" from a (USB-connected) drive where TC15 is installed for booting on a different PC.

My thinking is that if someone runs your script, they're going to be wanting the resulting extensions inside a tce/optional directory, usually on the same drive as the TC installation's vmlinuz file. Therefore if they can write to tce/optional from the system running the script, they can probably read the vmlinuz file that will boot that TC installation.

Really it's no easier to find vmlinuz on the target machine or off it, because it's only read by the bootloader. On that TC15 installation of mine the EFI partition where vmlinuz lives isn't even mounted normally while TC is running since it's not used after the bootloader has run. But the script could still try looking in likely places such as "../../vmlinuz" or "../../boot/vmlinuz" for it, which might work for common TC installations.

[GNUser]

But the script could still try looking in likely places such as "../../vmlinuz" or "../../boot/vmlinuz" for it, which might work for common TC installations.

I think the main reason  FetchExt.sh  is so useful is that it can run on any machine, whether or not TCL is present anywhere on that machine.

[CNK]

But the script could still try looking in likely places such as "../../vmlinuz" or "../../boot/vmlinuz" for it, which might work for common TC installations.

I think the main reason  FetchExt.sh  is so useful is that it can run on any machine, whether or not TCL is present anywhere on that machine.

Yes that's the situation I'm talking about!

Somehow nobody's understanding me, so I'll try a more complete example:

Code: [Select]

$ mount /mnt/sdb1
$ cd /mnt/sdb1/tce/optional
$ file ../../vmlinuz64
../../vmlinuz64: Linux kernel x86 boot executable bzImage, version 6.6.8-tinycore64 (tc@box) #666 , RO-rootFS, swap_dev=0x5, Normal VGA
$ ~/bin/FetchExt.sh input-joystick-KERNEL

FetchExt.sh, running on any machine, could now use "file" to work out the TC kernel version of the system that will use the downloaded extensions.

"file" != "uname": its output is unrelated to the system it's running on, "file" can tell you the version of any kernel binary file (vmlinuz). You just need to find the location of that file for the TC installation that's going to use the extensions that FetchExt.sh is downloading - likely close to the tce/optional directory (though not always).