I recently installed xubuntu 24.04.2 on a machine (using a usb stick)
and after install, before any updates,
the kernel was 6.11.0-21.
So I added and configured apps,
and created my install medium with this kernel.
Two weeks later I installed the same 24.04.2 usb stick on another machine
(prior to writing over it with the install medium)
and after install, before any updates,
the installed kernel was 6.11.0-24.
So I checked the usb stick to see if it was harboring a wormhole
to a dimension where kernels get to decide among themselves who will get installed,
but no, no wormhole,
and the kernel on the usb stick was: 6.11.0-17.
This is extremely inconvenient,
as the only way to do a copy install from a multiboot system
to another multiboot system
is to have the same kernel on each,
as otherwise /boot and / disagree which kernels are installed
(because on a multiboot system you never overwrite /boot)
and this then requires brain surgery.
Does anyone have any experience here?
I’m guessing the only way around this is to unplug from the network
while doing the installs. This however may bring its own problems.
Why would an upgrade be done before I asked for any updates?
Do all install media do this, or just Xubuntu?
If you had a network connection enabled chose to allow installation of updated packages while you installed the OS you will have automatically got the updated kernel at that time as well as any other packages upgraded between the date you downloaded the ISO file and the date of your second install.
So no dubious wormholes or other problems are likely from this.
If you run sudo apt update on the install with the older kernel version you will probably see that the newer version is now available and I recommend you allow it to be updated as well as anything else available.
when you are installing to a similar single boot system
you can usually just backup the source system
and then copy to the destination system, fixing /etc/fstab on the way.
But to copy to a multiboot system
the key point is to setup and not overwrite /boot
so you first install (from usb) 24.04.2 on the target partitions on the destination system
so / boot is correctly setup,
then you overwrite everything except /boot (and fstab) on the destination system
with the system from the source machine.
Voila (as they say somewhere) you boot the destination system
and it is exactly setup as the source system,
and the systems on the other partitions are still there and happy and bootable.
No, the way I installed works as long as the usb install gives me a predictable kernel version
No, I deliberately don’t do that.
I can be certain of that because:
1 after install,
I do a sudo apt-get -V upgrade (NOT sudo apt -V upgrade)
which upgrades hundreds of packages but not the kernel.
So nothing except the kernel has been upgraded
2 if i did,
it would have both -17 and -21 (or -24). But it only has -21 (or -24),
so they have been installed instead of -17 not after -17.
Of course but that means:
1 I have to have access to my source system - maybe not possible if I am in a different place;
2 I have to delete the previous kernel from the source system,
which I don’t like as I like to keep at least 2 kernels.
3 Other things may have changed on the source system, which I don’t want to propagate;
4 I have to create a new install medium every time this happens (a minor point).
My guess as to the most likely culprit is that
I usually select to install 3rd party drivers and codecs
and that this (reasonably) forces the latest kernel.
I will get a chance to test this in a few weeks when i perform the procedure on another machine.
To do a copy install,
you have a source system (or master) and a number of target systems.
The source system is the one you preconfigure,
(which in my case takes days)
and then back this up to a disk to get what we’ll call the Master Disk.
You then carry this Master Disk around
and on the target systems, you restore the image from the Master Disk
(following the procedures in the above posts)
so you don’t have to hand configure every target system.
(In large environments you may do this over the network,
directly from the source system but of course these will be single boot systems.
That doesn’t apply to a mixed multiboot environment).
So,
if you want to change the master disk, you have to have access to the source system,
which you can’t do if you are in a different location
(in my case in a different country) in a secure way.
Tested various ways of installing 24.04.2 Minimal Install in a VM.
1-- If you de-select:
Install 3rd party s/w for graphics & wifi
Download and install support for additional media formats
the kernel is still updated from 6.11.0-17 to 6.11.0-24.
2-- If, in addition to 1 , you also specify: Dont connect to the internet
the kernel is still updated from 6.11.0-17 to 6.11.0-24.
3-- If you disconnect the machine from the internet by unplugging the cable and hiding it,
the install takes about 4 times longer than normal
but the kernel is not updated, ie 6.11.0-17 is installed.
So silently updating the kernel seems like an implementation choice
and while I can see that there are sensible reasons for doing this,
the option Dont connect to the internet
really should be honored.
So, in this case, it seems we might have an “Answer” but not necessarily a “Solution”.
I have just confirmed that even though I ticked “Do not connect to the internet”, the installer connects and updates packages from the repo. This is a pretty bad bug in the installer, in my opinion, and should be filed in launchpad.
Hello! I was trying to report the bug on launchpad platform directly, but it is asking to use the apport command. I am quite confuse as the bug is observed during the installation process, any idea on how I can use apport to submit this.
