I have upgraded my dual boot laptop (Xubuntu) to 19.10, I only had some minor problems:
The system on boot did start scrub of all datapools automatically, that was unexpected and it took a couple of minutes before I realized, why the system was that slow. There is a small chance that the monthly auto-scrub was due, but that would be a coincidence. If it is part of the upgrade do not do it without at least a notification, the same should be valid for the monthly default auto-scrub too. I detected it relatively fast on my conky display, but else??
In the scrub I have been notified, that my datapool did not support all new features and that I had to upgrade the datapool. Of course I followed that advice enthusiastically and now the second 18.04.3 OS does not recognize the upgraded datapool anymore. There should be a stronger warning in the upgrade for stupids like me. Only upgrade the datapool, if all OSes have been upgraded to zfs 0.8. I found out I canāt disable the culprit features, so I have a choice; move everything to 19.10 or restore the datapool from a backup using 18.04.3.
My two other OSes were recognized as expected, one on ext4 and another on zfs too. I will delete 40_custom. I like the facilities in the boot menu.
I also noticed that the old snapshots for the 18.04.3 OS were still valid and displayed by āzfs list -t snapshotā and by the boot menu. I do not believe. I could rollback those snapshot, since all other 18.04.3 binaries will have been deleted during the upgrade to 19.04 and later to 19.10. I did not try a rollback, but I destroyed those old snapshots. The boot menu has been corrected afterwards after I updated it after deleting 40_custom. If upgrading an OS I think you should delete existing snapshots during the clean-up.
I have updated the ext4 Ubuntu OS to 19.10 and I lost all grub entries to the ZFS based systems
The ext4 based systems does still run ZFS version 0.7.12 and has NOT been upgraded to ZFS 0.8.1. Also the upgrade from Linux 5.0 to Linux 5.2 failed, because it booted in 5.0
Running update-grub did detect Linux 5.2, but Grub did not use it for booting.
See also my Ubuntu bug report [Bug 1843222]
We didnāt trigger anything special, so I guess itās part of zfs 0.8 upgrade that does a scrubbing on first boot. I suggest you open a bug report on ZFS so that they provide an integration with systemd or else to signal scrubbing on boot (and we can then integrate with plymouth/others)
Thatās a very valid suggestion for shared pools between different OS (version or distros). I suggest opening a bug against the upstream project for this one as well.
Nice !
Hum, I disagree that we should delete existing snapshots and that you canāt rollback to those snapshots as long as you donāt upgrade the pool with new features. However, indeed, if you upgrade the pool itself (and not the distro), this should prevent rollbacking any datasets that have / or any zfs module that will be loaded. May worth an upstream bug as well?
The good news is that once ZSYS is available and you choose it, ārollbackingā wonāt have the same ādestroying any intermediate datasetsā and you will be able, if you canāt boot on the snapshot, to reboot again on the latest system without loosing anything.
Letās followup on the bug for this one. It sounds like you had a partial upgrade.
I did snapshot the 18.04.3 Xubuntu dataset and after the 19.10 upgrade during the clean-up I agreed to delete all 18.04.3 binaries, so you should delete the 18.04.3 snapshots too, since they are useless. You canāt roll back anymore, since their whole old environment has been destroyed. You will have to consider that for ZSYS too.
Of course you will have to think hard, what to do about snapshots that are on the say common roots directory of say 2 or 3 Ubuntu distros. I would try to prevent/discourage those, avoid that useless complexity.
Iām not sure to understand. You told to remove the binaries, indeed, but that was after the snapshot. So, the older binaries are still part of the previous snapshots content (in the diff, if you prefer), and when you revert, they will be there. Am I getting you wrong?
No, it was too late at night and I was unclear. Here is a better description, I hope.
Over time I did snapshot the 18.04.3 Xubuntu dataset manually. During the standard GUI upgrade from 18.04.3 to 19.04 in that clean-up step I agreed to delete all unused old binaries. I think, you should delete the 18.04.3 snapshots too in that clean-up step, since they are useless afterwards. You canāt roll back anymore, since the old 18.04.3 environment has been largely deleted. For the ādo-release-upgrade -dā there is no clean up step, so there the problem does not exist. For the future GUI upgrades you should have to reconsider the clean-up step and its relation to the previous snapshots of the dataset of the operating system.
I restored the access to my 2 zfs-Ubuntus, by fiddling with /boot/grub/grub.cfg and explicitly pointing to the Linux 5.2 images and rerunning āupdate-grubā afterwards in the ZFS based Xubuntu 19.10/Linux 5.2. I will have to clean-up my systems now. Running update-grub in Linux 5.0 does not detect anything related to /etc/grub.d/10_linux_zfs and in Linux 5.0 I need to fallback to my old 40_custom. Another user might run into the same issue, if he rolls back to linux 5.0 and tries to update-grub from there to repair the 5.2 boot process.
Some of my issues are related to the transition to zfs booting, so maybe you should not solve them in the system, but in the release notes with a clear description, how to circumvent them.
Juste as a side-note: this isnāt a supported upgrade path (we support LTS to LTS or release to next release, without skipping one). This should work for most of the case, but there is no insurance nor testing done.
On the contrary! So, you did a snapshot before the upgrade: you have all binaries, kernels and so on snapshotted (with a separate bpool, you would snapshot as well the separate pool at the same time so that you keep the kernels). Then, the removal happens only on the current datasets, but the snapshots still have them. So you can rollback and this is one of our next use-case (post 19.10) for zsys: snapshotting before upgrade and letting people optionally rollback.
ageed, and if you can report the logs for the partial upgrade (which is the reason why you were running still with zfs 0.7.x), that ould be awesome so that we can fix this general upgrade issue (not related to zfs)
Maybe I am wrong, but I took a snapshot of everything including the home directories in 18.04.3. I upgraded from 18.04.3 to 19.04 (as proposed by the Software Updater!) in the clean-up step they deleted over hundred files. I expect, there is a chance that files on which files in the snapshot depend also are deleted. I do not expect, that the 19.04 upgrade process knows anything about ZFS snapshots.
In the upgrade from 19.04 to the development edition through the CLI there is no clean-up step, so there is no snapshot issue.
My laptop OSes are now completely at 19.10 (1 x ext4 and 2 x zfs). In general I only detected minor issues and the more serious issues were related to my two phase update process from 18.04.3 to 19.04 to 19.10 of a relative complex multi boot PC. Iām cleaning up my laptop now, deleting ā1804ā from host-names and other important issues like that
Next is the upgrade of my Ryzen desktop, but I probably wait for the installer. A clean install, because in April its disks including all installed systems were moved from a Phenom II X4 B97 to the Ryzen 3 2200G.
In general I am happy with the progress, Ubuntu is doing a good job with 19.10 and in my opinion you are back at the leading edge of Linux desktop innovation.
In the past I always did run āUbuntu Cleanerā or Synaptic to loose the deb files, old kernels, configs and unneeded packages. According to Ubuntu Cleaner I now have 1296 deb files, 3 old kernels, 2 package configs and 8 unneeded packages.
I think I can delete the 1 GB of deb files. For the others Iām not sure.
I expect, if I want to loose the old kernels, package configs and unneeded packages, I have to destroy the older snapshots.
Are āUbuntu Cleanerā, āapt autoremoveā, apt clean/autoclean and synaptic still safe to use or might I harm accidentally a snapshot?
In the boot menu all Ubuntu names are the same. In the past, I could distinguish them by partition id, do you intend to add instead of the partition e.g. the dataset name or host name?
The dataset name would be nice for ZFS, but the host name could be the future general solution for all file systems, also ext4, btrfs etc,
No, when you delete a file, a deb or cleaning for cleaning after upgrade, you are deleting them from the current dataset states. They are still present on the older snapshots (as long as you snapshotted all datasets). This is why the snashots will remain valid: if you revert all datasets to a particular snapshots, the files that you cleaned on latest states will be restored, because they were present when the snapshot was taken (which is the whole point of a snapshot).
So, the snapshots remains valid and you can revert to that point (again as long as you reverted all datasets ofc, including /boot for kernels). The only thing that is in a separate partition is /boot/grub (in our incoming new default installs), as there is only one valid per machine.
Installing side-by-side the same version of ubuntu twice is uncommon. We shows when you have multiple installations the version, so you will have:
Ubuntu 19.10
Ubuntu 18.04
for instance, to be able to differentiate them.
Even uncommon, showing the dataset can be helpful, when the exact same version is installed twice. Mind opening a bug against zsys as a reminder (not a high prio, but a nice to fix)?
I have been the whole day without electricity. That is the Caribbean; nice beaches, but sometimes somewhat too basic. Thanks for your reply. I think I start to understand the way the snapshots work and I remembered their explanation in one of the YouTube videos.
Just a remark about the same boot menu items. My two installations are āUbuntu Mate 19.10ā and āXubuntu 19.10ā. If you display it like this, Iām fine, but if you display both like Ubuntu 19.10 nothing is solved for me. To be sure I will write the bug report
I have some problems with both the history and advanced menu items, both did not work and I will file another bug report.
Better to start with desktop to test things out. Desktop has a lot of users and should there be any bugs it will be reported quickly and the damage will be pretty small. But if something goes wrong in a server farm lol, the damage is huge. So better to get things up and running on the desktop first
imo
I downloaded the nightly build of 19.10 to give zfs on root a try. The installer does not have zfs as an option, is there an easy way to try it out (I have used zfs for more than 10 years on servers.)
The installer option is still WIP (there is a merge proposal, but we revisit the design currently). Iāll post here as soon as itās on the daily ISO.
