Due to some problems I’m unable to solve for some period of time, I’d like to do a fresh install of Fedora 37. Problems are here if you’re interested.
So I have a dual boot with Windows 10 and I’d prefer keeping Windows 10 as it is, it’s a seperate partition from Fedora. Fedora root is currently on /dev/sda6 and /boot/efi is on /dev/sda2.
I don’t know how to install it from Blivet GUI, but if possible I’d like to save all of my data. If not, I’ve got it backed up anyways(just not the whole Home, I only backed up what i needed cause i figured that whole Home is too heavy on GBs because it has some configurations that i could just setp up later)
Aside from not knowing how to install it, I’m also thinking of doing something that qill benefit me long term. Something like making a seperate /home or /swap or do a little bit of partitioning and make it overall more stable for future use.
I don’t really know what to do yet alone how, so all advices are welcomed.
If i need to post any additional information, please tell me and I’ll post it.
Typically, you would want to share the /boot/efi partition with Windows in a dual boot scenario like this. Generally, the EFI partition should also be the first partition on the boot disk. By the spec, it doesn’t technically have to be, but given that most every OEM Windows PC is going to have it as the first partition, it’s possible that your BIOS might not bother to boot it if it isn’t there.
Also, keep in mind that the EFI partition must be a FAT32 filesystem. That is required by the spec. /boot otherwise should probably be ext4, which is the default. Grub can technically do btrfs now, but the Fedora default for /boot is still ext4 and that’s going to have the best overall compatibility at the moment.
You don’t need /swap anymore since zram is now the default. Fedora will automatically create a swap for you if your physical memory fills up. You can still choose to do the old static swap method, but it’s not necessary and probably also not helpful.
Regarding /home, by default btrfs will make /home as a separate sub-volume so you no longer need to define how much to give it vs the root / partition. This way they are separate sub-volumes but don’t have a hard up-front physical limit on the file-size, so you can have your cake and eat it too with btrfs this way.
Do you have any reference (URL or whatever) to documentation of that?
I don’t think you are correct. But in case I’m wrong, I’d like to learn.
If that was just your description of the behavior of zram, I think that is a very misleading description.
I have a generally low opinion of zram. Most people buy computers with excessive ram, so they don’t need any swap. Zram isn’t a terrible choice for that situation, because it doesn’t tie up significant resources when it isn’t needed, and it can substitute very efficiently for a little bit of swap space in the boundary case that you need a little. But it isn’t a great choice.
Hard disk space is super cheap if you have a hard disk. Even SSD space is quite cheap. So tying up some of that resource when you have no real need of swap is not too bad. If you actually need significant swap space, real swap space gets the job done, while zram doesn’t. I don’t think the boundary case of needing just a little swap (for which zram is faster) is very common.
Any experienced Linux user should know whether they actually need swap space and be able to estimate how much.
I don’t understand what you’re trying to do with Blivet.
So far as I understand (without trying it myself) Blivet is a disk partitioning tool, not a Linux installer.
Assuming you intend to do a clean install and then restore files from backup, you might simplify things by using a tool like Blivet to delete all partitions that are not part of the Windows install. Then you can let Anaconda do a default partitioning into the unpartitioned space left by those deletions.
I hope Anaconda would figure out how to share the existing EFI partition (but I’m not sure it will).
My own general experience with Anaconda partitioning is that I can’t ever get it to do what I want. So I usually let it do what it wants, and then I clean up afterwards.
If it creates its own EFI partition, I would know how to merge that into the original and then delete the new one.
If I want a swap partition (in fact I always do) and I can’t get Anaconda to do that, I know how to shrink some other partition and create the swap.
I like the (Fedora default) idea of / and /home being separate subvolumes of one btrfs. If you don’t like that, I think you can get to whatever you want.
It’s been the default since Fedora 33. No need for most users to mess with static /swap anymore and doing much swapping on an SSD is a good way to decrease it’s longevity. zram does a great job minimalizing the need for swap and the disk IO necessary for it.
Thanks. I never found that in my recent attempts to do partitioning in the Fedora installer. I’ll take another look next time I try to experiment with that installer.
There is no need for most users to have any swap at all, including zram.
But if you actually need any swap, then there is only a very narrow range within which zram will do the job. Most users need none (so zram is unnecessary for them). Most of the rest need real swap; zram is insufficient.
You’re of course welcome to architect your own system that way. Fedora uses different defaults. You’re of course also welcome to disagree with those defaults, but regardless, zram is fully supported and I believe the rationale for it is sane. I’ve also maxxed out the 64GB of my laptop before and appreciated zram in that scenario, for what it’s worth. Since it was introduced back in Fedora 33, I don’t think I’ve ever heard of a single issue here or on IRC that someone had with using it, so my own experience with it and the feedback from others seems to indicate that it’s a generally sane choice, even if machines with lesser amounts on memory might stand to benefit even more from it.
FWIW, I’m utilizing it right now on my laptop with 48GB of memory:
$ free -m
total used free shared buff/cache available
Mem: 45882 16111 9125 401 20645 28800
Swap: 8191 948 7243
See, no /swap:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
zram0 252:0 0 8G 0 disk [SWAP]
nvme0n1 259:0 0 953.9G 0 disk
├─nvme0n1p1 259:1 0 600M 0 part /boot/efi
├─nvme0n1p2 259:2 0 1G 0 part /boot
└─nvme0n1p3 259:3 0 952.3G 0 part
└─luks-8a9be667-0b6d-4912-89a4-652584ccdae7 253:0 0 952.3G 0 crypt /home
/
Granted, not everyone runs kubernetes clusters on their laptop
I don’t really want to have a fight over this. But if you want to read about issues with the use of zram, just look for the many complaints about issues with the OOM killer. If you dig into the details, none of those represent any actual problem with the OOM killer and all describe systems that need actual swap instead of zram and misunderstand that as OOM killer flaws.
I may have asked this question to generally, as I should really keep it simple considering I’m out of linux for more than a week.
So if it is possible to save data, and install Fedora 37, but kater configure partition and all of the stuff i need, i guess I’d go with that option.
I don’t really know if i need either /home or /swap partition. Former might be good, just to keep my data backed up if anything would to happen to the system.
As for /swap and zram, to be honest I don’t know, I don’t even know what It’s used for. But looking at this topic, it might be useful to me cause I only have 8GBs of RAM.
About Blivet, well, I’m not sure how to install and keep the data. Like, the idea is to go to Fedora installer and choose Blivet to setup all of these things correctly. I don’t what I’m supposed to set as mountpoints or basically anything.
A basic install of Fedora has the following mount points: /boot/efi /boot / /home
Those can be separate partitions or share partitions. /boot/efi acts as the boundary between the BIOS and the OS’s boot manager (grub2 for Fedora). It needs to be a specific file system type. That type is a poor choice for other mount points, so it generally isn’t shared with other mount points. /boot/efi ought to be shared among all the OS’s installed on a drive, but often isn’t.
/boot holds the next stage of the boot process for Fedora. It should be a file system type that grub2 fully supports. I think that rules out btrfs. The default seems to be ext4 and the default works well.
The software (Linux itself and installed packages) goes in / while your private data goes in /home. There are complicated pros and cons to separating vs. sharing / and /home. Using subvolumes of a btrfs is a great compromise between separate and shared, giving all of the benefits of shared with most of the benefits of separate.
To understand swap, you need to understand 3 of the major kinds of ram use:
There is ram use (primarily program data) that nominally exists only in ram. To free up that ram without losing that data, you either copy it to secondary storage (real swap) or compress it in place (zram).
There is ram use (primarily program code) that nominally exists identically in ram and on secondary storage. To free up that ram, it can be simply discarded at the cost of needing to reread it the next time it is used.
There is ram used (called “cache”) for content that nominally exists only on secondary storage, but by keeping a copy in ram the cost of reading it from secondary storage next time it is needed will be avoided.
When something is needed in ram, but all is occupied, Linux must kick something out to make room. The way computer programs normally behave, the most recently used contents are the most likely to be needed again soon. So across all 3 of the above types, Linux would like to kick out the least recently used. But the cost of kicking out (1) to real swap is twice as high (or even higher for SSD) than (2) or (3) because (1) must be written and later read, while (2) and (3) just discarded and later read. So there is a bias against pages of type (1). They must be a lot more stale (time since last use) than pages of types 2 or 3 before they are kicked out. With zram, a similar 2 to 1 comes from the expected effectiveness of compression: you need to kick out two pages to free one.
If you don’t have enough swap space, then Linux can only kick out types 2 or 3. If it kicks out too many of those simple tasks would take forever, so instead the “OOM killer” kills whole processes to keep the overall system useable.
The amount of what I have described as (1) above can vary widely depending on what you use your computer for. I often develop/test simulation software that must solve giant sparse matrices (solving causes major “fill in” so they don’t stay sparse). So memory of type (1) can exceed even the giant ram size of my machines, so lots of swap it needed. Video editing may be a more common activity with similar swap needs.
Many people have ram filled with programs and cache, while the data in use by those programs is trivial compared to the programs themselves. If they happen to have swap, then the data of programs that are idle for a long time can get swapped out and the system can run a trivial amount faster by allowing a bit more caching. But that improvement is trivial compared to having no swap. In that case, zram behavior is halfway between swap and no swap. It frees half as much ram for better caching. The transitions in and out for the swapped data is faster, but that speedup makes no difference because it only happens on super stale data.
If you’re used to Windows, it is called “page file” on Windows. swap is basically for supplementing physical memory with disk backed storage, which is slower but can save your computer from crashing if you run out of physical memory. On Linux, the kernel expects swap to be there in some form and it’s recommended that it exists even if you have plenty of physical RAM, even though it may not be strictly necessary. The old way of doing it is, unlike Windows, to have a separate partition for it. zram instead only creates swap as necessary and can utilize compression of your memory in the process. Honestly, you can do either and you may not notice any difference other than adding a /swap means a bit (not much) more complexity to your blivet operation and you’ll have slightly less disk space to use for storage otherwise.
All that to say, this got a little in the weeds, but here is the official docs for recommended partitions:
I’ll probably just skip on /swap partition. It worked pretty good without it. But I’ve got a couple of questions.
My root is currently ext4 i think. If i change it to btrfs, will i need to format it?
How do i even make subvolumes?
actually, how do i make everything that is stated in the link provided without loosing any data? I already have EFI /boot/efi partition of Fat32 but my root is ext4 and it isn’t a subvolume.
Plus, could i perhaps install everything now and later configure everything else without reinstalling? Because although i want to make a long term better system I also kind of want it to work as soon as possible. But if setting up all of these wouldn’t take much, then I’d like to set it up before installing.
Not true. Unless a system is running idle with a large amount of ram, swap is required. The more processes in use, and the more active a system is, the more swap is necessary. While a newer system with a lot of ram may not require use of swap, not everyone has the ideal system in that respect.
What about those using older machines with less than optimal ram? Not everyone can afford the latest and greatest machines with ideal hardware.
Zram can manage most that the majority of users need. It is fast and compresses data so there is no need to read&write to a physical swap for most use.
Anaconda always shares an existing efi partition as long as the installer is allowed to write to the drive where the efi partition is located. It has for many years.
Almost all are on systems that have limited ram available to start with, combined with the user using apps that are memory hungry.
Almost all systems install with /boot/efi shared unless the user either A) denies the use of the existing drive during the install or B) deliberately chooses to create a new efi partition.
If you’re using ext4 and want a separate /home from root /, then you will either need to make them as separate partitions or define them as separate volumes using LVM. In these cases, you’ll need to give the root and home volumes specific sizes. You can actually do this with automatic partitioning in Customize without Blivet by picking the LVM option.
If you’re using btrfs, then you can set /home as a sub-volume without needing to set specific sizes and just let btrfs sort it out for you based on available remaining space.
Here are some further documentation references that go into a bit more detail and sum up a TL;DR for this thread so far (the previews look the same, but they are different links):
I assume I did something wrong. But I still don’t know what.
I have a 950Gb SSD drive that had Ubuntu installed, including a /boot/efi partition. It also had lots of unpartitioned space. I ran the Fedora installer and enabled only that SSD drive and selected default partitioning. That gave me 3 new partitions: a new /boot/efi and a /boot and a btrfs with subvolumes for / and '/home`.
I later copied all the Fedora /boot/efi contents onto the previous partition (there was enough free space) and deleted the /boot/efi Fedora had created (and cleaned up /etc/fstab etc.) as part of my usual cleanup after failing to make Anaconda do what I want.
I later messed up my Ubuntu install, and no longer have any interest in resurrecting it, but haven’t cleaned it up because I never actually needed nearly as much as 950GB. That is the system I’m on now.
I had similar results installing Fedora on a couple of old Windows machines (which I haven’t entirely cleaned up yet). Each time, I got a new /boot/efi that I didn’t want.
I thought you had everything you actually need backed up.
In that case, you could delete your existing ext4 partition then let Fedora do default partitioning, which will create a new /boot and a new btrfs including both / and /home. Then you could restore into /home from backup.
Alternately, you could shrink the existing ext4 to a bit under half its size (preferably a bottom up shrink, rather than top down, so it ends up at the end of the drive). I don’t know partitioning tools other than gparted, but that step is pretty easy in gparted.
Next do that default install. Next copy over what you want from the old /home to the new one. Next delete the ext4 and extend the btrfs.
Most of those steps must be done while booted from the “live” image (your Ventoy stick) not from either the new Fedora nor the old one.
In your other thread, I don’t see any explanation of your sda1. Is that the Windows EFI partition or some other Windows thing?
If you have as bad luck with Anaconda as I seem to, there may be a bit more cleanup after the install. But if you have the basic idea of where you are trying to get to, none of that is hard.
I didn’t actually backup the whole /home directory, only subdirectories I found useful. I wanted to save data because it’s easier than just copy pasting it but I’ll check if everything is backed up well and probably format everything.
First of all do i format just / or /boot/efi too?
I might actually need /swap because I only have 8GBs of RAM, or should i be fine with zram too? I don’t think I’m doing anything heavy on memory, perhaps a couple of games here in there but not that much.
I’m not sure what dev/sda1 is… I’ve been using linux for quite some time but when i was installing this I was heavily guided and just installed it as told as i wasn’t that experienced.
I don’t know if I should just leave all of this be as it is and just reinstall it as it used to be. It’s getting a little bit complicated.
You don’t format your current /. You either shrink it, so it can temporarily exist at the same time as the new install, or you delete it, so the space it occupied becomes unpartitioned space (which will be converted into the new /boot and btrf by the install).
Any partitioning tool could be used to delete it. I know gparted can be used for the bottom up shrink (so it ends up occupying the end of the area it now occupies). I expect other partitioning tools also can do that, but I’m not sure. Remember, to do anything to it with a partitioning tool, you need to be booted in some other copy of Linux (such as the one on your Ventoy stick).
You don’t do anything to /boot/efi prior to doing the install. Maybe it will require some cleanup after the install. Listing its contents after the the install is a good idea for finding out if there is much there that doesn’t belong.
I would guess that games and online activities are light enough for 8GB and also have a low fraction of their memory use in what Linux calls “anonymous” memory (meaning it has no base location in the file system). Only anonymous memory uses swap. So I expect you don’t need any swap. I’m mainly guessing about game use of anonymous memory. Game engine design can vary a lot. If a games uses so much anonymous memory that it needs swap by itself, it would run too slowly anyway.
If you have multiple programs that each use a lot of anonymous memory, but each not too much to run well in 8GB and you leave one or more of them idle in the background while actively using another (rather than closing a game, etc. when not actively using it), then swap can make a big difference.
Photo editing and especially video editing are common user tasks that use a lot of anonymous memory. If you expect to leave a photo editing session running idle in the background while doing other tasks, absolutely allocate some real swap space.
If you aren’t allocating any real swap space, there is no reason to disable the Fedora default of zram. It won’t do any harm if you don’t really need swap. It will help if you need a tiny amount of swap. Its presence if things go wrong due to lack of swap can make it easier to diagnose that the problem is lack of swap. My best guess is that the usage you somewhat described doesn’t need swap.
