Hello, i want to shrink the big partition Nr 6, as small as possible without touching the used space.

Hmmh, that is very sad. I never touched something, only installed with the preferred options from the installer... Fyi: I want to make space for a second linux Installation, not an additional partition. Does it mean that i have erase the whole disk, because it is btrfs?

Thanks you for the info. Fyi: my laptop use UEFI. ---------------------------------------- Von: Roger Heflin <rogerheflin(a)gmail.com&gt; An: Community support for Fedora users <users(a)lists.fedoraproject.org&gt; Datum: 27.07.2023 12:48:01 Betreff: Re: Need help; safe way to shrink my fedora38 installation disk > I got the partition that was last wrong. > > You would have to know the sizes and used of the various mount points > and have to know how/if btrfs has enough free and how to re-arrange > that free space to be at the end so you can resize. > > In general adding a 2nd installation after the fact is very > complicated.  Even adding the 2nd install when you left free space is > not the most straightforward as the installer program has to do > everything right, and the installer person has to also not pick the > wrong options and damage the 1st install. > > The few times I do a 2nd install the 2nd install is on its own boot > device (usually a usb disk), and I tend to not run 2 installs for very > long.  I have done 3 install with the same grub setup (legacy boot) > but that setup was designed to have 3 installs and the grub merging of > the 3 /boots into one set of boot options had to be done entirely > manually as each installer at the time wanted to do its own grub.cfg > and not share.   That all might be better using UEFI since UEFI can > work as the switch between the 3 /boots. > > On Thu, Jul 27, 2023 at 1:27 AM Karlderletzte > <karlderletzte(a)holnishaus.de&gt; wrote: >> >> Hmmh, that is very sad. I never touched something, only installed with >> the preferred options from the installer... >> Fyi: >> I want to make space for a second linux Installation, not an >> additional >> partition. >> >> Does it mean that i have erase the whole disk, because it is btrfs? >> _______________________________________________ >> users mailing list -- users(a)lists.fedoraproject.org >> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org >> 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/users@lists.fedoraproject.org >> Do not reply to spam, report it: >> https://pagure.io/fedora-infrastructure/new_issue > _______________________________________________ > users mailing list -- users(a)lists.fedoraproject.org > To unsubscribe send an email to users-leave(a)lists.fedoraproject.org > 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/users@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue

Adding to what George says. If doing a 2nd install, have a plan of what to do if it all fails badly and you end up with no working installs (there are posts all of the time for failures, not sure how many dual installs work as people only post when it goes wrong). There are a few places it can go wrong during the install, and if it goes wrong there are a very limited number of experts that can sort out what is salvageable or not. Make sure to have a tested (to boot) livecd (not a installer iso) such that you can boot up and examine the disk. On Thu, Jul 27, 2023 at 5:28 AM George N. White III <gnwiii(a)gmail.com&gt; wrote: > > On Wed, Jul 26, 2023 at 2:22 PM KarlderLetzte <karlderletzte(a)holnishaus.de&gt; wrote: >> >> hello everybody, >> >> i need some space on disk for a second installation. >> therefore i want to safely shrink my fedora installation. >> >> here is the disk layout: >> [...] >> >> my question: >> is there a safe way to shrink? >> > The only safe way to shrink is to have a backup. Shrink is I/O intensive and has > a much higher probability of revealing any weaknesses in hardware or software > than normal operations where weaknesses may remain undiscovered for a long > time. Also note that running a filesystem with too little free space slows down > file operations and also increases the probability that weaknesses will be revealed. > > See: <https://btrfs.readthedocs.io/en/latest/btrfs-filesystem.html#man-filesyst... > > -- > George N. White III > > _______________________________________________ > users mailing list -- users(a)lists.fedoraproject.org > To unsubscribe send an email to users-leave(a)lists.fedoraproject.org > 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/users@lists.fedoraproject.org > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

Am Donnerstag, dem 27.07.2023 um 08:27 -0700 schrieb stan via users: here is the output of df and btrfs filesystem. i resized the filesystem to a desired value. my ssd has 500GB capacity. it is the nvme0n1..6 sudo btrfs filesystem sync / sudo btrfs filesystem df / Data, single: total=195.01GiB, used=154.75GiB System, single: total=4.00MiB, used=48.00KiB Metadata, single: total=5.01GiB, used=2.21GiB GlobalReserve, single: total=301.27MiB, used=0.00B df Dateisystem 1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf devtmpfs 4096 0 4096 0% /dev tmpfs 7850952 0 7850952 0% /dev/shm tmpfs 3140384 1964 3138420 1% /run /dev/nvme0n1p6 282561536 164889684 115040620 59% / /dev/nvme0n1p6 282561536 164889684 115040620 59% /home tmpfs 7850952 12 7850940 1% /tmp /dev/nvme0n1p5 996780 355908 572060 39% /boot /dev/nvme0n1p4 613184 17796 595388 3% /boot/efi tmpfs 1570188 192 1569996 1% /run/user/1000 /dev/sda1 495312 5920 412352 2% /run/media/held/40f020fb-33eb-406b-a3b0-7f7ba297557b

Hello everybody, thank you all for the information. Unfortunately i do not fully understand, how to manage the shrinking. For now, i will install the new linux on a external disc, boot and then copy content from the f38 installation. the old way, long and work intensive (finding the correct partition size, choose the filesystem typ and so on.). i think, it is annoying, that btrfs with f38 is so hard to use for this task. my new filesystem will not be btfrs. Regards Karl Am Freitag, dem 28.07.2023 um 06:40 -0700 schrieb stan via users:

Am Sonntag, dem 30.07.2023 um 11:46 -0300 schrieb George N. White III: Yes you are right. I could shrink the filesystem. My problem starts, because gparted complains a warning, that it is possible not able to boot. therefore i cancel the operation and read a bit deeper.

On Mon, Jul 31, 2023 at 5:12 PM richard emberson <emberson.rich(a)gmail.com&gt; wrote: An equivalent for yum-complete-transaction was requested but never implemented. https://bugzilla.redhat.com/show_bug.cgi?id=1091702 There's probably a way to use `dnf repoquery` based commands to list the problem packages and them remove them. Have you tried doing an update with --allowerasing? Thanks, Richard

A new issue is best started in a separate thread instead of hijacking someone else's thread, as you did. It keeps threads neat and tidy too. On Mon, 31 Jul 2023 15:11:06 -0700 richard emberson <emberson.rich(a)gmail.com&gt; wrote: At what stage was it interrupted? If it was during update it isn't as problematic as if it is during cleanup, I think, when a package could be left in a partially finished state. I think it was better not to run dnf clean all. You should have just run a repeat of dnf update because the system would have been in a sane state. By running clean all, you wiped all metadata. I think the errors are because there is some cruft left over from the update. Try using dnf distrosync If that doesn't work, you can try dnf -x glib2 update to see if it will fix all the other problems and ignore glib2 for now. Usually, the problem that glib2 is reporting is a packaging error, but I suspect it isn't in this case because of the update interrupt. Once everything else is fixed, you might have to manually remove the glib2 packages in conflict because they are cruft left over from the interrupted update.