Install on a small disk auto partition #1159
Comments
|
The swap partition size was recently changed to reflect the RAM size. The more RAM the bigger swap. And the snapshots are enabled by default. I do not know whether with all that features enabled 20GB disk is enough for a TW system. Manual solutions:
I'm not sure if we can solve that somehow automatically. Each solution has some drawback and we do not know what the user would prefer. @ancorgs ? |
thats what i did tried to do another VM with 40GB disk size on a regular HDD (where i have more space them on my NVME disk today) and that seems to work out better |
yep worked better with more disk space |
|
There are soooo many topics we could open based on this issue description. 😉 I will try to not go too off-topic... but I can make no promises. The initial proposalIt caught my eyes that you used the expression "auto partitioner", which already reveals some expectations. YaST, as an installer, tries hard to always find a way to install into the system if the user just go "next, next, next" without even reading. That's what I call the "chicken installation" since even a chicken just pecking on the "enter" key would make it. That implies YaST, in presence of a small disk, will automagically and transparently disable "enlarge swap to ram", "propose separate /home", "enable Btrfs snapshots" and whatever needs to be disabled in order to make sure the user just needs to click on "install". For the storage proposal at Agama, we wanted to rethink that approach a bit. Nothing is written in stone yet, but you can check the About the Initial Proposal section of the document describing the new storage user interface. In short, if we deviate from the standard settings, we want that to be a conscious decision by the user. So Agama just tries to setup storage once - in the first disk and with the default settings. If that's not what the user wants, then the user has to visit the storage page and tell Agama what to do. Standard settings and the size of swapThe other big topic here is why Agama tries to set a big swap by default when installing Tumbleweed. In that regard, a lot was written already at the "About the Approach" section of the original pull request that introduced the setting for Tumbleweed. In short, Agama has a feature to specify automatic sizes for the file-systems and we want to rely on that feature in order to cover scenarios like the classical YaST "Enlarge to RAM Size for Suspend". We may still need to refine the current solution in several ways. For example, making it possible for the product to specify that a given file-system should only observe the RAM size in certain situations (eg. ignore that in case of a virtual machine since suspending is usually not relevant there). But we didn't want to start with a completely Ad Hoc implementation for that "swap for suspend" thingie since the topic is WAY more controversial than it looks at first time. |
As Agama has progressed, the original idea of a hyper-minimalist interface has completely vanished. We have moved far away from the first _SPA interactive interface_. The installation summary has lost all its value and it is now a sort of navigation menu or index. Furthermore, it is impossible to start with a valid configuration straight away due to several reasons, such as * The creation of a user it's mandatory since it cannot be relegated to the first boot. * The storage proposal algorithm [does not perform as many attempts](#1159 (comment)) as it used to do in YaST. Last but not least, it is way weird landing in a page with a big, green, and enabled <kbd>Install</kbd> button that will prompt an error when clicked before any other user interaction. There is a [proposal to improve](#778) that first initial screen, but having in mind the Agama development progression I believe that the current approach does not scale. Regrettably, looks like a dead end. With this in mind, I have been thinking a bit about an alternative that I had on my to-do list for the future, which consisted of converting the summary screen into a panel on the left and loading the content of each section to the right (which would overlap the first on small devices). It would solve two problems in one shot by stop forcing the user to navigate back and forth to change between sections and stop wasting available space on large screens. The key was to make better use of react-router and embrace [nested routes](https://reactrouter.com/en/main/start/overview#nested-routes) as designed instead of fighting against them. Something perfectly doable. However, as soon as I started writing some code to play with, I realized that also embracing more heavily PatternFly would be enough to start making it possible. Moreover, I concluded that it could even help to solve many of the problems we currently have with the interface at many levels. So I got to work to carry out a small proof of concept with, among others, following ideas in mind, * Use PatternFly as much as possible to the point of looking familiar with Cockpit UI but keeping some bits of Agama's identity (like typography and colors, the absence of wizard, to allow the user to move as freely as possible, etc) * Reduce the number of components developed by us and help to improve the existing ecosystem instead. After all, at this moment it is not realistic to think that we can also develop and maintain a design and components system (although I would like to do so, of course :P). * Sensibly embrace the router: use a [data router](https://reactrouter.com/en/main/routers/picking-a-router#using-v64-data-apis), [nested routes](https://reactrouter.com/en/main/start/overview#nested-routes), [outlet context](https://reactrouter.com/en/main/hooks/use-outlet-context), etc. * Use [FormData API](https://developer.mozilla.org/en-US/docs/Web/API/FormData) when working with forms and/or evaluate the use of react-router [Form](https://reactrouter.com/en/main/components/form) * Keep an eye on the [next React version](https://react.dev/blog/2024/04/25/react-19). * Keep in mind that the number of internal states of some components can be reduced by relying in the [URL as State Management](https://www.youtube.com/watch?v=VenLRGHx3D4&t=602s) when possible. Indeed, it is A LOT of work to do, but I firmly believe it worth. Once we finish the migration, we should be able to move forward more efficiently and, hopefully, with less friction when taking UI decisions. Don't get me wrong, we will still have work to do, decisions to make, and specially things to improve, etc. We will even keep changing our minds from time to time based on learned lessons or feedback gathered. But with a bit of luck, we will have more time for these things. **PLEASE REMEMBER** there will be a lot of details to define and many others to polish after this PR gets merge, but in general terms this new, streamlined layout gives us more room for placing almost everything you will miss at first sight. **Little by little, please.** Bonus: PatternFly already provides style guides, and we can build our own on top of them since it will be inevitable that, at certain points and due to the nature of Agama and our view/knowledge, we will take slightly different decisions/paths. ## Related pull requests - #1298 - #1299 - #1300 - #1301 - #1302 - #1303 - #1304 - #1305 - #1306 - #1307 - #1308 - #1309 - #1310 - #1312 - #1313 - #1315 - #1316 - #1317 - #1319 - #1320 - #1321 - #1322 - #1323 - #1324 - #1325 - #1326 - #1328
Hey!
The auto partitioner does not really work that well with just a 20GB disk in a gnome-boxes VM as i have to make the swap 8GB instead of 5GB and the main drive 10GB instead of 15GB
What is the recommended size on the disk to install openSUSE Tumbleweed with Agama now, or can the auto partitioner work better with smaller disks?
The text was updated successfully, but these errors were encountered: