mult-boot setup with Tumbleweed, LM, and Win on UEFI

Greeting, Gurus:

I am new. I’ll do research, but since I need to hurry and openSUSE is new to me, tips from any of you may help me a lot. :wink:

I have a new laptop: ~1 TB drive SSD (probably GPT) and UEFI

I need to create a multi-boot including openSUSE. OS & data Partitions:

  1. The pre-installed Windoze left in its now shrunk partition (already done) – because some employers, clients, or instructors may need me to use video chat that only runs in Windoze (sigh)
  2. Linux Mint 20 (possibly needed sometimes, at least if openSUSE Tumbleweed ever stops booting)
  3. openSUSE Tumbleweed: an eternally self-updating host OS for virtual machines and possibly my replacement of modern LM versions
  4. a data partition (most of the SSD size) sharable with both Linux partitions and sharable folders for virtual machines, and also the virtual machines stored in this partition

First questions in my mind:

  • (A) Maybe ~100 GB partition sufficient for openSUSE installation to be big enough forever? (most data incl. virtual machines placed on the data partition)
  • (B) ext4 being the best format for openSUSE as well?
  • (C) / and /home easily installed together on that single partition? (anything else needed?)
  • (D) How to handle GRUB during booting with openSUSE? (maybe first install Linux Mint and THEN openSUSE because the last used installer (as in the case of LM installer) may set the default pick of OS?) – (or perhaps I must use rEFInd instead?)

Thanks a lot for any tips! :slight_smile:

openSUSE Tumbleweed “self-updating”? That’s not a classification I’d ever ascribe to it.

Secondary Linux operating systems can be installed sans bootloader so that the original won’t be disturbed. Various ways can force it to not disturb NVRAM when installers don’t specifically allow to specify a bootloader not be installed or set up:

  • not including the ESP partition in fstab
  • including the ESP in fstab, but not mounting it to /boot/esp/
  • including the ESP in fstab with a noauto option
  • excluding efibootmgr from the installation

None of my TW installations live on filesystems larger than 8G. All use EXTx. All are on multiboot PCs. I still have several on 5600M or less. Absent use of BTRFS with snapshotting instead of EXT4, I can’t imagine filling a / filesystem anywhere near 100G when used with a separate /home filesystem and VMs housed elsewhere too. Including /home as part of the / filesystem makes suggestion of any particular size an exercise in futility.

If rEFInd floats your boat, use it. I tried it on a Mac. The first time it failed, which didn’t take too long, I abandoned it. Grub works well enough for me.

Custom UEFI multiboot may be overkill for only 3 OSes, but probably worth making part of your research.

Multiboot is easy as can be. I squeezed the Windows partition and added a single btrfs partition for Tumbleweed (ext4 lacks some features of btrfs): https://forums.opensuse.org/showthread.php/574148-Lenovo-Thinkbook-Windows-11-Tumbleweed-dual-boot?p=3153077#post3153077

You may want to have a rescue system on the nvme drive. But I prefer another instance of Tumbleweed on btrfs. All my machines are multiboot with the installed systems using their own grub: https://forums.opensuse.org/entry.php/244-Tumbleweed-Partitioning-Grub-Multiboot

KeepItSimple: Everything fits on the back of an envelope with ample provisioning for additions.

Thank you both for two responses. I admit to still be groping a bit in the dark.

A skim over the pages of the link https://forums.opensuse.org/showthread.php/533087-How-to-have-a-custom-UEFI-grub-menu-for-a-multiboot-system given to me here seems to hint at me that the openSUSE installer will act with the UEFI and GRUB2 like the Linux Mint installers. This then probably answers my (D) question if openSUSE installation will make openSUSE the default boot (but hopefully leave the other OSs also bootable from the GRUB2 menu) with a yes. Correct?

For those who wonder why I mentioned rEFInd, the GRUB2 menu disappeared after bringing in a second drive on which I installed a newer LM 99version on my now dying old laptop. I could not bring the GRUB2 menu back. Only rEFInd worked there (while rEFInd on another laptop got hit with “secure boot” blue screens DESPITE having “secure boot” turned off). — This reminds me that I should probably ask if “secure boot” still needs to be turned off for Linux boot adding if I install openSUSE (on LM it may still be a little unclear if that’s still necessary).

BTW, recent LM versions of live Linux systems (often referred to by me as “installers”) come with a “Boot Repair” tool that can often fix the GRUB menu (although it did not in the GRUB2 menu disappearing case just mentioned).

In LM multi-boot installations I also ran into a little oddness of (when having 2 drives anyway) of me having to hint at the ESP partition not with the exact sdb1 reference but only a sdb reference.

Haha. In 2014 it was super easy for me, too (on MBR & BIOS & GRUB systems rather than the GPT & UEFI & GRUB2 systems we now have), but since then I and others have run into super struggles. You can read one here: forums.linuxmint.com/viewtopic.php?p=196798099

My past trouble reminders by now make me think I should probably ask:
Well, back in 2014 I set up / and /home separately for LM 17 and each at 20GB. / didn’t get filled over 66% while /home sometimes ran out of space (not EVERY data shifted by me from there). Last year or so, I got recommended something like 100GB for a / & /home combined partition for LM 20, LM 20 having become much bigger than LM 17 (also much less nice, sigh). So, I want to avoid future troubles of space when openSUSE surely also grows bigger over the years. As for splitting / and /home into separate partitions, that seemed smart for OS repairs back in 2014 to me, but since then has only given me extra partitions (annoyingly many on multi-boot setups), including waste of space, and now that I want to try and turn my highly modified and idealized LM 17 into a virtual machine, the split may be a problem.

Me unsure what that means.

> … btrfs …

I must admit that btrfs is totally new to me (and SOMEWHERE I had read that sticking with ext4 were better).
99

My past trouble reminders by now make me think I should probably ask: Where is an existing good detailed instruction and/or video of openSUSE installation steps?

I couldn’t get Google to cough up anything that looked related from your non-clickable pseudo-URI.

Your indecision about sizes makes you a classic candidate for LVM or BTRFS use. LVM was created in part to enable resizing live filesystems, and shrinking them, and growing them onto additional partitions and/or media. BTRFS also has these capabilities.

Hmm… Sorry… It worked earlier, now not on my end either… Odd… This should be correct: https://forums.linuxmint.com/viewtopic.php?f=90&t=342159 (if it fails, you can search for the thread title “How to multi-boot via multiple drives on UEFI?” on forums.linuxmint.com)

Well, to be honest I’d prefer to keep it simple and as safe as possible (not sure if LVM or btrfs would stay simple and safe; never worked with them before and btrfs is totally new to me). Should the data partition get overfilled, I could still have some usable storage space in the /home folder which – if kept in the / partition rather than being a separate partition – there won’t be eternally unused space on the / partition wasting drive space. And since in all the years I never had to re-install the / partition, having /home in it appears safe enough for me by now.

I remember in good old times having been told by OS installer manuals or such how much space the OSs would minimally and ideally need. No info about this found for openSUSE (nor LM). My latest LM 20 installation that I used occasionally all this year filled only 42 GB by now despite so far me having saved all there used data in the /home folder placed within that single / partition, so the LM 20 OS + the /home folder with some data added only filled 42 GB. openSUSE may perhaps be no bigger, but over many years to come openSUSE Tumblweed will probably grow in size. So… can someone guess better than I what would likely be a safe size?

I am new. I’ll do research, but** since I need to hurry and openSUSE is new to me,** tips from any of you may help me a lot.

I missed the above. As you need to hurry, I suggest to forget everything you bothered with in posts #4 and #6.

Thanks for this Read Installation link! :slight_smile:

It gave some size info:

10 GB available disk space for a minimal installation, 16 GB for a graphical desktop (more is recommended). In case you plan to use Btrfs snapshots a minimum of 40 GB for the root partition is recommended.

Other than that, it gave too little, but its link to https://doc.opensuse.org/documentation/leap/startup/html/book-startup/cha-install.html gave more info, also mentioning again:

If you plan to keep snapshots activated for a system upgrade (to be able to roll back), you should consider 40 GB or more.

But… Does this refer to a partition of only / or of / AND /home?

The following quote seems to hint that the installation partition is considered as both / AND /home as the default installation, BUT not being really clear if any kind of roll-back will normally work trustworthy then if an update of openSUSE TUMBLEWEED shoud ever break it:

The default proposal no longer suggests to create a separate partition for /home. The /home directory contains the user’s data and personal configuration files. Placing it on a separate directory makes it easier to rebuild the system in the future, or allows to share it with different Linux installations on the same machine.

So, 40 GB is considered sufficient for / (the root) AND /home AND snapshots all in one partition? (still unknown to me how to use these snapshots, btw)

[HR][/HR]
BTW, I worry about LVM creation to make data recoveries impossible (or too tough?) if booting from this drive ever stops working. ALSO another Linux OS on this multi-boot drive could possibly not have access to the data partition then, but I want it to be accessible by both Linux OSs.

[HR][/HR]

More:

If you plan to suspend your machine, make sure to create a separate swap partition and check Enlarge to RAM Size for Suspend.

Uhm, doesn’t openSUSE use a swap file in / (the file system) by now by default (rather than a swap partition) like Linux Mint now does? (I recall reading that a swap partiton gives danger now… uhm… uhhh… something to do with suspension or hibernation… hibernation described as very bad for SSD drives btw)

More:

If the root file system format is Btrfs, you can also enable or disable Btrfs snapshots here.

Huh? What to do?

More:

hardware clock to UTC…

This confuses me.

[HR][/HR]
Unfortunately these pages always talk of “openSUSE Leap”, never is Tumbleweed mentioned. A problem when I want to install Tumbleweed?

[HR][/HR]

Total confusion given:

3.11.5 Default systemd target

openSUSE Leap can boot into two different targets (formerly known as “runlevels”). The graphical target starts a display manager, whereas the multi-user target starts the command line interface.

The default target is graphical. In case you have not installed the X Window System patterns, you need to change it to multi-user. If the system should be accessible via VNC, you need to choose graphical.

What on Earth does this say?

When using a single btrfs partition required size is

  • size of operating system +
  • size of your data +
  • available space.

Operation without available (unallocated) space ist PITA. This is obvious, but to my experience some users don’t get it.

erlangen:~ # btrfs filesystem usage -T /
Overall:
    Device size:                 476.84GiB
    Device allocated:            175.04GiB
    Device unallocated:          301.80GiB
    Device missing:                  0.00B
    Device slack:                    0.00B
    Used:                        149.83GiB
    Free (estimated):            324.61GiB      (min: 324.61GiB)
    Free (statfs, df):           324.61GiB
    Data ratio:                       1.00
    Metadata ratio:                   1.00
    Global reserve:              287.77MiB      (used: 0.00B)
    Multiple profiles:                  no

                  Data      Metadata System                              
Id Path           single    single   single   Unallocated Total     Slack
-- -------------- --------- -------- -------- ----------- --------- -----
 1 /dev/nvme0n1p2 171.01GiB  4.00GiB 32.00MiB   301.80GiB 476.84GiB     -
-- -------------- --------- -------- -------- ----------- --------- -----
   Total          171.01GiB  4.00GiB 32.00MiB   301.80GiB 476.84GiB 0.00B
   Used           148.20GiB  1.63GiB 48.00KiB                            
erlangen:~ # 

Bulk of system is /usr

erlangen:~ # du -hd0 /usr/
11G     /usr/
erlangen:~ # 

The following quote seems to hint that the installation partition is considered as both / AND /home as the default installation …

They finally got it.

BUT not being really clear if any kind of roll-back will normally work trustworthy then if an update of openSUSE TUMBLEWEED should ever break it: So, 40 GB is considered sufficient for / (the root) AND /home AND snapshots all in one partition? (still unknown to me how to use these snapshots, btw)

Nope, see above. Snapshots are great for rollback and backup.

BTW, I worry about LVM creation to make data recoveries impossible (or too tough?) if booting from this drive ever stops working. ALSO another Linux OS on this multi-boot drive could possibly not have access to the data partition then, but I want it to be accessible by both Linux OSs.

Forget lvm. The Linux kernel comes with btrfs. Thus any distribution will have access to btrfs partitions.

Uhm, doesn’t openSUSE use a swap file in / (the file system) by now by default (rather than a swap partition) like Linux Mint now does? (I recall reading that a swap partiton gives danger now… uhm… uhhh… something to do with suspension or hibernation… hibernation described as very bad for SSD drives btw)

All my machines are doing fine without swap since several years.

erlangen:~ # free -h
               total        used        free      shared  buff/cache   available
Mem:            29Gi       5.6Gi        11Gi        92Mi        12Gi        23Gi
Swap:             0B          0B          0B
erlangen:~ # 

If the root file system format is Btrfs, you can also enable or disable Btrfs snapshots here.

If you want to rollback enable snapshots.

erlangen:~ # snapper list
    # | Type   | Pre # | Date                     | User | Used Space | Cleanup | Description            | Userdata     
------+--------+-------+--------------------------+------+------------+---------+------------------------+--------------
   0  | single |       |                          | root |            |         | current                |              
1777* | single |       | Mon Jan  3 09:13:10 2022 | root |  17.80 MiB |         | writable copy of #1774 |              
2138  | pre    |       | Sun Oct 30 21:20:14 2022 | root |   1.05 GiB | number  | zypp(zypper)           | important=yes
2139  | post   |  2138 | Sun Oct 30 21:21:10 2022 | root | 333.70 MiB | number  |                        | important=yes
2152  | pre    |       | Thu Nov  3 23:32:00 2022 | root | 301.78 MiB | number  | zypp(zypper)           | important=yes
2153  | post   |  2152 | Thu Nov  3 23:32:55 2022 | root |   3.14 MiB | number  |                        | important=yes
2154  | pre    |       | Thu Nov  3 23:38:10 2022 | root |   1.44 MiB | number  | zypp(zypper)           | important=yes
2155  | post   |  2154 | Thu Nov  3 23:38:14 2022 | root |   1.91 MiB | number  |                        | important=yes
2156  | pre    |       | Fri Nov  4 08:53:39 2022 | root |   2.03 MiB | number  | zypp(zypper)           | important=no 
2157  | post   |  2156 | Fri Nov  4 08:53:48 2022 | root |   1.53 MiB | number  |                        | important=no 
2158  | pre    |       | Fri Nov  4 17:52:11 2022 | root |   2.05 MiB | number  | zypp(zypper)           | important=no 
2159  | post   |  2158 | Fri Nov  4 17:52:48 2022 | root |   5.52 MiB | number  |                        | important=no 
2160  | pre    |       | Sat Nov  5 12:29:48 2022 | root |   6.27 MiB | number  | zypp(zypper)           | important=no 
2161  | post   |  2160 | Sat Nov  5 12:29:56 2022 | root |   3.42 MiB | number  |                        | important=no 
2162  | pre    |       | Sat Nov  5 21:01:25 2022 | root |   1.86 MiB | number  | yast users             |              
2163  | post   |  2162 | Sat Nov  5 21:07:48 2022 | root | 416.00 KiB | number  |                        |              
2164  | pre    |       | Sat Nov  5 21:43:48 2022 | root | 608.00 KiB | number  | zypp(zypper)           | important=no 
2165  | post   |  2164 | Sat Nov  5 21:45:53 2022 | root |   7.83 MiB | number  |                        | important=no 
2166  | pre    |       | Sun Nov  6 07:48:51 2022 | root |   1.70 MiB | number  | zypp(zypper)           | important=no 
2167  | post   |  2166 | Sun Nov  6 07:49:01 2022 | root |   1.58 MiB | number  |                        | important=no 
2168  | pre    |       | Sun Nov  6 16:48:22 2022 | root |   4.27 MiB | number  | zypp(zypper)           | important=no 
2169  | post   |  2168 | Sun Nov  6 16:48:49 2022 | root |   6.27 MiB | number  |                        | important=no 
2170  | pre    |       | Mon Nov  7 09:19:01 2022 | root |   2.48 MiB | number  | zypp(zypper)           | important=no 
2171  | post   |  2170 | Mon Nov  7 09:19:09 2022 | root | 416.00 KiB | number  |                        | important=no 
2172  | pre    |       | Mon Nov  7 14:53:55 2022 | root | 400.00 KiB | number  | zypp(zypper)           | important=yes
2173  | post   |  2172 | Mon Nov  7 14:55:21 2022 | root |   1.95 MiB | number  |                        | important=yes
2174  | pre    |       | Mon Nov  7 17:09:15 2022 | root |   1.33 MiB | number  | zypp(zypper)           | important=yes
2175  | post   |  2174 | Mon Nov  7 17:09:20 2022 | root |   2.14 MiB | number  |                        | important=yes
2176  | pre    |       | Tue Nov  8 19:55:48 2022 | root |  13.75 MiB | number  | zypp(zypper)           | important=no 
2177  | post   |  2176 | Tue Nov  8 19:56:03 2022 | root |   7.61 MiB | number  |                        | important=no 
erlangen:~ # 

Unfortunately these pages always talk of “openSUSE Leap”, never is Tumbleweed mentioned. A problem when I want to install Tumbleweed?

Nope: https://forums.opensuse.org/entry.php/247-Install-Leap-Tumbleweed-from-USB-Stick-On-Internal-Disk

More: hardware clock to UTC… This confuses me.

Use these settings:

erlangen:~ # timedatectl 
               Local time: Wed 2022-11-09 08:33:57 CET
           Universal time: Wed 2022-11-09 07:33:57 UTC
                 RTC time: Wed 2022-11-09 07:33:57
                Time zone: Europe/Berlin (CET, +0100)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no
erlangen:~ # 

Total confusion given:
3.11.5 Default systemd target
openSUSE Leap can boot into two different targets (formerly known as “runlevels”). The graphical target starts a display manager, whereas the multi-user target starts the command line interface.
The default target is graphical. In case you have not installed the X Window System patterns, you need to change it to multi-user. If the system should be accessible via VNC, you need to choose graphical.
What on Earth does this say?

Shorter version: No graphics, no VNC,

If you don’t have enough memory to run what you want to run you do need some swap. Also if you use or want hibernate you need swap to store the memory image.

If you run out of memory without swap it means a system crash will happen.

So amount of memory and how you use your system determines if you need swap.

Once again, my thought is to install both the file system (/) AND the file-system-associated data container (/home) in one single partition (in order to keep the number of partitions on a multi-boot drive reasonably small — unless an openSUSE guru points out a need for splitting / and /home into different partitions (even though this wastes space in the form of giving plenty of space in BOTH partitions in case one of them will fill up a lot). In other words, installing openSUSE only in one single partition (BTRFS since apparently needed, and around 100GB in case I ever install big applications like experimenting with huge games or so). QUESTION: Is there a big problem with placing /home as a folder in the / partition of openSUSE (for instance by making recovery of a messed up opnSUSE much tuffer that way)?

And NO, I won’t fill /home with too many data from me (as opposed to from linux application insertions). Because big data from me – like my virtual machines – I will instead put in a different partition, a big one only made for my data. This data partition I want to be ext4 formatted, so these data can be shared with other OSs that might not be able to handle BTRFS on a multi-boot. QUESTION: I read that SOMEopenSUSE applications can work only with BTRFS partitions. Are any of those applications very important?

Of course. What else could they be for? But openSUSE being new to me I don’t know how to use them (like Timeshift on Linux Mint, or cool like it would be via GRUB menu?)

And again, does this give a need to keep /home split in another partition than /? Or is the opposite true?

My new laptop has 16 GB RAM. Enough?

If ever running out of RAM, will openSUSE instantly crash or first begin to noticeably slowing down, thus warning me to free up some RAM space?

Another term on the Installation Steps webpage that I could not understand is:

If you plan to suspend your machine, make sure to create a separate swap partition and check Enlarge to RAM Size for Suspend.

Yes, suspend is useful. So, unfortuntely a wasteful swap partition insisted on. But what does “check Enlarge” refer to? And what would be the desirable swap partition size on my 16 GB RAM laptop?
And is a swap partition safe to have on an nvme SSD? Won’t this overwork that part of the drive making it live not long? And since when does suspend (rather than hibernate) need a swap partition???

Also, the UTC and systemd target mentions are still unclear to me.

You need at least 60% (some say 50) of memory size for swap for hibernate . The memory image is compressed but compression estaminets are never exact.

the default these days is to put home on root (/) partition at least for BTRFS. But I prefer to keep them separate ie not all eggs in one basket but you can arrange things as you need and prefer you are in charge.

16 G may be enough to not to need swap but depends on what your use is. Note if you run out of memory you will crash the OS without warning. There is no firm swap size recommended. In old days it was 1.5X memory but even having a small swap may save you from a crash

For TW i recommend BTRFS it allows roll back which helps if an update breaks something. Which does happen sometimes with TW. I use ext4 but I’m running Leap not TW.

NOPE.

And NO, I won’t fill /home with too many data from me (as opposed to from linux application insertions). Because big data from me – like my virtual machines – I will instead put in a different partition, a big one only made for my data. This data partition I want to be ext4 formatted, so these data can be shared with other OSs that might not be able to handle BTRFS on a multi-boot. QUESTION: I read that SOMEopenSUSE applications can work only with BTRFS partitions. Are any of those applications very important?

Any reasonable code will run on btrfs. If it doesn’t ditch it or fix it.

Of course. What else could they be for? But openSUSE being new to me I don’t know how to use them (like Timeshift on Linux Mint, or cool like it would be via GRUB menu?)

You may boot into a snapshot, check whether it works and rollback.

And again, does this give a need to keep /home split in another partition than /?

NOPE.

My new laptop has 16 GB RAM. Enough?

Presumably yes. I configured several systems with 8GB RAM and no swap. Their users are happy with these machines. Previously they were calling me with the machines getting sluggish and even stopping working properly. With a single partition using btrfs and no swap space they stopped calling.

If ever running out of RAM, will openSUSE instantly crash or first begin to noticeably slowing down, thus warning me to free up some RAM space?

NOPE. Actually the OOM Killer kicks in and frees some memory. In most cases users aren’t aware of this background activity. They are happy with their machines working without freezes.

Another term on the Installation Steps webpage that I could not understand is: If you plan to suspend your machine, make sure to create a separate swap partition and check Enlarge to RAM Size for Suspend.

This is sloppy wording. It should read “If you plan to hibernate your machine …”. I have no swap, but I suspend my machines to RAM. This works really fast and is maintenance free even in the long term. Swap adds complexity and tends to cause annoyances and issues.

Yes, suspend is useful. So, unfortunately a wasteful swap partition insisted on. But what does “check Enlarge” refer to? And what would be the desirable swap partition size on my 16 GB RAM laptop?

Forget hibernate unless you have a really compelling reason for using it. Sleep works fine. Power uptake is around 2W for desktops and 0.6W for notebooks. Some users I know never turn off their laptops. I dup these machines on a quarterly schedule and reboot them.

And is a swap partition safe to have on an nvme SSD? Won’t this overwork that part of the drive making it live not long?

You may want to monitor SSD activity. One user presumably damaged a drive by inappropriate overuse: https://forums.opensuse.org/showthread.php/577573-BTRFS-error-writing

Also, the UTC and systemd target mentions are still unclear to me.

systemd groups services into functional units (targets):

**erlangen:~ #**  systemctl list-units --type target  
  UNIT                  LOAD   ACTIVE SUB    DESCRIPTION                       
  basic.target          loaded active active Basic System 
  cryptsetup.target     loaded active active Local Encrypted Volumes 
  getty.target          loaded active active Login Prompts 
  graphical.target      loaded active active Graphical Interface 
  integritysetup.target loaded active active Local Integrity Protected Volumes 
  local-fs-pre.target   loaded active active Preparation for Local File Systems 
  local-fs.target       loaded active active Local File Systems 
  multi-user.target     loaded active active Multi-User System 
  network-online.target loaded active active Network is Online 
  network.target        loaded active active Network 
  nss-lookup.target     loaded active active Host and Network Name Lookups 
  paths.target          loaded active active Path Units 
  remote-fs.target      loaded active active Remote File Systems 
  rpcbind.target        loaded active active RPC Port Mapper 
  slices.target         loaded active active Slice Units 
  sockets.target        loaded active active Socket Units 
  sound.target          loaded active active Sound Card 
  swap.target           loaded active active Swaps 
  sysinit.target        loaded active active System Initialization 
  time-set.target       loaded active active System Time Set 
  time-sync.target      loaded active active System Time Synchronized 
  timers.target         loaded active active Timer Units 
  veritysetup.target    loaded active active Local Verity Protected Volumes 

LOAD   = Reflects whether the unit definition was properly loaded. 
ACTIVE = The high-level unit activation state, i.e. generalization of SUB. 
SUB    = The low-level unit activation state, values depend on unit type. 
**23 loaded units listed.** Pass --all to see loaded but inactive units, too. 
To show all installed unit files use 'systemctl list-unit-files'. 
**erlangen:~ #**

VPN requires graphical target.

Physical machines are recommenced to use UTC for the real time clock and have the system synchronized properly. openSUSE uses chrony:

**erlangen:~ #** systemctl list-dependencies --reverse chronyd.service  
chronyd.service 
**●** └─multi-user.target 
**●**   └─graphical.target 
**erlangen:~ #**
**erlangen:~ #** systemctl status chronyd 
**●** chronyd.service - NTP client/server 
     Loaded: loaded (/usr/lib/systemd/system/chronyd.service; **enabled**; preset: **disabled**) 
     Active: **active (running)** since Wed 2022-11-09 20:23:32 CET; 1 day 10h ago 
       Docs: man:chronyd(8) 
             man:chrony.conf(5) 
   Main PID: 1331 (chronyd) 
      Tasks: 1 (limit: 4915) 
        CPU: 92ms 
     CGroup: /system.slice/chronyd.service 
             └─1331 /usr/sbin/chronyd

Nov 09 20:23:32 erlangen chronyd[1331]: chronyd version 4.3 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +NTS +SECHASH +IPV6 -DEBUG) 
Nov 09 20:23:32 erlangen chronyd[1331]: Frequency 2.968 +/- 0.158 ppm read from /var/lib/chrony/drift 
Nov 09 20:23:32 erlangen systemd[1]: Started NTP client/server. 
Nov 09 20:24:04 erlangen chronyd[1331]: Selected source 2001:a60::123:1 (ntp.mnet-online.de) 
**erlangen:~ #**

You obviously do not know what OOM killer actually does. Killing running process is very far from “background activity” and certainly something users become aware of rather fast.

Of course, swap is not necessary. It simply allows to have more concurrent workload by moving the content of currently unused memory to swap - which is exactly “free some memory” and yes, users usually “aren’t aware of this background process”. It also provides some headroom for burst of activity (like starting new process).

It is just like closet. You do not need closet, but then all those rarely used household accessories will either take up space in your living room (leaving less space to you) or you will have to do without them.

I am kindly asking you to stop this kind of unsupported claims. You made more of these in the past. I am annoyed.

Thanks again for teaching me. :slight_smile:

OK…

So far I believe I understood this much:

/ and /home together in the same partition is fine
BTRFS important for this partition (for sometimes needed roll backs)
Swap patition unnecessary. (and as I read elsewhere, a used swap partition could reduce the lifetime of an SSD drive)

Still not yet sure if BTRFS would indeed be better than ext4 on my data partition.

OK. Roll-back is of course necessary (and much better than reinstallation, I would think) when an OS is failing (like no longer booting). But can a roll-back also instead merely bring back a former version of application when its upgrade made it bad?

Wow! Sounds easy! (at east the boot… less sure how to make that rollback then)

ponder Is the OOM Killer installed and running by default? Also: if it kills an application the application (and me) may not get a chance to save files before that kill? In that case, is there a better handling?

Hibernate has given me problems (like failure to boot) on laptops. What would be nice would be a setup letting applications and the files they had open when shutting down restart after booting. Is there a good way for that?
Also, are regular reboots necessary for TUMBLEWEED’s updates?

How to avoid damaging inappropriate overuse of drive/partition? (Sorry, I don’t capture much insight from that linked thread; and UTC and systemd target points remain still unclear to me – what they are about or how they work. New as all this is to me, a simple sentence or two on each of them – telling me what I should do – might be best to get me started in those areas) (and was there even a sudden mentioning of a virtual private network (VPN) popping up?)

It is kernel facility which is available by default.

if it kills an application the application (and me) may not get a chance to save files before that kill

Correct.

Yep. This works best on all machines running Tumbleweed I have seen in past 3 years. If, for some reason issues occur on your system, you can easily switch to a different configuration.

BTRFS important for this partition (for sometimes needed roll backs)

Default configurations of btrfs and snapper are unique selling points of openSUSE.

Swap partition unnecessary. (and as I read elsewhere, a used swap partition could reduce the lifetime of an SSD drive)

Swap on modern Linux is overrated. Sure, having swap is better than running out of memory. But nothing comes close to ample RAM. After three days of uptime host erlangen has:

**erlangen:~ #** uptime 
 07:45:02  up 3 days 11:21,  7 users,  load average: 0.26, 0.17, 0.15 
**erlangen:~ #** free -h --si 
               total        used        free      shared  buff/cache   available 
Mem:             32G         12G        4.1G        814M         16G         19G 
Swap:             0B          0B          0B 
**erlangen:~ #**

RAM is shared between user processes and file system cache, which makes for extreme responsiveness even under heavy background activity by content creation:

**erlangen:~ #** hdparm -tT /dev/nvme0n1

/dev/nvme0n1: 
 Timing cached reads:   53034 MB in  1.99 seconds = 26587.32 MB/sec 
 Timing buffered disk reads: 4578 MB in  3.00 seconds = 1525.71 MB/sec 
**erlangen:~ #**

Still not yet sure if BTRFS would indeed be better than ext4 on my data partition.

Go with btrfs. When encountering issues try to resolve them.

OK. Roll-back is of course necessary (and much better than reinstallation, I would think) when an OS is failing (like no longer booting). But can a roll-back also instead merely bring back a former version of application when its upgrade made it bad?

Yep. Rollback works perfectly with /usr. However some directories are excluded from snapshotting:

**erlangen:~ #** cat /etc/fstab 
UUID=19CF-0B54                             /boot/efi               vfat   defaults                      0  0 
UUID=0e58bbe5-eff7-4884-bb5d-a0aac3d8a344  /                       btrfs  defaults                      0  0 
UUID=0e58bbe5-eff7-4884-bb5d-a0aac3d8a344  /.snapshots             btrfs  subvol=/@/.snapshots          0  0 
# subvolumes exempted from snapshotting 
UUID=0e58bbe5-eff7-4884-bb5d-a0aac3d8a344  /var                    btrfs  subvol=/@/var                 0  0 
UUID=0e58bbe5-eff7-4884-bb5d-a0aac3d8a344  /usr/local              btrfs  subvol=/@/usr/local           0  0 
UUID=0e58bbe5-eff7-4884-bb5d-a0aac3d8a344  /srv                    btrfs  subvol=/@/srv                 0  0 
UUID=0e58bbe5-eff7-4884-bb5d-a0aac3d8a344  /root                   btrfs  subvol=/@/root                0  0 
UUID=0e58bbe5-eff7-4884-bb5d-a0aac3d8a344  /opt                    btrfs  subvol=/@/opt                 0  0 
UUID=0e58bbe5-eff7-4884-bb5d-a0aac3d8a344  /home                   btrfs  subvol=/@/home                0  0 
UUID=0e58bbe5-eff7-4884-bb5d-a0aac3d8a344  /boot/grub2/x86_64-efi  btrfs  subvol=/@/boot/grub2/x86_64-efi  0  0 
UUID=0e58bbe5-eff7-4884-bb5d-a0aac3d8a344  /boot/grub2/i386-pc     btrfs  subvol=/@/boot/grub2/i386-pc  0  0 
**erlangen:~ #**

Wow! Sounds easy! (at east the boot… less sure how to make that rollback then)

Selecting a working snapshot from the grub boot menu is easy. Make it the default by typing “snapper rollback” in a root shell.

ponder Is the OOM Killer installed and running by default? Also: if it kills an application the application (and me) may not get a chance to save files before that kill? In that case, is there a better handling?

Obviously the better and safer solution is closing an application when no longer needed. However to my experience users are lazy and tend to mess. Users of the machines I assembled most of time are not aware of OOM killer kicking in. They have saved their data or the application saved it automatically. They don’t mind. But they are annoyed by sluggish behaviour of Tumbleweed due to swapping.

Hibernate has given me problems (like failure to boot) on laptops. What would be nice would be a setup letting applications and the files they had open when shutting down restart after booting. Is there a good way for that?

KDE supports saving graphical sessions. This works reasonably well. If it gets in your way you can easily revert.

Also, are regular reboots necessary for TUMBLEWEED’s updates?

It depends. Upgrades of Tumbleweed may require reboot. Zypper will inform you:

**erlangen:~ #** journalctl -b -4 -g reboot 
Oct 19 20:05:01 erlangen zypper[24702]: The following package requires a system reboot: 
Oct 19 20:05:01 erlangen zypper[24702]:     Note: System reboot required. 
Oct 19 20:07:08 erlangen zypper[24702]: Reboot is suggested to ensure that your system benefits from these updates. 
Oct 20 09:49:36 erlangen zypper[30043]: Reboot is suggested to ensure that your system benefits from these updates. 
Oct 20 14:20:52 erlangen systemd-logind[965]: **System is ****reboot****ing.**
Oct 20 14:20:53 erlangen systemd[1]: Show Plymouth Reboot Screen was skipped because of a failed condition check (ConditionKernelCommandLine=!plymouth.enable=0). 
**erlangen:~ #** 

How to avoid damaging inappropriate overuse of drive/partition? (Sorry, I don’t capture much insight from that linked thread; and UTC and systemd target points remain still unclear to me – what they are about or how they work. New as all this is to me, a simple sentence or two on each of them – telling me what I should do – might be best to get me started in those areas) (and was there even a sudden mentioning of a virtual private network (VPN) popping up?)

Beware of disk trashing. HDDs would respond by acoustic noise and sluggishness: https://www.minitool.com/lib/disk-thrashing.html Thrashing of SSDs may go undetected for an extended period of time.

Periodic trim helps with the internal garbage collection of the SSD. It does no harm to the drive and goes undetected by most users due to very modest consumption of resources. You may run it daily.

**erlangen:~ #** journalctl -q -u btrfs-trim.service -g Consumed -o short-monotonic  
 3718.426613] erlangen systemd[1]: btrfs-trim.service: Consumed 1.693s CPU time. 
 2584.105939] erlangen systemd[1]: btrfs-trim.service: Consumed 1.872s CPU time. 
  117.970312] erlangen systemd[1]: btrfs-trim.service: Consumed 1.868s CPU time. 
[25164.465037] erlangen systemd[1]: btrfs-trim.service: Consumed 1.825s CPU time. 
[218914.692497] erlangen systemd[1]: btrfs-trim.service: Consumed 1.716s CPU time. 
  249.366750] erlangen systemd[1]: btrfs-trim.service: Consumed 2.139s CPU time. 
**erlangen:~ #** 

When installing a new Tumbleweed you may want to have graphics most of the time. Select graphical target as default. Switching between multi-user.target and graphical target is easy. But you can always upgrade to graphics at a later time.

Hardware Clock being set to local time is an annoyance. Make sure to check “Hardware Clock set to UTC”: https://doc.opensuse.org/documentation/leap/startup/html/book-startup/cha-install.html#sec-yast-install-date-time

Summary

I try to strictly adhere to the above when assembling a new machine or installing a new Tumbleweed. It does away with virtually all annoyances encountered since 1976.

I’m not a guru, but the advantage of having / and /home in separate partitions are (or might be):

  • You can reinstall the system without any Data loss. Let’s say SuperGau Happens, System doesn’t boot anymore, Snapshoots don’t boot anymore (Let’s say GRUB is broken) -> You can reinstall Opensuse from a USB stick to / and mount your existing /home without losing the data on /home.
  • You might want to encrypt your Data. But you might not want to encrypt the whole Operating system because of performance. Then you can only encrypt /home