So you can go to Zorin menu > Settings > Background and set whatever background image you want... but what if you want no background image?
dconf Editor to the rescue!
flatpak install flathub ca.desrt.dconf-editor
flatpak run ca.desrt.dconf-editor
Open dconf Editor, navigate to /org/gnome/desktop/background/picture-uri
Disable the "Use default value" slider, then delete the Custom Value entry. Now your desktop is black (#000000), no image. Click the 'Apply' button.
Now you can change it to whatever color you want.
Within dconf Editor, navigate to /org/gnome/desktop/background/primary-color, disable the "Use default value" slider, then set whatever color you want and press the "Apply" button, in the format:
#RRGGBB
... where:
RR is the intensity of red, from 00 (minimum) to FF (maximum)
GG is the intensity of green, from 00 (minimum) to FF (maximum)
BB is the intensity of blue, from 00 (minimum) to FF (maximum)
So it goes:
00
01
02
03
04
05
06
07
08
09
0A
0B
0C
0D
0E
0F
10
11
12
... etc., etc. up to FF for each of red, green and blue.
So obviously black would be #000000, full-intensity red would be #FF0000, full-intensity green would be #00FF00, full-intensity blue would be #0000FF and full-intensity white would be #FFFFFF.
I've set mine to #000000.
1 Like
No, I don't know a lot, I'm just willing to break things to learn how they work.
That's because I've got the ability to restore back to the settings that I know work... either via the ZFS snapshots, or failing that, via the .img file of the drive I take before embarking on any changes.
And the ZFS snapshots aren't a rock-solid fallback... I installed dracut once just to see what it did... the machine locked up when booting (dracut doesn't recognize ZFS drives), so I rebooted, rolled back to a prior snapshot... and dracut was still there! It'd hijacked the machine to such an extent that no rollback would get rid of it. So I had to clone the backup .img file back to the internal drive.
With a 1 TB internal drive, keeping a lot of 1TB .IMG files around doesn't make much sense, so I compress them with .7z... the more zero'd sectors your drive has between the files, the more you can get it compressed. I've compressed that 1 TB image down to 5.4 GB before. So now I'm casting about trying to find or build a utility which will zero the free space on the drive... which isn't easy... ZFS compression tosses any zero-file (no matter how big it is) and just records an index (ie: a 'sparse file')... there's reports of people saving multi-TB zero files to ZFS drives of only GB capacity.
So we need something with a low enough access that it can fly under the radar of ZFS, but high enough that it'll recognize file-allocated sectors... dd isn't it, it'll fly under the radar of ZFS, but it's so low that it doesn't recognize file-allocated sectors.
1 Like
I have an idea... not sure if it'd work, though.
Record all the starting and ending sectors of all the files on the drive, then use dd to write zeros between those files to zero the empty space... this would be a two-tiered approach, using ZFS to record the starting and ending sectors of all the files on the drive, then creating a 'map' of where dd can safely write to without overwriting files.
Of course, you'd have to trigger an update to that 'map' with every drive write, so while this would work on a live system (booted into Zorin OS), it'd be slow... every time a file is written, that 'map' would have to be updated and thus the commands for dd updated.
dd is low enough access that it doesn't care what's on the drive, thus it'll fly below the radar of ZFS. You can zero your entire drive (you will, of course, lose all your data) with:
sudo dd if=/dev/zero of=/dev/sda bs=512 status=progress
... but you can also set it to only start writing those zeros at a certain point, and stop at a certain point. You could also use blkdiscard -z.
If you use dd to write those zeros to a file, though, ZFS will toss that file and record it as a 'sparse file'... the zeros won't be written. So we have to write directly to the device as above, just limiting where dd can write.
Or, more simply, every time there's a write, it triggers this code to overwrite the old location of the file with zeros (because ZFS is a COW (copy-on-write) file system... every time a file is written, it's written to a new place)... eventually all the free space would be zero'd, and your compressed .IMG backup files would be small.
Good on you for taking GNU/Linux to the next level. Most folks like me just want a simple life with Ext4 File System! 
Here's an image file I created from the Zorin 'Z', it's 1600x900 pixels, 41484 bytes, to be used as a desktop background image:
Background images are stored in /usr/share/backgrounds.
Download the image to your desktop, then open sudo Nautilus and drag-n-drop the image from your desktop to the usr/share/backgrounds directory.
Then Zorin menu > Settings > Background > Add Picture, navigate to and select that image.
I wiped all the drives again and I'm working through how to manually partition the main drive for ZFS and have the partition sizes stick when installing Zorin OS. In doing so, I figured out how to 'hole punch' (ie: write zeros to free space) the ZFS-owned drives from within ZFS. It works even when you're up and running, not just when booted on the Zorin OS USB stick. That not only makes the 7z-compressed .IMG file backups smaller, it allows the built-in ZFS compression to compress better.
set zfs:zfs_initialize_value=0
sudo zpool initialize bpool
sudo zpool initialize rpool
This changes zpool initialize to write '0' rather than '0xdeadbeefdeadbeef' to all unassigned sectors, then zeros all free space on the selected pools.
Monitor it via:
sudo zpool iostat -v 15
... and wait for all pools to register zero write bandwidth.
I don't know what Moderators think, but IMO this is becoming more of a Blog than a "[How to]... Tutorial.
Maybe this thread would be better located under Chat about Zorin?
Just a thought, Zab.
1 Like
