Instead of storing 40GB partition fixed to that amount, that partition can dynamically use the space
Instead of storing 40GB partition fixed to that amount, that partition can dynamically use the space up to 40GB
Auh so lvm applies to the whole drive or the root partition?
Fbut it is the bad explanation of LVM
Gyeah we got plenty, the cosmic image is pretty small
SThe way it's explained is wrong, lvm doesnt have a set partition structure like were used to, what it does is basically take the whole disk and then rather than split it into partitions (with hard limits) it uses a volume that can change dynamically but only shows what's actually in use. So say you have one disk of 40gb but tell lvm to use three volumes it will adjust the volumes based on the usage. That's about the best i can explain it, the problem at the moment is the /boot can't use LVM as grub can't read from there.
Athe article clearly states 20gb storage pool
Arest is btrfs
Aits clearly stated
Gas an aside, is using
latestprev-ref: "${{ env.IMAGE_REGISTRY }}/cosmic-${{ matrix.flavor }}:latest"Gi'm not exactly sure how to get the previous tag exactly
Aonly one way to know
Arun it and see if it pulls the previous tag
Alatest dunno depends on your latest tag
Gdoes it work for F39 versions?
Aif you push to latest it will work
Ayes should work for f39
Gok yeah I don't think F39 pushes to latest
Sso basically you always have a /boot partition and then the rest managed with LVM which is where things like bootc, systemd-boot and OCI come into play as they don't have that limit. It's all rather confusing when you get to the explaining it in text lol
Afor f39 you can use the tag of f39
Fmaybe they just reduced the root partition from 40gb to 20gb literally, thinking that 1 image won't take more than 10GB?
Athats not what the blog says but thats the only way it works
Goh I can just use
matrix.versionAyup
FLVM doesn't have any relation to this in this case
SHaven't read the blog tbh as Vanilla really doesn't interest me I'm happy where I am with bluefin/kinoite no reason for me to change lol
Galr I'll squash everything and move it out of draft
Ai also think that
Amaybe it breaks in a few months once their image hits 10GB
Splus i find A/B root really offputting, it's worse than trusting BTRFS snapshots like Opensuse uses
Abazzite used to be 12gb so they have a way to go
Athey're probably like 6-7gb
SI do wonder at times if I should save some money and get a multidisk server again to try things like this with LVMRaid/Linuxmd and see how long it takes to totally tear itself to bits lol
FDon't like dosubot closing issues just because they are not active for some time
Most of those automatically closed issues are still related to the project
Most of those automatically closed issues are still related to the project
SSurely you can turn that off though cant you?
SOr is this another "feature not a bug" thing lol
FUblue folks can turn it off, but they turned it on in the 1st place lol
FIt's to manage issues which are low priority & close them
Soh right... erm don't know what to say then
FI just prefer to tag them automatically as low-priority instead & close unrelated issues manually
SWell that would seem a better way of doing it, but I guess with all the other work they already do it may get a bit time consuming?
Fprobably
Jremove the stale tag
FCan do that only for issues which I created
Fnot for all other issues
Jwhich ones do you need reopened?
Fsome issues in main related to useful packages, like python3-validity
Fbut you probably manage issues differently than I do
Fso no strict need
JI mean, it's been sitting for over 90 days and no one PRed it in?
Fno.
Joh it's not in a repo
