Hi, sorry for the big delay, i had stayed away from messing with system for awhile..
I updated the scripts, but as they are the latest, they work as before, i assume they do the check for updates..
But based on the conversation above, fact is i really don’t need these anymore, as the issues there was before with zfs seems to be resolved, so i will just upgrade as normal for now..
Anyways thanks to @glb and other for all the help and effort!
This does not work with zfs. Not for me anyway. The offline transaction fails to find the ‘disks’ and mount them (any zfs partitions I’ve specified in my /etc/fstab), despite the kernel module loading fine.
Hello, i’ve been away from messing with system, so sorry i didn’t notice tyour message. I trust you resolved your issues?
Reason i write to this thread is i’m preparing now to upgrade to f43 on my root on ZFS system.
First i will do it in a VM clone of my actual system.
Running a KVM virtual machine that is as close as possible to the configuration of my main system has proven invaluable, especially when running a non-standard setup. like root on ZFS.
Testing things can require a lot of reboots, and doing that on the main system would be unbearably painful, when you have multiple live news feeds and millions of web pages open on desktop.. So now i won’t do anything without testing it on the VM first.
In addition to that i use zfsbootmenu, so i will always have a snapshot of my root before doing anything, that i can easily roll back to if anything breaks. Invaluable if i need my desktop for something else, and can’t afford it being down.
So, will report here about any issues regarding root on ZFS.
paging @glb here if he wishes to add any input ( hi and nice to see you btw, happy holidays 
)
Right.. I wonder if i should try to skip the offline upgrade method. So upgrade commands on a updated system with all apps closed should be:
systemctl isolate multi-user.target
dnf system-upgrade --releasever=43
rpmconf -a
I will try this and also the standard dnf system-upgrade download --releasever=43 on the VM and see which is better, as i also want to see errors, and possibly control the global config stuff manually..
(one example is the sshd_config file which has a low number for max login attempts, i have more than 6 ssh keys loaded in ssh agent, so i must increase the limit manually every damn time on every system or ssh login fails.. sigh.. )
update: well the standard offline install went fine in the VM, so i will just try that with the following commands, as per the guide here
dnf up --refresh
dnf system-upgrade download --releasever=43
dnf5 offline reboot
...
rpmconf -a
remove-retired-packages
dnf repoquery --duplicates
dnf remove --duplicates
dnf autoremove
dnf install clean-rpm-gpg-pubkey
clean-rpm-gpg-pubkey
dnf install symlinks
symlinks -r /usr | grep dangling
symlinks -r -d /usr
rm /boot/*rescue*
kernel-install add "$(uname -r)" "/lib/modules/$(uname -r)/vmlinuz"
some notes:
trying to remove old kernels using the script provided in official fedora docs at:
https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-offline/#sect-clean-up-old-kernels
also removes zfs and zfs-dkms from the system:
# ./remove-old-kernels
Package Arch Version Repository Size
Removing:
kernel x86_64 6.16.7-200.fc42 updates 0.0 B
kernel x86_64 6.17.12-300.fc43 updates 0.0 B
kernel-core x86_64 6.16.7-200.fc42 updates 97.3 MiB
kernel-core x86_64 6.17.12-300.fc43 updates 96.9 MiB
kernel-devel x86_64 6.16.7-200.fc42 updates 79.8 MiB
kernel-devel x86_64 6.17.12-300.fc43 updates 83.6 MiB
kernel-modules x86_64 6.16.7-200.fc42 updates 94.6 MiB
kernel-modules x86_64 6.17.12-300.fc43 updates 95.6 MiB
kernel-modules-core x86_64 6.16.7-200.fc42 updates 67.8 MiB
kernel-modules-core x86_64 6.17.12-300.fc43 updates 68.3 MiB
kernel-modules-extra x86_64 6.16.7-200.fc42 updates 4.2 MiB
kernel-modules-extra x86_64 6.17.12-300.fc43 updates 4.2 MiB
Removing dependent packages:
zfs x86_64 2.4.0-1.fc43 zfs 1.9 MiB
zfs-dracut noarch 2.4.0-1.fc43 zfs 25.5 KiB
Removing unused dependencies:
add-determinism x86_64 0.6.0-2.fc43 fedora 2.4 MiB
[...]
perl-vmsish noarch 1.04-520.fc43 fedora 6.6 KiB
pyproject-srpm-macros noarch 1.18.6-1.fc43 updates 1.9 KiB
python-srpm-macros noarch 3.14-5.fc43 fedora 51.5 KiB
python3-pyparsing noarch 3.1.2-14.fc43 fedora 1.0 MiB
qt5-srpm-macros noarch 5.15.18-1.fc43 updates 500.0 B
qt6-srpm-macros noarch 6.10.1-1.fc43 updates 464.0 B
redhat-rpm-config noarch 343-11.fc43 fedora 182.9 KiB
rust-srpm-macros noarch 28.4-1.fc43 updates 5.5 KiB
sombok x86_64 2.4.0-24.fc43 fedora 131.7 KiB
sysstat x86_64 12.7.8-1.fc43 fedora 1.7 MiB
systemtap-sdt-devel x86_64 5.4-1.fc43 updates 184.0 KiB
systemtap-sdt-dtrace x86_64 5.4-1.fc43 updates 180.6 KiB
tree-sitter-srpm-macros noarch 0.4.2-1.fc43 fedora 8.3 KiB
zfs-dkms noarch 2.4.0-1.fc43 zfs 59.4 MiB
zig-srpm-macros noarch 1-5.fc43 fedora 1.1 KiB
Transaction Summary:
Removing: 225 packages
After this operation, 889 MiB will be freed (install 0 B, remove 889 MiB).
Is this ok [y/N]: n
so BAD idea. This might be a bug the package maintainers would like to know, so anyone knowledgeable enough could report this bug?
Also: running clean-rpm-gpg-pubkey seems to exit with a ZFS repo related issue:
# clean-rpm-gpg-pubkey
Downloading file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-43-x86_64 for:
Fedora 43 - x86_64 (/etc/yum.repos.d/fedora.repo)
Fedora 43 openh264 (From Cisco) - x86_64 (/etc/yum.repos.d/fedora-cisco-openh264.repo)
Fedora 43 openh264 (From Cisco) - x86_64 - Debug (/etc/yum.repos.d/fedora-cisco-openh264.repo)
Fedora 43 openh264 (From Cisco) - x86_64 - Source (/etc/yum.repos.d/fedora-cisco-openh264.repo)
Fedora 43 - x86_64 - Debug (/etc/yum.repos.d/fedora.repo)
Fedora 43 - Source (/etc/yum.repos.d/fedora.repo)
Fedora 43 - x86_64 - Updates (/etc/yum.repos.d/fedora-updates.repo)
Fedora 43 - x86_64 - Updates - Debug (/etc/yum.repos.d/fedora-updates.repo)
Fedora 43 - Updates Source (/etc/yum.repos.d/fedora-updates.repo)
Fedora 43 - x86_64 - Test Updates (/etc/yum.repos.d/fedora-updates-testing.repo)
Fedora 43 - x86_64 - Test Updates Debug (/etc/yum.repos.d/fedora-updates-testing.repo)
Fedora 43 - Test Updates Source (/etc/yum.repos.d/fedora-updates-testing.repo)
Downloading file:///etc/pki/rpm-gpg/RPM-GPG-KEY-openzfs-fedora-43 for:
ZFS on Linux for Fedora 43 (/etc/yum.repos.d/zfs.repo)
ZFS on Linux for Fedora 43 - Source (/etc/yum.repos.d/zfs.repo)
ZFS on Linux for Fedora 43 - Testing (/etc/yum.repos.d/zfs.repo)
ZFS on Linux for Fedora 43 - Testing Source (/etc/yum.repos.d/zfs.repo)
curl: (37) Couldn't open file /etc/pki/rpm-gpg/RPM-GPG-KEY-openzfs-fedora-43
Could not execute curl
And finally for some reason the rescue kernel had not been generated, even though dracut-config-rescue was installed. Don’t know if this is an issue, or important at all.. I did generate it as per the guide..
So, just some notes from the upgrade on Fedora root on ZFS system.. seems like a pretty easy process..
I’ve hit that error as well. I work around it by setting IdentitiesOnly yes and IdentityFile ~/.ssh/my-server-NN-ssh-key in my ~/.ssh/config under a Host ... section so that “server-nn” will use the right key on the first try rather than trying a bunch of incorrect keys and getting locked out. E.g. :
Host node-??
PreferredAuthentications publickey
IdentitiesOnly yes
IdentityFile ~/.ssh/%n
User phong
I’ve never tried to use that script, but if you want to do that, I’d try adding -x zfs\* to the dnf remove ... command. Personally though, I think it is probably better to leave a few older kernels+initramfs installed as fallback options in case you mangle your primary kernel+initramfs with some random driver update or something in the future.
I’m not sure what is happening there. It’s another command that I’ve never used. FWIW, that file does exist on my system:
$ ls -al /etc/pki/rpm-gpg/RPM-GPG-KEY-openzfs-fedora-43
lrwxrwxrwx. 1 root root 24 Nov 11 18:00 /etc/pki/rpm-gpg/RPM-GPG-KEY-openzfs-fedora-43 -> RPM-GPG-KEY-openzfs-2022
Do you have a file like the following on your system?:
$ cat /etc/dracut.conf.d/rescue.conf
dracut_rescue_image=no
Personally I’d rely on the fallback kernels rather than trying to keep the rescue kernel updated. One reason being that there is no guarantee that the rescue kernel actually works since it likely has never been used. The fallback kernels are just the previous “known good” kernels that you had used previously.
HTH 
gb
Good info, that is on the client from which i connect right? Might try to implement that.
Yeah, previously i’ve ran it without issues on the test VM (just to test all the commands in the guide) but i do leave older kernels on my main system. Still, it’s in the guide, and from memory it didn’t remove zfs before, so i assume it’s a bug..
yeah, same as above, and i do always have snapshots to rollback to using zfsbootmanager, so i actually never even rely on older kernels or rescue kernels, if an update results in a unbootable system, i rollback the whole root including /boot, and leave it to another day, i’m too old to try to rescue my system, i need my desktop 24/7 
Thanks for your reply
Nope, I’ve still never found a proper solution. My workaround is to comment out all of my ZFS related entries in /etc/fstab - thankfully I have nothing critical there (at least, critical for the OS/upgrade operation).
without knowing your issue well, have you tried defining mountpoints in zfsprops instead? i don’t mount any zfs datasets using fstab.
# zfs get mountpoint zroot/home
NAME PROPERTY VALUE SOURCE
zroot/home mountpoint /home local
I’m not sure that /etc/fstab is included in the initramfs anymore. (I think this is a recent change in Fedora Linux.)
When I run sudo lsinitrd | grep fstab, I get a zero-byte fstab.empty file, even though I have a non-zero /etc/fstab:
$ sudo lsinitrd | grep fstab
-rw-r--r-- 1 root root 0 Oct 13 19:00 etc/fstab.empty
-rwxr-xr-x 1 root root 57856 Oct 13 19:00 usr/lib/systemd/system-generators/systemd-fstab-generator
lrwxrwxrwx 1 root root 41 Oct 13 19:00 usr/lib/systemd/systemd-sysroot-fstab-check -> system-generators/systemd-fstab-generator
Investigating this just now, I’ve noticed that there is a use_fstab option that is now documented in the dracut.conf man page:
$ man dracut.conf | grep -A 2 use_fstab
use_fstab="{yes|no}"
Use /etc/fstab instead of /proc/self/mountinfo (default=no).
You might try creating a drop-in conf file under /etc/dracut.d with the following line and then regenerate your initramfs with dracut -f.
use_fstab="yes"
This.
this is what i find frustrating about linux. They drop the fstab from initramfs, and leave it up to the user to find that entry in dracut.conf.
That should not be. If a user uses fstab, any system upgrade should not break that.. just my opinion
To be fair, there is a system for notifying users about “significant” changes. It’s the Fedora Changes which begin as change proposals posted to this forum. But there is a lot that seems to slip under that “significant” threshold.
i see a future where all system and user configuration settings are maintained in a giant extremely complicated file, like the microsoft windows registry, and is maintained and edited using AI.
In that case AI would have realized the user has fstab entries needed early in boot process, and conserved them automatically
A user should be able to open AI chat on the desktop, and say:
Since i upgraded my system, some of my partitions fail to mount. fix it. And also, everytime i open my budget spreadsheet, i want it to open on my right side screen, maximized, and scrolled down to line 47. Make it so.
And the system should do all this. that’s what i want. a true AI OS.
You have much more faith in AI than I do. That said, it looks like there is an initiative to build some sort of AI assistant for Fedora Linux.
Excerpted from F43 FESCo Elections: Interview with Máirín Duffy (duffy/mizmo):
Technology has an increasingly large impact over society. We should have agency over the technology that impacts our lives. Open source is how we provide that agency. We’re now in a time period with a new disruptive technology (generative AI) that – regardless if you think it is real or not, is having real impact on computing. Fedora and other open source projects need to be able to provide the benefits of this new technology, the open source way and using open source software. Small, local models that are easy for our users to deploy on their own systems using open source tooling will provide them the ability to benefit AI’s strengths without having to sacrifice the privacy of their data.
But IMHO, the old “Garbage in, garbage out” rule still reigns supreme. Such a system would probably work best if its inputs were limited to the system’s man pages and I wouldn’t expect much. Just my 2¢.
@unused-hardhat I have not tried (or heard of) zfsprops, I’ve only ever used /etc/fstab as this seems to be the Linux way. I’ll look into it.
@glb I’ll look into this too, but it would seem to me that fstab is getting included since the contents of that file affect whether or not my system upgrade succeeds 
Well, the situation might be a little more complicated than that.
Looking at /usr/lib/dracut/dracut-functions.sh:
# find_block_device <mountpoint>
# Prints the major and minor number of the block device
# for a given mountpoint.
# Unless $use_fstab is set to "yes" the functions
# uses /proc/self/mountinfo as the primary source of the
# information and only falls back to /etc/fstab, if the mountpoint
# is not found there.
# Example:
# $ find_block_device /usr
# 8:4
find_block_device() {
local _dev _majmin _find_mpt
_find_mpt="$1"
if [[ $use_fstab != yes ]]; then
[[ -d $_find_mpt/. ]]
findmnt -e -v -n -o 'MAJ:MIN,SOURCE' --target "$_find_mpt" | {
while read -r _majmin _dev || [ -n "$_dev" ]; do
if [[ -b $_dev ]]; then
if ! [[ $_majmin ]] || [[ $_majmin == 0:* ]]; then
_majmin=$(get_maj_min "$_dev")
fi
if [[ $_majmin ]]; then
printf "%s\n" "$_majmin"
else
printf "%s\n" "$_dev"
fi
return 0
fi
if [[ $_dev == *:* ]]; then
printf "%s\n" "$_dev"
return 0
fi
done
return 1
} && return 0
fi
# fall back to /etc/fstab
[[ ! -f "$dracutsysrootdir"/etc/fstab ]] && return 1
findmnt -e --fstab -v -n -o 'MAJ:MIN,SOURCE' --target "$_find_mpt" | {
while read -r _majmin _dev || [ -n "$_dev" ]; do
if ! [[ $_dev ]]; then
_dev="$_majmin"
unset _majmin
fi
if [[ -b $_dev ]]; then
[[ $_majmin ]] || _majmin=$(get_maj_min "$_dev")
if [[ $_majmin ]]; then
printf "%s\n" "$_majmin"
else
printf "%s\n" "$_dev"
fi
return 0
fi
if [[ $_dev == *:* ]]; then
printf "%s\n" "$_dev"
return 0
fi
done
return 1
} && return 0
return 1
}
It is quite possible that the failure (return 1) is happening in that first if block when use_fstab is not set to yes. I don’t know where that find_block_device function is being called from (or indeed that that is the actual problem), but ZFS pools tend to be backed by more than one block device and I doubt that this code is designed to work with them. Glancing at it just now, I’m not sure that use_fstab would help much either. You might be better off going with Unused-Hardhat’s previous suggestion.
Scratch all that. You’re right, if changing the contents of the file affects the update, then that probably isn’t the problem. Sorry, I don’t know what is going on. Personally, I never use the offline updater. I have no confidence in it.
could we get the contents of your fstab file?