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
Well, most users would simply want things to work without having to tinker, and for now, timeshift still uses cronie scripts, and those are what it sets up if you configure automatic backups from within the timeshift GUI. 
2 Likes
Yeah, I know I’m in the minority with that. But this kind of attitude has served me well for 38 years now, so I’ll stay in the minority.
1 Like
That command would have the same consequences on any distro.
Good luck. This is why you should have backups which are safe from such things ie mounted read only or not mounted at all.
If you had a separate home partition and had included --one-file-system in the command, then your data would be safe.
It’s not a symbolic link and there isn’t a “grub” partition. /boot contains important files (mostly generated though) and, should you be using UEFI, the mount point for the EFI partition (/boot/efi).
1 Like
Sad - and familiar story. I’ve done worse myself… I guess the game’s up, coz it’s an old post now.
I’d say have a go with freshly installed BTRFS goodness and an rsync backup off your main drive.
BTRFS stands for 'Better Fileystem For idiotS… just a reboot to restore your last snapshot… but then when you’re too stupid, and you can’t restore via snapshot, you still have all your main data ready for recovery the slow way.
1 Like
I have to ask…
Did that really work? I was under the assumption you HAVE TO INCLUDE --no-preserve-root for that command to work?
Are you saying this command went through without warnings??
--no-preserve-root
do not treat '/' specially
--preserve-root[=all]
do not remove '/' (default); with 'all', reject any
command line argument on a separate device from its parent
Or read posts #7 #8 #10 which discuss preserve-root.
1 Like