It’s just changing configuration. Not sure if you work with Android much, but this is a common way to maintain this stuff.
Unlocking the bootloader is just to prevent people (or malicious code running on the machine your phone is connected to) from doing things to break the phone.
That’s how I do all the updates on my OnePlus 3. Works very well as long as you’re not rooted.
I’ve dabbled with the Android tools (adb and fastboot) over the years. That’s about it. Not super experienced with much else.
At this point I’m leaning towards convincing myself to just install LineageOS. There’s one on xda that looks to be almost bug-free. I was hoping it would be official by now, but it’s still not.
Flashing the security updates seems like a good idea, but are they device specific? I’m not sure where to go to find them.
Yeah, I looked and they don’t have official support. I’d go with the unofficial port if it’s got all the hardware working.
OnePlus releases them on the forum (really nice of them), but I’m not sure about Moto. 
Nope. Don’t use snapshots on my machine. It’s stable enough.
EDIT: whoops, confused snapper with snaps.
Yeah, I honestly had never heard of it until I was digging around RHEL documentation today. I’m gonna give it a try.
Go for it. It can’t be too bad.
Red Hat recommends using the ext4 file system with Snapper on Red Hat Enterprise Linux 7. Use the XFS file system on lvm-thin volumes only if you are monitoring the amount of free space in the pool to prevent out-of-space problems that can lead to a failure.
@SgtAwesomesauce you mentioned in a different thread that you use EXT4 (if I remember correctly). Do you know why it would be preferable over XFS when using thin LVM volumes?
Ext4 can be shrunk. Xfs cannot. That’s really my only reasoning.
Question about system snapshots:
Let’s say I have a system running on a single partition and I snapshot root:
lvcreate -s --name root_rollback vg1/root
And I decide that I want to roll the system back, maybe quite a bit later after multiple kernel updates:
lvconvert --merge vg1/root_rollback
reboot
Should I select the older kernel in GRUB after I reboot? Would a newer kernel possibly be incompatible with the system after rolling back?
This would only be between minor point releases… I just ran a test and it was fine with either kernels, but that doesn’t mean that would always be the case.
Best practice would be to select the old kernel, but if you’re not on UEFI, and don’t have a separate boot partition, the grub config will probably roll back to the state of the previous snapshot.
If you’re going 4.9.7 to 4.9.4, you’re good, if you’re going 4.9.x to 4.8.x, you’ll definitely want to use the old kernel.
If you’re on BTRFS, you can even encounter FS stability issues when rolling back minor releases of Linux. (I’ve had that problem when using the same btrfs array across Arch and Ubuntu.
So, I updated Solus about a week ago on my laptop… started the updates, walked away, when it was finished I turned off the laptop. Went to use the laptop for the first time since then and get tot he login screen and can’t type or move the cursor.
Timing for this is convenient: https://dev.solus-project.com/T4884
However, he says it was just a issue with his keyboard – and he was able to get to logs. I can’t do anything at all, much less get to logs.
Any ideas besides nuking it?
Solus Master Race
What is everyone with ZFS on linux using for automated snapshots?
I had it setup on one of my home servers for over a year, basically it makes and prunes snapshots on a schedule.
I’ve had a lightly corrupted btrfs system but a snapshot was readable and I used it to rsync the system onto a new drive and reinitialize the original one in much less time than it would’ve taken me to reinstall.
I don’t hate it, or love it. I believe it adds more cognitive load than it removes and therefore shouldn’t exist, let me explain:
You end up having config files with policies and a command line interface with flags, to use it, you need to know how snapshots normally work, and how to use snapper, and once in a while, how to clean up after it.
Without snapper, you end up having to know how snapshots normally work, how to use builtin snapshot commands, and that’s it.
On balance, snapper provides and abstraction that doesn’t decrease as much complexity as it introduces.
Having a command line utility that takes in a list of timestamps and outputs ones that should be kept or deleted would have been a more useful thing to provide than an entire snapshotting suite.
On my other home server where I use ZFS, I use it’s snapshotting capability to be able to take an atomic backup of the files, I don’t rely on it as backup byitself.
What I have is a shellscript that creates a snapshot and calls rsync to update the contents on the other machine and then runs rsnapshot on the other machine.
When your data is not changing underneath, such as on a readonly snapshot, rsync and rsnapshot work really well.
My test is on bios (VMWare), although I’d like whatever solution I come up with the be agnostic to BIOS vs (U)EFI if possible. Boot partition is currently 1GB on its own partition.
RHEL is deprecating BTRFS, so I’m stuck with MD/LVM for boot/OS drive in CentOS. This is an extension of my experiment with snapper, so I’m on EXT4, thin LVM. It’s unfortunate that there is a COW-sized hole in the RHEL family at the moment…
Yeah, that’s the impression I’ve gotten as well. I think I’ll use it because I personally like having the automated snapshots controlled through a config file, but you’re definitely right that the tools don’t cut much complexity off of just using (in my case) LVM.
I’m using snapshots to return a system to an earlier config (not for data recovery/history), and I was surprised that a system rollback tool wasn’t included in snapper. There is a rollback tool, but from what I can tell, it’s not for use with the OS partitions and only works with BTRFS anyway. I was able to use lvconvert --merge on the snapper-generated snapshots to roll back my system without issue, but if I have snapper, why am I still using lvconvert for a common task like that?
Concerning the kernel/snapshotting question, it looks like I’ll need to turn off installonly_limit in yum.conf and manually coordinate old kernel purging with system snapshots (if snapper was capable of doing that, then it would be much more useful). Might need to bump the /boot partition up from 1GB as well.
Can you try ctrl+alt+F1 to get to a TTY? If you can do that, try connecting to a wired network connection and try to upgrade again. sudo eopkg up
I’d give that a try, if you can’t get to a TTY, the easiest thing would be to boot a livecd, copy your files to an external and nuke.
In this case, you’ll definitely have to choose the old kernel.
Yeah, I guess that was inevitable because it seems like there’s been no major progress on BTRFS…
I’ve used this in the past, works just fine:
That was way too simple to install. Appreciate it not sure how i missed it in my searching.
Glad to help.
One advice: don’t go overboard and have it create a snapshot every 5 minutes if you have a dozen or more zfs filesystems. I did that once, and it slowed the system to a crawl when deleting files.
