I have searched and don’t see any info at all on how/if data in /root is protected (or not) during upgrades. Or if it’s just wiped and recreated, although that doesn’t seem likely. Or if files are just over written on a case by case basis if needed.
Thanks for any thoughts.
Rufus
/root is the home directory of user root, It is created at system installation with some minimal contents (e.g. there is an empty bin directiory there). During further existence, some programs/tool called by root may create there configuration files or cache files (I see e.g. .vim there from my vi usage as root).
Nothing is changed there by an update (zyper patch/up) or upgrade (zypper dup).
/root/ is like any other user’s homedir except for one thing. Since /home/ can be on a filesystem that might not be available when boot completes, root’s homedir must be on the / filesystem, or else there could be no root login possible, and no way to fix whatever needs fixing, or shutting down or rebooting, without risk to the filesystem(s).
It depends on the partitioner option selected:
**erlangen:~ #** findmnt --types btrfs
TARGET SOURCE FSTYPE OPTIONS
/ /dev/nvme0n1p2/@/.snapshots/1161/snapshot] btrfs rw,relatime,ssd,space_cache=v2,subvolid=1744,subvol=/@/.snapshots/1161/snapshot
├─/boot/grub2/x86_64-efi /dev/nvme0n1p2/@/boot/grub2/x86_64-efi] btrfs rw,relatime,ssd,space_cache=v2,subvolid=263,subvol=/@/boot/grub2/x86_64-efi
├─/opt /dev/nvme0n1p2/@/opt] btrfs rw,relatime,ssd,space_cache=v2,subvolid=261,subvol=/@/opt
├─/.snapshots /dev/nvme0n1p2/@/.snapshots] btrfs rw,relatime,ssd,space_cache=v2,subvolid=265,subvol=/@/.snapshots
├─/boot/grub2/i386-pc /dev/nvme0n1p2/@/boot/grub2/i386-pc] btrfs rw,relatime,ssd,space_cache=v2,subvolid=264,subvol=/@/boot/grub2/i386-pc
├─/home /dev/nvme0n1p2/@/home] btrfs rw,relatime,ssd,space_cache=v2,subvolid=262,subvol=/@/home
├─/root /dev/nvme0n1p2/@/root] btrfs rw,relatime,ssd,space_cache=v2,subvolid=260,subvol=/@/root
├─/srv /dev/nvme0n1p2/@/srv] btrfs rw,relatime,ssd,space_cache=v2,subvolid=259,subvol=/@/srv
├─/usr/local /dev/nvme0n1p2/@/usr/local] btrfs rw,relatime,ssd,space_cache=v2,subvolid=258,subvol=/@/usr/local
└─/var /dev/nvme0n1p2/@/var] btrfs rw,relatime,ssd,space_cache=v2,subvolid=257,subvol=/@/var
**erlangen:~ #**
Experts may use the expert option and specify what happens to each of the above. Dilettantes are better off with a new install: https://forums.opensuse.org/showthread.php/541321-Upgrading-the-Hardware?p=3086058#post3086058
I see no connection whatsoever between what you post and the OPs question.
Before performing an upgrade it has always been a good idea to double check /etc/fstab.
**erlangen:~ #** findmnt --types btrfs
TARGET SOURCE FSTYPE OPTIONS
/ /dev/nvme0n1p2/@/.snapshots/1161/snapshot] btrfs rw,relatime,ssd,space_cache=v2,subvolid=1744,subvol=/@/.snapshots/1161/snapshot
**├─/root /dev/nvme0n1p2/@/root] btrfs rw,relatime,ssd,space_cache=v2,subvolid=260,subvol=/@/root **
├─/.snapshots /dev/nvme0n1p2/@/.snapshots] btrfs rw,relatime,ssd,space_cache=v2,subvolid=265,subvol=/@/.snapshots
├─/boot/grub2/i386-pc /dev/nvme0n1p2/@/boot/grub2/i386-pc] btrfs rw,relatime,ssd,space_cache=v2,subvolid=264,subvol=/@/boot/grub2/i386-pc
├─/boot/grub2/x86_64-efi /dev/nvme0n1p2/@/boot/grub2/x86_64-efi] btrfs rw,relatime,ssd,space_cache=v2,subvolid=263,subvol=/@/boot/grub2/x86_64-efi
├─/var /dev/nvme0n1p2/@/var] btrfs rw,relatime,ssd,space_cache=v2,subvolid=257,subvol=/@/var
├─/home /dev/nvme0n1p2/@/home] btrfs rw,relatime,ssd,space_cache=v2,subvolid=262,subvol=/@/home
├─/opt /dev/nvme0n1p2/@/opt] btrfs rw,relatime,ssd,space_cache=v2,subvolid=261,subvol=/@/opt
├─/srv /dev/nvme0n1p2/@/srv] btrfs rw,relatime,ssd,space_cache=v2,subvolid=259,subvol=/@/srv
└─/usr/local /dev/nvme0n1p2/@/usr/local] btrfs rw,relatime,ssd,space_cache=v2,subvolid=258,subvol=/@/usr/local
**erlangen:~ #**
Use Expert Partitioner to manage btrfs subvolumes. /root is one of them on host erlangen.
Double check looking for what?
My reading of OP is that his meaning for “/root” applied to root’s homedir, not the root filesystem. If he meant root filesystem, then upgrade involves no “wiping”, but does commonly involve replacement of various config files, aka data.
When I did a zypper dist-upgrade I checked fstab of Leap 15.3 first:
**6700K:~ #** fdisk -l /dev/sdb
**Disk /dev/sdb: 232.89 GiB, 250059350016 bytes, 488397168 sectors**
Disk model: CT250MX500SSD1
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 3B04C452-DAD9-45C6-9BD3-AE398288F628
**Device **** Start**** End**** Sectors**** Size****Type**
/dev/sdb1 2048 1026047 1024000 500M EFI System
/dev/sdb2 1026048 283596799 282570752 134.7G Linux filesystem
**/dev/sdb3 283596800 385996799 102400000 48.8G Linux filesystem **
/dev/sdb4 385996800 386029567 32768 16M Microsoft reserved
/dev/sdb5 386029568 488396799 102367232 48.8G Microsoft basic data
**6700K:~ #**
**6700K:~ #** findmnt /mnt/Leap-15.4
TARGET SOURCE FSTYPE OPTIONS
**/mnt/Leap-15.4 /dev/sdb3** btrfs rw,relatime,ssd,space_cache,subvolid=5,subvol=/
**6700K:~ #**
**6700K:~ #** cat /mnt/Leap-15.4/@/.snapshots/1/snapshot/etc/fstab
UUID=85d405ec-d559-49a1-b59c-5c5c9f176724 / btrfs defaults 0 0
UUID=85d405ec-d559-49a1-b59c-5c5c9f176724 /.snapshots btrfs subvol=/@/.snapshots 0 0
UUID=85d405ec-d559-49a1-b59c-5c5c9f176724 /var btrfs subvol=/@/var 0 0
UUID=85d405ec-d559-49a1-b59c-5c5c9f176724 /usr/local btrfs subvol=/@/usr/local 0 0
UUID=85d405ec-d559-49a1-b59c-5c5c9f176724 /tmp btrfs subvol=/@/tmp 0 0
UUID=85d405ec-d559-49a1-b59c-5c5c9f176724 /srv btrfs subvol=/@/srv 0 0
**UUID=85d405ec-d559-49a1-b59c-5c5c9f176724 /root btrfs subvol=/@/root 0 0
**UUID=85d405ec-d559-49a1-b59c-5c5c9f176724 /opt btrfs subvol=/@/opt 0 0
**UUID=85d405ec-d559-49a1-b59c-5c5c9f176724 /home btrfs subvol=/@/home 0 0
**UUID=85d405ec-d559-49a1-b59c-5c5c9f176724 /boot/grub2/x86_64-efi btrfs subvol=/@/boot/grub2/x86_64-efi 0 0
UUID=85d405ec-d559-49a1-b59c-5c5c9f176724 /boot/grub2/i386-pc btrfs subvol=/@/boot/grub2/i386-pc 0 0
UUID=6B6D-1CDE /boot/efi vfat utf8 0 2
**6700K:~ #**
/root is a folder, but there is more to it:
**6700K:~ #** btrfs subvolume show **/mnt/Leap-15.4/@/root**
@/root
Name: root
UUID: 7d39f69c-d5cc-5c40-be46-26b9a6a69a14
Parent UUID: -
Received UUID: -
Creation time: 2021-08-06 11:47:31 +0200
Subvolume ID: 261
Generation: 10201
Gen at creation: 20
Parent ID: 256
Top level ID: 256
Flags: -
Send transid: 0
Send time: 2021-08-06 11:47:31 +0200
Receive transid: 0
Receive time: -
Snapshot(s):
Quota group: 0/261
Limit referenced: -
Limit exclusive: -
Usage referenced: 10.91MiB
Usage exclusive: 10.91MiB
**6700K:~ #**
The same for /home:
**6700K:~ #** btrfs subvolume show /mnt/Leap-15.4/@/home
@/home
Name: home
UUID: b9e342b5-18bd-2f48-a438-a1192f234e7e
Parent UUID: -
Received UUID: -
Creation time: 2021-08-06 11:47:31 +0200
Subvolume ID: 263
Generation: 10201
Gen at creation: 24
Parent ID: 256
Top level ID: 256
Flags: -
Send transid: 0
Send time: 2021-08-06 11:47:31 +0200
Receive transid: 0
Receive time: -
Snapshot(s):
Quota group: 0/263
Limit referenced: -
Limit exclusive: -
Usage referenced: 1.35GiB
Usage exclusive: 1.35GiB
**6700K:~ #**
To my experience users tend to ignore these facts. But a consistent /etc/fstab as shown above is a prerequisite for a smooth upgrade. More: Update openSUSE 15.3 to 15.4
Thank you all for you comments. That clarifies it. I did in fact mean the directory /root, not the root file system. I apologize for the delayed response. I need to try to correct my profile or something so I get email when my post is answered.
The broad overview:
I have been “upgrading” as opposed to “installing”, even though many recommend “installing” for purposes of system hygiene and purity. Meaning, far as I can see, safer with fewer unexpected issues hooked to pre-existing system data. That’s nice, but…
“Installation” means manually reinstalling everything not provided by default. And resetting dozens (at least) of configuration tweaks. THAT, in practice, is a huge problem, for me anyway. Example: The StartMenu needs to be reset back in order since I use a custom structure which helps me see what I have available more or less quickly and easily years after installing something (which I often can’t quite remember the name of); perhaps that’s just an “easy” restore, but it goes on the list of before/after procedures which quickly grows and grows. Dozens, maybe hundreds of settings which I have found desirable over many years go away with an “install”. There may be this way or that way to save various things and “reinstall” somewhat more quickly. But one needs to maintain and find the list (how-to’s, config files, restore/reinstall procedures, etc, etc) from last time, and at least review all the procedures before use. It’s often 2-3 years between system upgrades and I have zero expectations of pretty much anything going right in that space (restoring/reinstalling my apps and settings after and “install”). This is based on a lot experience, and, of course, on my own work habits.
IOW, “installation” of new versions of systems is tantamount to throwing out all the productivity tweaks accumulated since last version change - and often many years prior - and this is a serious problem. Happily, thus far, “upgrade” appears to mostly work as expected, leaving most of my tools and settings alone. I personally have experienced few if any problems. Actually I did two glitches upgrading 15.4, but those seem a small price to pay compared with chasing all my apps and configs. The glitches: The upgrade script for local media wouldn’t go past the system check because it “lost” the media device. I upgraded manually, repo changes then "dup… The upgrade worked happily and all was well except one thing. It killed my wifi dongle, an rt82xxx chip which had survived the last three upgrades. After an hour of hassle, I just bought another dongle (RALINK) with a different chip that worked out of the box. I’m mostly good with the guys who engineer the upgrade procedures.
However, while I was pretty sure that /home would not be messed with, I wasn’t that sure about /root. I have been saving install media for the dozens of packages, mostly utilities, which I pull down, mostly from software.opensu… into a special user on /home. But most are useful and desirable for all users, and it would be cleaner/clearer to locate that kind of system wide file somewhere the data is not attached to a particular user and yet would persist through “upgrades”. /root seems the obvious place but I needed to get some specific exact info on the policy for /root across “upgrades”.
@karl…
I think you’re probably correct that fstab has accumulated some road kill. I haven’t gone through it specifically looking, but I’ve noticed a few lines that I can’t relate to anything in particular. I may get around to looking eventually, but so far it doesn’t seem to have caused any problem. Possibly that’s because I’ve never used btrfs - never seen the ROI for the small systems I have to deal with. For me ext4 “ain’t broke” and my volume maps are very simple, pretty much flat. Eventually I’ll have to get real about snapshots and such as the predators move into our world and target us softies. Right now, I just do backups.
Again, thanks to all.
Rufus
My downloads mostly go to a separate filesystem named /isos/, formatted specially for large files. Since it’s not part of the standard filesystem structure, the installer ignores it, and its addition to fstab is on my post-installation todo list. Nevertheless, most of my new installations are a part of alpha/beta testing. Most everything else gets upgraded. Zypper is the best package manager and updater/upgrader bar none among those I’ve used more than trivially.
You have a long, long story in post #9, and I did not study it in detail.
I think from posts #2 and #3 you will have read that at least two people here understood correct that with /root, you meant just that: /root… So your question was already answered with that.
Reading somewhere at the end of post #9, I understand that you want to put files that are to be used in common by all users in /root. That is NOT a good idea. /root is the home directory of root. Nobody else should ever have access to it, or anything in there.
There are places enough for what you want. Like /usr/local, or for larger, more complicated products /opt.
Have a read: https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
I’ll look at the wiki link, see if a better way rears its head.
What I meant was not that users accessed the files, nor that I installed apps into /root. Just that the settings and utilities which I install should in most cases be available to all users to run and thus the packages (media and associated notes and tweaks) do not fit logically with any one user, but rather with the system as a whole. So /root seemed a reasonable location for install-media. To my (admittedly limited) knowledge, regular system dirs don’t provide official, ready-made, closet space for anything except what comes from the distro repos; but maybe I’m overlooking something under /opt or /user, or maybe it’s ok to dump stuff in /src - but I think that gets major changes when upgrading. There are also my (and others’) notes about tweaking configs, some scripts and probably a few other things which pertain to local admin duties. That seems likely fodder for /root if it will persist there. Or maybe …/local? I’ll look through the wiki.
As far as installed locations, I mostly use rpm’s and I pretty much let the media package and yast install the app where it likes.
Regards,
Rufus
It’s your PC. You may do with it as you wish. For what you’re describing, I suggest creating a custom directory writable by all local users, either in /home/, or in /. If in /, I strongly suggest mounting a discrete filesystem to it, so that these files aren’t co-mingled on the same filesystem as the OS. The same idea of a separate filesystem may be consistent with choosing a directory in /home/, depending on how many users you have, whether /home/ itself is a separate filesystem, and how much of this miscellaneous data is involved. /root/'s special reason for existence makes it definitely not appropriate for such user data. My PCs include
# ls -dl /home/down*/
drwxrwx--- 5 <filter> <filter> 15360 Sep 1 01:35 /home/downloads/
for similar purpose.
@mrmazda et al
I believe you also mentioned you use an “isos” dir for large files. I think I may have the same general philosophy - put functionally distinct data into separate file systems.
My /home is a separate file system which remains “offline” when I do do an install; I put it back in place once I know the new system looks like behaving. Then I deal with “issues” when reinstalling the non-distro software. May that not be needed for a while.
If I understand your “Download” file system, I tried something similar once. But at the moment I’m not as generous to users. Six-seven years ago with just three users I drowned in permissions problems. Likely my own ignorance counting coup on me. Elegant design required changing permissions on the fly, timing or forcing backups dependent on files appearing in the dirs, and various other headaches - I wasn’t just granting equal access to a dir. They could write but not change or delete afterward. And other stuff I don’t recall (wonder why…). I use a version of “sneaker net” now - gawd-the-root comes in and helicopters needed files from one user to another. Occasionally. There are, by definition, very few such interventions needed… <g>
Presently I have a user “shadow-admin” which serves as base camp for all the non-distro common stuff - isolated from the system volume. There’s a link to it in /root and I’m the only permitted user. I started this out trying to decide if that was a good idea and I’m still not sure but I’m leaning toward keeping it in some form or other. I do root stuff logged into as root.
I have to read the wiki and other filing screeds. It’s good to stay in line with standards and I haven’t looked at that for quite a while. Particularly where scripts of various permitted rank should live. Like as not there’s better ways or at least standard ways.
Thanks for all your thoughts. They have given me a wider perspective and slightly different pov to start organizing things some more. Homework time.
Regards,
Rufus