You can make the image then mount and interact with that. (no extra hardware required)
The Archwiki goes over this:
https://wiki.archlinux.org/title/File_recovery#Working_with_raw_disk_images
It only treats / specially, to protect against mistakes like rm -rf / tmp/junk.
If you used /* then the shell expands that to /bin /boot ... before executing rm with those arguments, and rm -rf /bin or anything else that isn’t / is not treated specially.
2 Likes
If you have a separate home partition, reinstalling should fix the problem.
You have to be more precise what exactly is missing. Only /etc? /boot? If everything important is still there, ie. /home, then I don’t see any point in doing any kind of recovery.
First you can try, booted in iso, reinstalling every package with: [Later note: Actually you would need to do some cleaning to only have last version of each package, eh]
pacman -r /mnt -U /mnt/var/cache/pacman/pkg/* # where you mount root to /mnt
I’m presuming here that you have all packages cached. Or you can do it by some other means. Also maybe a good idea would be to start with filesystem package.
After that you can try chrooting and running mkinitcpio and update-grub, or just reinstall kernels again.
Either way, in the end you can just reinstall everything and keep your home.
Valid point.
Moving or backing up your /home directory/partition could save you from having to perform a long and tedious recovery operation.
You could then simply start from scratch, and restore your profile(s) later.
Boot a live media - preferably the same edition - mount your root partition on the temporary /mnt mountpoint e.g. sdy is an example - you will need to adjust for your system
sudo mount /dev/sdy2 /mnt
If your system is EFI then mount the efi partition
sudo mount /dev/sdy1 /mnt/boot/efi
In the topic [root tip] [How To] Do a manual Manjaro installation follow the instructions to reinstall the list of packages which made up the initial installation.
There may be other steps needed but that should get you started.
You got to love this quote
Unix was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things.
— Doug Gwyn
1 Like
Same principle applies though.
No separate home partition, unfortunately.
I’m not quite sure I understand. `/bin/, /boot/, /dev/, /etc/ and part of /home/ is completely bulldozed, so I cannot boot. Even if I did, bash is obliterated, so mount wouldn’t work.
I wish I was knowledgeable enough about Linux to select that option back then. Maybe next time I should know more about Linux before switching from using Raspbian occasionally to daily driving a “distro for intermediate users”. Oh well, actions have consequences.
Once we recover the missing files from /home/, that would be great, although my personal preference is not to reinstall, but if it comes to it, I don’t have a problem.
Glanced over the link, looks fine to me. Will do that to the ISO backup I made of the drive. (just going to mention @cscs because I haven’t previously stated that I made it.)
That got a chuckle out of me. I think I read somewhere about somebody in the programming community talking about the best and worst things of CLIs.
The best thing is they do exactly what you say, and the worst part is they do exactly what you say.
Could you (or anyone else) elaborate? Not quite sure what you mean, because I don’t think I need to mount /boot/ because it’s an MBR system. Furthermore, as previously stated, /boot/ is demolished, henceforth I cannot mount it.
Thanks for helping, everyone. Great community here in the forums, I must say.
The same principle applies, even though you’re not using a UEFI based system: Translated to an mbr system; rather than mounting the efi partition as @linux-aarhus suggested, the same methodology could be used to mount the partition on which Grub resides.
There was a time when /boot might have been symlinked to a separate boot partition, but this hasn’t been a default configuration for many years. If /boot is still intact, using the example used previously, the command to mount the partition would be:
sudo mount /dev/sdy1 /mnt/boot
(instead of this command to mount an efi partition):
sudo mount /dev/sdy1 /mnt/boot/efi
as indicated previously.
To follow his suggestion, mounting a partition (whether an efi partition, or not) would still have been part of the process.
With that additional information; /boot being demolished; that makes this approach somewhat irrelevant.
Aside:- Is your system UEFI-capable? If so, this could also be an opportunity to switch to using it. (a potentially positive spin) 
OOOH. I forgot that /boot/ is really just a symbolic link to the GRUB partition. My bad. Thank you.
Point being, you might have yet been able to recover via chroot. Alas, no longer.
It is, as a matter of fact. I’ve stated before in a previous topic that
The wording is a bit weird, but essentially when I tried to switch to UEFI using the Manjaro wiki guide (UEFI - Install Guide - Manjaro), in the BIOS only Windows Boot Manager (i had windows 10 installed previously) and network boot would show up in the UEFI boot sequence selector.
OT but it’s still pretty funny… just realized I made this post 4 days after the 1 year anniversary of when I first installed Manjaro.
Yes, you would have needed to change the boot order in BIOS, most likely.
It’s usually best to install each OS separately, at first (on separate disks), so that one doesn’t interfere with the other.
Then when both are ready, reconnect them both, confidently knowing that boot selection is the only thing to change.
Happy anniversary then. Cheers. 
5 Likes
I’d rather suggest a systemd timer. They are much easier to understand…
Could you repeat that, as if I’m fi… OK, nevermind…
1 Like
Okay, imagine you have a special helper who reminds you to do important things like homework or brushing your teeth. In the computer world, we have similar helpers to do tasks at specific times.
Cron jobs and systemd timers are like two different types of these helpers. Cron jobs are like an old, reliable friend who has been helping for a long time. They are good at reminding you about tasks at certain times, but they can sometimes be a bit tricky to set up and manage.
On the other hand, systemd timers are like a new, smart friend who can also remind you about tasks at specific times, but they come with some extra features and are easier to work with. They are designed to be more flexible and provide more information about the tasks they are doing.
So, using systemd timers is like having a new, improved reminder system that can do the same job as the old one but with some extra benefits. It’s like upgrading your reminder helper to make your computer tasks easier and more efficient.
With timeshift you don’t need to bother setting up cron tabs or systemd timers. You only need to have cronie running. You then simply tell timeshift — via its GUI — to make periodic backups, and how often.
Note: By default, timeshift does not back up the home directories, but you can tell it to.
2 Likes
That’s true. Because it uses it’s own cronjobs. And that’s why I converted everything to systemd timers for me. Because I didn’t want another daemon that does the same thing than an already running daemon is doing. And doing well.
1 Like