On Tue, 2025-09-16 at 21:55 -0600, home user via users wrote: > What I vaguely recall from several years ago, the first time dnf told me > it couldn't do the upgrade because I didn't have enough space, was that > someone suggested re-installing with less restrictive partitioning. I > passed on that because it was a dual-boot desktop (with windows-7), and > the re-install would have been difficult...[snip]... > > If I'm remembering correctly, one cause of the problem was kernels were > in their own partition (/boot?), and that filled up. (Some other > directory also got very full because stuff in it was not being cleaned > out properly by the upgrades.)
The other will probably have been a cache inside /var (for yum/dnf package updates). They downloads and store them until finished installing them, then delete them (unless something goofs up). But it can be configured to keep them (people with multiple systems sometimes turn one PC into a local cache for them all). It can go a bit haywire if you'd updated systems over the top for many years, and an old one used different repos, and something didn't erase the previously cached files so they were left hanging around. Something along those lines... > If I'm remembering correctly, the suggestion I mentioned above was > intended to combine /boot with other partitions, resulting in a much > bigger partition that included /boot as a directory. Boot partitions can be expanded, if you have spare drive space. Or boot can be moved to another bigger partition. Boot can simply be a folder in "/" if your system can read from it at boot time (and since UEFI took over from BIOS, more systems can). There are filesystems that act less like partitions with fixed sizes, and more like folders with adjustable quotas. But with today's huge drive sizes, you can easily give things far more partition space than they need without making too much of a sacrifice to your own use of storage space. > * I was advised by several people to keep system files and personal > files on separate drives. It's supposed to be safer, and make > re-installs both easier and safer. There are some advantages with doing that. And you can mount it as your /home drive, or your /home on the other drive can link into it. I'd just mount it as /home on a single-boot system. > * When I ordered the desktop, I was anticipating dual boot, and I did > not know that the two distros could use the same /home. While *that* is doable, you can have clashes with running the same software on two different distros, but different versions, and them trying to share the same .config files in your homespace. Or them not clashing, but having separate configurations that you have to individually customise on each distro's installation. That sort of thing can get really annoying when using an ISP's mail system that can tell you're accessing it from different software, and it insists that everything must have a unique password that they've created for you for each mail client (but doesn't tell you that they have that requirement). And I'm sure hackers aren't as stymied by that pseudo-security measure as the ISP thinks they are. For dual booting, my inclination is let each distro have a /home inside its own drive, where their userspace will be, and their apps will store their own configs and caches. And use a second drive for your own data (either mounted or linked into the different OSs spaces). I more or less do that with networked storage, files to be kept and accessed anywhere are in the big networked drive. Files I've temporarily downloaded, or working with in the short term, while doing something can stay on the system in question for the meantime. Then get deleted or archived. Dual-booting comes with its own set of headaches if you actually work with both installations. It's less of an issue if the second one is just an experiment. -- uname -rsvp Linux 3.10.0-1160.119.1.el7.x86_64 #1 SMP Tue Jun 4 14:43:51 UTC 2024 x86_64 (yes, this is the output from uname for this PC when I posted) Boilerplate: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the mailing list. -- _______________________________________________ users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
