Linux Mint Forums

I had Lm19,2 going fast and strong on my Lenovo dualbooting with Elementary OS.
Last night I decided to get rid of Elementary because LM is better for me, so I deleted the partition and messed around with grub, not knowing exactly what I was doing.
So I couldn’t boot into LM anymore, luckily I haven’t saved anything important, since I still am a newbie and still learning.

I tried to fix the bootloader(still not quite knowing what I was doing) to no avail from my old live-USB.
So I reinstalled LM 19,1 and did all the updates. Now I’m up and running again.

So I have a few questions because I couldn’t find answers for them.

1) Is it best to have different partitions for the Home-folder and Timeshift backups, and a swap-partition? Right now everything is on one partition.
1A) Can it be done after installing LM? Or should I do it while installing LM?

2) What order should those partitions be in?

3) Could I save the bootloader using grub? (If I knew what to do)

Swampthing wrote: ⤴Thu Sep 12, 2019 4:42 am 1) Is it best to have different partitions for the Home-folder and Timeshift backups, and a swap-partition? Right now everything is on one partition.

Opinions vary on this, but I advise only a separate partition for Timeshift snapshots. More than that is, in my eyes, a needless complication:
https://easylinuxtipsproject.blogspot.c ... 2.html#ID2
(item 2)

In any case: keep the number of retained Timeshift snapshots down. Practically nobody ever needs more than two snapshots. I advise to set a monthly schedule, with a retention of two.

Swampthing wrote: ⤴Thu Sep 12, 2019 4:42 am 1A) Can it be done after installing LM? Or should I do it while installing LM?

Can be done afterwards.

Swampthing wrote: ⤴Thu Sep 12, 2019 4:42 am 2) What order should those partitions be in?

Doesn't matter.

Swampthing wrote: ⤴Thu Sep 12, 2019 4:42 am 3) Could I save the bootloader using grub? (If I knew what to do)

Not quite, as a part of Grub also resides in the MBR of the hard disk.

1) Doesn't really make a difference. I'd keep it as you have it, that way you'll have less wasted space. Since it was mentioned above, I do not see any advantage to a separate partition for Timeshift snapshots. If you can put them on a different drive so if the drive fails you still have the snapshot, but different partition on the same drive has no advantage.

3) Yes. Easiest is using the LM 19.2 installation medium/live environment and running Boot Repair from the menu, it'll figure it out for you.

Thanks for the fast reply!
I'll look into saving important stuff on external devices.

gm10 wrote: ⤴Thu Sep 12, 2019 4:49 am... but different partition on the same drive has no advantage.

Not necessary is fair, assuming Timeshift is configured correctly and the destination partition has enough room. Particularly unnecessary if using manual snapshots, as can see before running how much space remains. OTOH, separate partition has the simple advantage, especially with automatic snapshots, that if it gets overrun (usually due to operator error) all it takes down is Timeshift, leaving the rest of the system free to function as normal.

Mind, I've not been recommending separate partition (even though I use one, mainly out of curiosity). Generally I recommend root-only or sending snapshots to home if separate. Some users, though, want certainty Timeshift won't mess up their system and will disable it if they can't be certain. In that case, separate partition is easy to do, relatively painless (assuming there's enough room) and pretty much foolproof.

pbear wrote: ⤴Thu Sep 12, 2019 12:34 pm OTOH, separate partition has the simple advantage, especially with automatic snapshots, that if it gets overrun (usually due to operator error) all it takes down is Timeshift, leaving the rest of the system free to function as normal.

Fair enough, I concede that point.

It's actually a major annoyance that Timeshift does not check free space on the target device before creating a snapshot. For the Timeshift integration into my Update Manager fork I had considered doing the free space check in mintupdate myself but I decided against it because this is really somehing that must be fixed in Timeshift itself, I cannot be bothered to parse Timeshift's configuration, at that point I'd better fork Timeshift itself (but I didn't want to do that, either).

Frankly, what's the deal with Timeshift using "partitions" in the first place? Why would it not allow me to save snapshots to e.g. a NAS? Thing's as far as I'm concerned quite useless due to that...

gm10 wrote: ⤴Thu Sep 12, 2019 12:52 pmIt's actually a major annoyance that Timeshift does not check free space on the target device before creating a snapshot.

Agreed, that's either a bug or a very bad design decision.

pbear wrote: ⤴Thu Sep 12, 2019 10:49 pm

gm10 wrote: ⤴Thu Sep 12, 2019 12:52 pmIt's actually a major annoyance that Timeshift does not check free space on the target device before creating a snapshot.

Agreed, that's either a bug or a very bad design decision.

Well, putting myself in the developer perspective thinking about how I'd fix it, on the first snapshot it's fairly easy because you know that all files will be written as they are. In fact there is a limited check in Timeshift but only when you first select the snapshot partition, not when you are actually doing the first snapshot. That must get fixed.

On subsequent snapshots, however, you do not even know how much data will be written until rsync has run through, so you'd have to do a --dry-run first to find that out, then check free space, then run rsync again for real. That would significantly slow the whole process down.

So from a design perspective I could actually accept not checking beforehand for performance reasons (I'd still do a nominal check for a hardcoded minimum free space amount like 1 GB or so). But what I cannot accept is not checking afterwards. Timeshift does roll back snapshots when you kill the rsync process while the snapshot is being created, but it does not roll them back if rsync fails, and that's clearly broken behaviour.

In addition you should probably perform a free space check even if the snapshot succeeded and warn the user if only very little space remains.

And to top this off, timeshift does not even return error codes, it always returns an ok status even when it completely failed. In my mintupdate I have to parse Timeshift's output to decide whether the snapshot was created properly, which is ridiculous.

So yes Timeshift's dev still has a few things left to do. Not sure how motivated he is though.

Interesting insights, thanks.