This is how just about every Linux distro works. Heck, even Windows blasts more away with updates, and you have even less options.
The older packages are in your /var/cache/pacman/pkg. And people sometimes install previous versions of packages from here as temporary solutions. You can increase the amount of versions you keep too.
Myself, and many others use btrfs snapshots. So you can one click restore your PC to previous point in time. Timeshift makes this very easy to do (if you are running btrfs).
I used to pixie boot whole networks with nfs home directories and the like. I still don’t understand what you want, is it grub, to do? And how this all ties together?
You overwrote what? And now you want to do what?
There are many ways to boot, and you don’t even have to use grub. And you can make it boot whatever you want. Linux is great that way.
You still have to boot into the OS to restore, and my problem was that I couldn’t since an update process got interrupted by pamac somehow(it crashed I guess).
What I want is simple, it’s to have as much chance as possible to boot my actual OS installation on my pc in case things go wrong for when I don’t have time to deal with problems. Not some other temporary OS that won’t have my installed apps.
For example, in this case, I needed to do something in a game within 30 mins when the issue happened, but it took me 4 hours(I did take things quite slow and did other stuff since I can dual boot into windows, meaning I could get my stuff done, but it would have taken more than that either way) to get the OS back running.
The goal would be to have a backup way to boot into manjaro quickly, run that game, do my thing and then I can do whatever needs to be done to fix things when I have the time to spare.
So in short, making a kernel copy and all its required files to boot that the OS can’t delete and add a custom entry for it in grub is the solution I got from this whole conversation.
I used to have one or more bootable backups for when I broke things at night and didn’t want to spend time fixing things right away (or if it took a while).
It makes more sense to me than trying to backup only part of the system (so many other things to go wrong).
If memory serves, just copy / to a new partition, edit the UUIDS in fstab (or switch to LABELs) and update grub (in both I think). Obviously it works better if home is separate.
However there’s also timeshift (and backup utilities).
With the (partial) update, system libraries and kernel modules may have changed, which then no longer match the old kernel.
The old initramdisk matches the old kernel, but are there perhaps already changes in the file system that are causing the crash? The modules for the new kernel might already be installed in the file system. With this “emergency boot,” you’re booting into an inconsistent system (with all the consequences).
The correct solution is Timeshift!
A btrfs-rollback restores the old kernel along with everything that belongs to it.
A btrfs-rollback takes only a few seconds.
I’m not sure what you mean by that, a whole system copy, if that is what you really mean, would be huge with a game library is my problem. I couldn’t separate my games onto another drive at this time.
And yeah, I’m aware it won’t always work, but it’ll work more often than right now.
I’d need to be using btrfs to make a btrfs rollback. This installation was meant to be temporary just to try it out so I went with what I knew, ext4, but it became permanent.
I’d probably look into zfs support for manjaro if I were to change, I’m already familiar with those snapshots for restoration from FreeBSD.
Sure it’s more complex than just that one file to check, but it’s not hard for a computer to check everything it depends on is correct before making the switch when updating and rollback if it detects a problem, it’s just more work for the programmer to make it happen and it’s not the fun part.
The delete and pray everything is fine until it gets fixed method is objectively bad.
My emergency boot idea should never be required if there were proper safeguards when updating important system files.
I still have to check what files are linked to the kernel booting to know if it’s viable to make a copy of everything required. Like I said a few times, it would be a copy of everything required to boot that kernel copy, so it should not be in an inconsistent state since that would only get updated very rarely and manually. Manjaro supports multiple kernel at the same time so I don’t see why that would be an issue.
Well, this is the current arch and manjaro concept. Simple and fast with tradeoff a bit of stability.
You can try another concept with an immutable distro
You don’t need a semi-immutable distro to have safeguards in your installation process.
Nothing would prevent the current manjaro with the way it works from implementing safety when updating packages, unless updating a few seconds faster per package is that important to people.
Only other priorities and motivation to do it would prevent it and I know I struggle a lot with that 2nd one when making software idiot proof, lol.
You can copy the kernel and the initramfs under a different name, but that kernel is going to be looking for driver modules which are no longer there, and copying the driver modules under a different name isn’t going to do you any good, because the specific versions and the path to the modules are hard-coded in the kernel.
The only sensible approach would be, as @Molski said, to make a btrfs snapshot before upgrading, and then if you have grub-btrfs installed, you can always boot into that snapshot.
It is only a btrfs snapshot — not a copy — of your @ subvolume. Your /home is not included, and neither are /var/log and /var/cache. And it takes only a few seconds to create, as well as a few seconds to restore your entire system to the state of the snapshot.
I mean a whole OS copy, not data. If you’ve chosen to lump everything together then you should consider changing to a better partitioning scheme at some point (when you have space to do so).
What I’m talking about are two / partitions which share a single /home partition (and any other data partitions you may have).
That way you can have two identical systems which share the data. So when the main one breaks you just use the other until you’ve fixed it.
As @Aragorn and others have said, something similar can be done with btrfs, it’s quicker and easier than doing it my way. But my way works with any filesystem.
For the odd time you need it. The rest of the time something else will break and you still need to resort to just using a live USB.
At most I’ve had that issue once or twice in ~17 years. The vast majority of the time it was something else, for which your plan won’t help.
Even if it’s applicable, and works, it only saves a few minutes. Just boot a live iso then using a chroot, install a kernel, finish the update and reboot.
How would you do that?
When the software that would fix things is already not working properly, and the system may have crashed completely.
Just use timeshift in rsync mode and keep a live USB handy.
Good to know there’s a way to boot into a snapshot directly from grub, that’s useful.
I’m assuming it works like zfs and it only saves the difference and not do a full copy of the system(excluding a few dirs).
I was afraid there might be hardcoded stuff.
So I guess compiling my own kernel would also create the modules and fix that issue, which is why you suggested I do that.
Like I explained, you don’t remove the old files until the end of the process, after you’ve verified all the new files are good and ready.
If it gets interrupted by a crash, blackout or whatever, the old files remain in place and intact.
There’s is still the possibility of the crash or whatever happening during the transition at the end, but that would significantly narrow the problematic window and it can be mitigated by detecting a problem(or just unmoved temporary files actually) during the boot process and complete the transition then, since the new files would still be in the temporary place before replacing the old ones.
That is correct. btrfs is a copy-on-write filesystem, and it was specifically developed for the Linux kernel by Oracle, who, after the takeover of Sun Microsystems, are now also the copyright holders of zfs.
In other words, btrfs was developed as a new filesystem with the same properties as zfs, but done somewhat differently, and licensed under GPLv2.
zfs is licensed under the CDDL (“Common Development and Distribution License”), which, although recognized by the Free Software Foundation as a valid Free Software license, is incompatible with the GNU GPL, and therefore zfs cannot be included in the Linux kernel by distributions. This is why zfs must be used as a driver running in userspace. Several distributions have sinned against that — most notably Ubuntu — but technically it’s illegal.
There are however differences between btrfs and zfs. For instance, RAID 5 and 6 are not considered production-ready in btrfs, and the question remains open as to whether they ever will be usable — there does not appear to be any motivation towards stabilizing that code — but RAID 0, 1 and 10 are perfectly usable.
Another difference — for instance — is that zfs subvolumes can be manipulated as block devices, whereas btrfs subvolumes are not block devices. In fact, they are more like bind-mounts.
Do however note that in order to boot into a btrfs snapshot, you need grub-btrfs instead of the regular grub package.
Indeed.
That’s not how pacman works. First it downloads the new packages, then it removes the kernel images and initcpios, then it replaces all the packages — including the kernel — with the new versions, and only then are the vmlinuz and initramfs recreated and is the boot loader updated to refer to these newly created images.
pacman is developed upstream, by Arch. pamac is a different package manager, but it does largely work like pacman itself, and it also uses libalpm and the pacman package database in the background.
There is a reason why pacman was designed to work this way. It’s all based upon a series of pacman hooks. The binary kernel and its loadable modules are separate entities, and everything needs to be updated first before the vmlinuz and initramfs can be regenerated — by mkinitcpio, and based upon the kernel preset.
After all, you’re not supposed to interrupt the update process.
I know, that’s why I’m saying the way it actually works is bad.
I don’t know the internal workings so I simplified how I think it should work, it’s obviously not that easy, but it is certainly possible to modify the process in a way that would make it safe from getting interrupted.
I don’t see why you wouldn’t be able to make all the changes in a sandbox type of environment, generate everything and then commit it to the system once everything is good for example.
If putting all that work and effort into achieving that is worth it or not, that’s an entirely different question and people can have a wildly different point of view depending on who you ask.
Yes, but we don’t live in a world with fairies and unicorns so things happen. I even have a UPS on that pc in case of power outages.
From what someone said in the update thread, I likely rebooted while pacmac was still doing its thing after pamac crashed and since I haven’t used manjaro daily for very long, there’s things I did not know.
Well, we didn’t develop the ALPM. As its name implies, it was developed by Arch, and if you look at the man page for pacman, you will find the email address to report bugs and feature requests to right at the bottom of the page.
My dear friend, it has been linked to 54 times and has received 20 likes. I don’t even remember how many times I’ve told people, and which people I’ve told.
I have only recently posted the link again somewhere, but given the high volume of traffic — I look at every new post — I thought I had already posted it to you.
You still need to move it all over - during which time you have the same issue with interruptions.
If you’d killed pamac and finished the update, making sure sudo mkinitcpio -P and sudo update-grub were run, before rebooting then you wouldn’t have had an issue.
Except it’s easy to see with a simple check that some files haven’t been moved during boot since they’re all located in a temporary place, which would be empty if all went according to plan and it can be finished then, which would eliminate the issue.
Even if that wasn’t possible, it would narrow the problematic window.
And with hash checks before deleting once the copy is over, you can eliminate corruption as well if it got interrupted in the middle of a file transfer.
If I had known pacman was still running in the background, I wouldn’t have rebooted. I assumed it would stop when pamac did and I even started pamac again to make sure the update went ok(wasn’t sure it was a crash or not), which it seemed to think it did.
It was a very easy situation to avoid… if you have the right knowledge, which I didn’t at the time and you can’t expect everyone to read everything about an OS before using it.
The fact essential files for booting are deleted in this way was a huge surprise to me and I wouldn’t have guessed it would ever act this way.
I’m savvy enough with computers that it wasn’t a big deal to fix, but less technical people can have a really bad time with this.
I have a friend that messed up his manjaro installation over a year ago after an update and he hasn’t managed to fix it still(it is fairly low priority though since he was dual booting with ubuntu, which is only half broken, lol).
And cause a lot of unnecessary reading and writing, which on an SSD is not a good idea, and especially not for people who’ve already used up almost all of their storage space.
Not pacman, but the pamac daemon — yes, it utilizes a daemon at the backend.
I hate to have to say it, but with Arch and Arch-derivative distributions like Manjaro, yes, you do have to put in the effort.
Manjaro is not a kitchen sink appliance the way some other distributions — like Ubuntu and derivatives — attempt to be. It’s aIso not a distribution aimed at refugees from the Windows world.
For that matter, GNU/Linux has never been about providing a safe haven for ex-Windows users or an alternative to Windows. It’s an alternative to proprietary UNIX. And Manjaro concretely — as well as Arch and other Arch-derivatives — is a distribution for people interested in GNU/Linux itself, and willing to learn and get their hands dirty. And needless to say, this comes with a certain requirement for responsibility.
Let me pour it into a metaphor. If you’ve been using Microsoft Windows, then you’ve been driving a 2-wheel-drive pickup truck with an automatic transmission. Using GNU/Linux on the other hand is like driving a medium-to-heavy-duty lorry with a 16-speed or 18-speed unsynchronized range-and-splitter transmission, and a driven tandem rear axle with three manually locking differentials.
Nobody’s telling you you’re not allowed to drive it, but you’ll still need to learn to do so first. You will not succeed if you don’t learn. And no, that doesn’t mean you have to become a mechanic or an engineer. But you do have to at least understand the machinery involved.
