| === linux is now known as Linux | ||
| Delemas | Lots of attempts and partially functional solutions but I have yet to find something with a clearly working offline upgrade for Ubuntu ex. 20.04 to 22.04. I need some way to cache everything for a do-release-upgrade, turn off Internet and upgrade. Anyone seen a working how to? | 14:10 |
|---|---|---|
| tomreyn | i guess you could create local mirror servers. but this may not be worth it for a single system upgrade. | 14:25 |
| ravage | for a single system i would clone the system (rsync?) upgrade it where i have internet connection and rsync it back. possibly to the clone process from a live usb | 14:29 |
| ravage | if you have multiple systems a local mirror is the way to go. you need about 2TB of space for it | 14:30 |
| JanC | could just move the system too then | 14:31 |
| JanC | instead of using rsync twice | 14:32 |
| ravage | sure. but in case the upgrade fails you still have the old one | 14:32 |
| JanC | you can also upgrade without do-release-upgrade, which allows you to find the packages needed and then download them elsewhere, but that's much trickier | 14:33 |
| ravage | with some external HDD and a laptop a local mirror is easy to create | 14:34 |
| JanC | yeah, creating a local mirror is easiest | 14:34 |
| ravage | in general the idea of a system that will not get any security updates in the future is bad | 14:35 |
| JanC | and maybe for a simple server you won't need anything outside main | 14:35 |
| ravage | so maybe the best solution here is to provide access to a mirror on the internal network or some proxy | 14:35 |
| JanC | if it doesn't have internet access at all, the security might not be too bad | 14:35 |
| tomreyn | Delemas: i think these responses are to you | 14:36 |
| ravage | i think do-release-upgrade downloads some stuff when you execute it | 14:37 |
| ravage | you would have to provide that offline too somehow | 14:38 |
| ravage | a jammy.tar.gz or so? | 14:38 |
| JanC | WCS you just use apt upgrade | 14:38 |
| JanC | or aptitude | 14:39 |
| JanC | (or both) | 14:39 |
| ravage | that may work. but also skips a lot of special migrations steps. i dont think they coded that tool just for fun | 14:39 |
| JanC | most of those issues can be solved manually (aptitude, or synaptic if you want a GUI can be useful for that), and I would not expect many in case of a server (if it doesn't have a desktop installed) | 14:44 |
| tomreyn | you'd need to also mirror http://changelogs.ubuntu.com/ (or parts of it) | 14:45 |
| tomreyn | also, if you're upgrading from an EOL release, need to include old-releases.ubuntu.com (or relevant parts of it), too | 14:46 |
| JanC | I'd hope it doesn't break if that's not available? | 14:46 |
| Delemas | I've been doing OS upgrades since the early RH days when I had to write my own scripts to do it. Better upgrade handling was one of the reasons I switched to Debian and Ubuntu many years ago. Given my profession I get a lot of offline upgrade needs in different forms. | 14:46 |
| tomreyn | JanC: i'd bet it bails out with an error | 14:47 |
| JanC | Delemas: just use the "old style" change repositories + apt upgrade with a local mirror then | 14:48 |
| Delemas | For the low security case I was hoping to pre-cache the files for an upgrade but that isn't a supported use case with do-release-upgrade. | 14:48 |
| tomreyn | Delemas: so providing internet to security and other updates from a fixed set of locations is not an option in this scenario? | 14:48 |
| JanC | you can then keep the local mirror (USB disk, or whatever) up-to-date to do security updates whenever you have access to the machine | 14:50 |
| tomreyn | doing what JanC suggests is also not a supported use case (just an unsupported, incomplete fallback) | 14:50 |
| Delemas | In my immediate case I want to upgrade a server which is also a host to my internet firewall VM. I can connect LTE to it but that gets quite expensive to do a whole OS upgrade over LTE. | 14:50 |
| JanC | well, not having internet access is not supported, it seems | 14:50 |
| tomreyn | Delemas: wait, you can connect an unrestricted wireless internet access but not a restricted, wired, one? | 14:51 |
| Delemas | In low security, to upgrade a system you have no easy way to upgrade otherwise, yes it is an option. Obviously not what you want to keep connected. | 14:52 |
| JanC | I suppose the issue is that the host tries to connect through the VM? | 14:53 |
| Delemas | There are systems which can never talk to the Internet. | 14:53 |
| Delemas | Exactly and when the virtualization platform is being upgraded that must be off. | 14:53 |
| JanC | can't you change the networking on the host temporarily for the upgrade? | 14:54 |
| tomreyn | I guess your scenario sounds like one where you should do local mirroring | 14:54 |
| ravage | ^^ | 14:54 |
| ravage | for that LTE option you can setup a local http cache. nginx does that for example | 14:55 |
| Delemas | The networking change option is the LTE option. Either that or building another virtualization host for the sake of hosting the firewall during the upgrade. | 14:56 |
| ravage | so you only need to download packages you did not already download before | 14:56 |
| Delemas | Yes some kind of caching proxy would help greatly. | 14:57 |
| JanC | maybe do-release-upgrade should have a download-only option... | 14:59 |
| Delemas | Never quite understood why do-release-upgrade -s disappeared. That was helpful to see if upgrades would work and to cache files with a proxy. | 14:59 |
| JanC | oh, it had? | 14:59 |
| Delemas | A download-only option would be awesome for do-release-upgrade. | 14:59 |
| tomreyn | do-release-upgrade has some (fully qualified) domain names hardcoded, so you'd want to either use a local proxy, match those (modifying name resolution to point to local servers) or make sure your local domain names match what it expects to see (I'm not sure that's possible without also overriding the resolver). | 15:00 |
| JanC | ugh | 15:00 |
| ravage | i would hope that the tool honors the proxy env-var? | 15:00 |
| ravage | if not that for sure is worth a bug report | 15:01 |
| ravage | it has the -e option | 15:01 |
| tomreyn | i assume it does, haven't tired, but certainly someone has | 15:01 |
| JanC | also, I suppose do-release-upgrade wouldn't stop the firewall-VM until after it downloaded all files it needs? | 15:01 |
| ravage | dont think so | 15:01 |
| Delemas | Yes there was a simulation option for do-release-upgrade years back. I suspect it ran into issues as people trying to use different file systems for root fs. A squid transparent proxy is a option. | 15:01 |
| ravage | Delemas, to save more space maybe do an initial upgrade of any 20.04 to 22.04 before you run it on any of your offline nodes | 15:03 |
| ravage | eh..not space. bandwidth | 15:03 |
| ravage | can be a container or whatever | 15:03 |
| Delemas | If do-release-upgrade would pre-download before it started upgrading that would work too but I don't think it does. Yes a separate upgrade of an expendable VM could seed the transparent proxy then the LTE charges shouldn't be crazy. | 15:05 |
| JanC | it does download before it starts installing anything | 15:05 |
| ravage | i never feel comfortable stopping that process | 15:06 |
| JanC | it has to, because many scenarios exist where your internet connection could disappear while installing packages... | 15:06 |
| Delemas | Hmm I might get away with having Internet only until downloads complete then... | 15:06 |
| ravage | in theory it should restore everything if you cancel it before it starts installing | 15:07 |
| ravage | i would still just do a VM upgrade | 15:07 |
| ravage | also builing that proxy system will help you for future upgrades too | 15:08 |
| ravage | so in my opinion is worth spending the time to build it | 15:08 |
| Delemas | Transparent proxy with cache could help a lot of things... Not the simplest solution though. Hmm... | 15:13 |
| tomreyn | I'm also wondering why Ubuntu requeires the extra upgrader tool when Debian can still do it without. There probably are some reasons, and I just don't know them. | 15:19 |
| === Beret- is now known as Beret | ||
| === Bebef0 is now known as Bebef | ||
| === ravage_ is now known as ravage | ||
| === NightMonkey_ is now known as NightMonkey | ||
| === pizzaiolo is now known as pizza | ||
| JanC | tomreyn: it works almost as well with Ubuntu as with Debian | 16:11 |
| JanC | it mostly just automates things you do (semi-)manually in Debian, and tries to fix some common issues, but there are many use cases where it fails & then aptitude/synaptic/apt upgrade works better | 16:14 |
| alkisg | For example "remove slick-greeter if no package needs it after upgrade, because ubuntu-mate switched to arctica-greeter". In debian that would be "meh, can't do that, just leave slick-greeter installed | 16:18 |
| tomreyn | JanC: the word "mostly" is what i'd be worried about. would need to review the source code to understand what is actually done | 16:19 |
| JanC | the "mostly" is almost entirely because it's not tested as much | 16:19 |
| JanC | oh, no that's the "almost" I used :) | 16:20 |
| tomreyn | so you have reviewed the source code and what it does? | 16:20 |
| === jelly-home is now known as jelly | ||
| JanC | alkisg: you can just remove that "slick greeter" manually, of course (and maybe some people explicitly want to keep it, and then removing it will annoy them...) | 16:23 |
| alkisg | if you do know the 43 deprecated packages, sure | 16:25 |
| JanC | there is a good chance aptitude/synaptic will tell you those are no longer needed (depending on how they were installed/marked before) | 16:28 |
| JanC | or you could document it outside the code (bonus points if the code & the documentation use the same source) | 16:28 |
| tomreyn | jammy's demoted.cfg has 211 lines | 16:28 |
| tomreyn | 383 for demoted.cfg.focal | 16:29 |
| tomreyn | DistUpgradeQuirks.py has 1533 lines and was recently updated | 16:30 |
| JanC | one of the reasons I sometimes can't use do-release-upgrade is because it tries to remove stuff I still need... | 16:30 |
| alkisg | All the packages in seeds are marked as automatically installed, apt/synaptic won't tell you about them | 16:33 |
| JanC | that's where documentation would be useful indeed | 16:34 |
| JanC | although some of them would be removed/replaced because of dependencies, I suppose | 16:34 |
| alkisg | A do-release-upgrade tool is needed to overcome such limitations in the debian packaging system | 16:35 |
| alkisg | It's not a bad solution; debian should adopt it | 16:35 |
| tomreyn | i can see how you definitely need something like it at least for desktops, and how it would be at least nice to have for server upgrades. it would be lovely if it was easy to tell what changes are going to be applied for the upgrade from release x to release y. | 16:38 |
| tomreyn | ...(in advance, and make choices based on this). | 16:40 |
| JanC | do-release-upgrade breaks too easily when you have non-standard packages on your system, or when you don't use a default configuration | 16:40 |
| JanC | it's fine for most people who don't change too much from the default, I'm sure :) | 16:43 |
| JanC | maybe a way to do all the steps separately, manually, and with a supported way to override them would help :) | 16:57 |
| === Avago_Broadqual1 is now known as Avago_Broadqual | ||
| === lotuspsychje_ is now known as lotuspsychje | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!