View previous topic :: View next topic |
Author |
Message |
tmcca Tux's lil' helper
Joined: 24 May 2019 Posts: 120
|
Posted: Thu Nov 19, 2020 2:44 am Post subject: Resizing root? |
|
|
What is the best way to resize root without losing data?
I currently have 83% on my root partition. |
|
Back to top |
|
|
RayDude Advocate
Joined: 29 May 2004 Posts: 2062 Location: San Jose, CA
|
Posted: Thu Nov 19, 2020 3:05 am Post subject: Re: Resizing root? |
|
|
tmcca wrote: | What is the best way to resize root without losing data?
I currently have 83% on my root partition. |
More information please.
How many partitions do you have?
If the disk is full, then you'll need another drive... _________________ Some day there will only be free software. |
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21633
|
Posted: Thu Nov 19, 2020 3:54 am Post subject: |
|
|
Please post the output of df -Th, the partition layout requested above, and, if applicable, any LVM or RAID layer information.
In the abstract, the process would be to resize the block device that contains the root filesystem, then grow the root filesystem to fill the resulting block device. The specifics of how to do this vary by filesystem and by what block layers sit beneath it, which is why we need more information. |
|
Back to top |
|
|
figueroa Advocate
Joined: 14 Aug 2005 Posts: 2963 Location: Edge of marsh USA
|
Posted: Thu Nov 19, 2020 4:11 am Post subject: |
|
|
How big is 83%? How much space is left in your 17%? Can some of the things in your current root be offloaded to another partition/drive? i.e. distfiles, personal files, junk, videos
The best and safest option is to restore your root to a new, larger partition from a current backup. If you don't have a current, tested, restorable backup you have bigger problems than being 83% full. And, if you don't have such a backup, you shouldn't consider trying to grow your root partition. Backups are essential to prevent future alligator tears.
Generic solution: https://gparted.org/ _________________ Andy Figueroa
hp pavilion hpe h8-1260t/2AB5; spinning rust x3
i7-2600 @ 3.40GHz; 16 gb; Radeon HD 7570
amd64/23.0/split-usr/desktop (stable), OpenRC, -systemd -pulseaudio -uefi |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54237 Location: 56N 3W
|
Posted: Thu Nov 19, 2020 10:25 am Post subject: |
|
|
tmcca,
The best way to resize root is not to do it at all.
Your install can be scattered over as many drives and partitions as you like.
They don't even need to all be in the same PC.
Pay close attention to my sig too. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
tmcca Tux's lil' helper
Joined: 24 May 2019 Posts: 120
|
Posted: Fri Nov 20, 2020 12:44 am Post subject: |
|
|
Code: | fdisk -l
Disk /dev/sda: 119.24 GiB, 128035676160 bytes, 250069680 sectors
Disk model: SAMSUNG SSD 830
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 74BEDD7F-48C9-42C1-A4DB-DCAA1753A232
Device Start End Sectors Size Type
/dev/sda1 2048 262143 260096 127M EFI System
/dev/sda2 262144 63487999 63225856 30.1G Linux filesystem
/dev/sda3 63488000 250067631 186579632 89G Linux filesystem
Disk /dev/sdb: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: WDC WD10EZEX-08W
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: E681F51A-DC9A-4724-9566-B1477DBF6C48
Device Start End Sectors Size Type
/dev/sdb1 2048 1953523711 1953521664 931.5G Linux filesystem
|
Code: | df -Th
Filesystem Type Size Used Avail Use% Mounted on
/dev/root ext4 30G 24G 4.9G 83% /
devtmpfs devtmpfs 10M 0 10M 0% /dev
tmpfs tmpfs 1.6G 996K 1.6G 1% /run
cgroup_root tmpfs 10M 0 10M 0% /sys/fs/cgroup
shm tmpfs 7.9G 283M 7.6G 4% /dev/shm
/dev/sda3 ext4 88G 1.3G 82G 2% /srv
/dev/sdb1 ext4 917G 1.5G 869G 1% /home
tmpfs tmpfs 12G 0 12G 0% /var/tmp/portage
tmpfs tmpfs 1.6G 16K 1.6G 1% /run/user/1000
/dev/sda1 vfat 126M 19M 107M 16% /boot
|
|
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21633
|
Posted: Fri Nov 20, 2020 2:29 am Post subject: |
|
|
Your current partition layout has no free space between the end of the partition holding the root filesystem and the beginning of the partition holding the /srv filesystem. You did not use LVM, so you cannot grow the device holding the root filesystem without overwriting the head of the device that holds the srv filesystem. Such an action would destroy the srv filesystem and lose all data on it. If you have a place you can temporarily relocate the contents of the srv filesystem, this might be acceptable. Otherwise, you will need to pursue the route Neddy suggested earlier: add new filesystems to host some of the content that is currently in the root filesystem, thereby allowing you to free those files on the root filesystem without losing their contents. How would you like to proceed?- Give up
- Destructively relocate srv
- Move files off root onto some other filesystem.
|
|
Back to top |
|
|
steve_v Guru
Joined: 20 Jun 2004 Posts: 388 Location: New Zealand
|
Posted: Fri Nov 20, 2020 4:34 am Post subject: |
|
|
Gparted from a liveCD can resize and/or move partitions, assuming they are among the filesystems it supports and said filesystem supports resizing. ext4 should not be a problem.
Personally I like PartedMagic, but this livecd will also work (and is a free download).
Be aware this is a slow and potentially destructive operation, make absolutely sure you have a working backup before attempting it.
You will want to shrink the /srv partition moving it to the right, then grow the / partition into the free space. It will be slow as the data on /srv must be physically relocated. Interrupting the process will almost certainly trash your filesystem(s), consider yourself warned.
Whether this is any faster than simply backing up /srv and restoring it later is debatable, but as you will be backing up your data in any case I see no reason not to try it. It's easy, it's GUI, and IME it's pretty painless. _________________ Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy. |
|
Back to top |
|
|
dmpogo Advocate
Joined: 02 Sep 2004 Posts: 3267 Location: Canada
|
Posted: Fri Nov 20, 2020 7:19 am Post subject: |
|
|
Hu wrote: | Your current partition layout has no free space between the end of the partition holding the root filesystem and the beginning of the partition holding the /srv filesystem. You did not use LVM, so you cannot grow the device holding the root filesystem without overwriting the head of the device that holds the srv filesystem. Such an action would destroy the srv filesystem and lose all data on it. If you have a place you can temporarily relocate the contents of the srv filesystem, this might be acceptable. Otherwise, you will need to pursue the route Neddy suggested earlier: add new filesystems to host some of the content that is currently in the root filesystem, thereby allowing you to free those files on the root filesystem without losing their contents. How would you like to proceed?- Give up
- Destructively relocate srv
- Move files off root onto some other filesystem.
|
srv is just over 1G full, it is easy to move the content to /home temporarily. Just move, delete /srv partition, create new one in its space that starts later, grow root partition, grow root filesystem, copy the cotent of /srv back.
Would not trust any GUI to do it, easy with fdisk, but this is just me.
by grow root partition, in fdisk you will have to delete it, and then create a new one starting at exactly the same block, but ending later. |
|
Back to top |
|
|
Jaglover Watchman
Joined: 29 May 2005 Posts: 8291 Location: Saint Amant, Acadiana
|
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54237 Location: 56N 3W
|
Posted: Fri Nov 20, 2020 9:01 am Post subject: |
|
|
I was about to offer shrink /srv and make a new partition in the free space for distfiles and possibly packages.
I like Jaglovers solution better though. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
figueroa Advocate
Joined: 14 Aug 2005 Posts: 2963 Location: Edge of marsh USA
|
Posted: Fri Nov 20, 2020 3:32 pm Post subject: |
|
|
How is the user's /srv partition being used? Why does it exist? I've never had one, never missed it.
How does the user backup his system/personal files? _________________ Andy Figueroa
hp pavilion hpe h8-1260t/2AB5; spinning rust x3
i7-2600 @ 3.40GHz; 16 gb; Radeon HD 7570
amd64/23.0/split-usr/desktop (stable), OpenRC, -systemd -pulseaudio -uefi |
|
Back to top |
|
|
eccerr0r Watchman
Joined: 01 Jul 2004 Posts: 9679 Location: almost Mile High in the USA
|
Posted: Fri Nov 20, 2020 3:54 pm Post subject: |
|
|
As of writing this message, I found that 20GB disk/partition you can still get a semi-usable full GUI Gentoo install if it's x86 and keep things cleaned up. Little to no space to store your mpegs however. My x86 machines with firefox (not firefox-bin) and xfce4 is still working with a 20GB partition. Running size is 10GB, and rest is for tmp space to build rust and firefox. I don't know how long this is going to remain true. It's already very tight when doing updates - juggling free space is tricky.
For 64-bit x86_64, it's no longer enough, binary and file sizes are significantly larger than x86 that there won't be enough tmp space to build rust/firefox.
But I would give a thumbs up for the gparted livecd, I used it several times to nondestructively resize partitions. I'd be very hesitant on using it on SSDs, you will lose a life across your media, not too big an issue with SLC/MLC but is a concern with TLC. However, resize with impunity on rust spinners.
And yes: read Neddy's signature very carefully.
BTW there needs to be a poll on what people call their directories for extra partitions. Seems a lot of people call it /srv, or at least it's not the first time I saw someone call it /srv... Perhaps this is standard for some other distributions? Dunno. _________________ Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54237 Location: 56N 3W
|
Posted: Fri Nov 20, 2020 7:43 pm Post subject: |
|
|
The discussion on naming extra directories went that way ---> _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
tmcca Tux's lil' helper
Joined: 24 May 2019 Posts: 120
|
Posted: Fri Nov 20, 2020 10:13 pm Post subject: |
|
|
after using eclean-dist it's now 62%
I think this be ok now. Thanks |
|
Back to top |
|
|
Jaglover Watchman
Joined: 29 May 2005 Posts: 8291 Location: Saint Amant, Acadiana
|
Posted: Fri Nov 20, 2020 10:54 pm Post subject: |
|
|
tmcca wrote: | after using eclean-dist it's now 62%
I think this be ok now. Thanks |
I have it as monthly cronjob, it mails me with report, usually about 4 GB every month is cleaned out. This server serves distfiles to 5 computers, if yours is single then it probably will be less than that.
Code: | server ~ # grep eclean /etc/crontab
@monthly root /usr/bin/eclean-dist |
_________________ My Gentoo installation notes.
Please learn how to denote units correctly! |
|
Back to top |
|
|
eccerr0r Watchman
Joined: 01 Jul 2004 Posts: 9679 Location: almost Mile High in the USA
|
Posted: Sat Nov 21, 2020 3:25 am Post subject: |
|
|
If you have kernel sourcecode installed, make sure you clean up older versions in /usr/src too --
$ eselect kernel list
Unmerge the extra kernels and clean up the /usr/src/... directory.
In general you should also try emerge --pretend --depclean and remove extra packages you don't need like extra old compilers, etc.
Lots of little sneaky stuff adds up and fills up your disk... _________________ Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
Back to top |
|
|
RayDude Advocate
Joined: 29 May 2004 Posts: 2062 Location: San Jose, CA
|
Posted: Sat Nov 21, 2020 4:16 am Post subject: |
|
|
Depending on how you build your kernels, you can save space by deleting the unused kernel modules in /lib/modules. _________________ Some day there will only be free software. |
|
Back to top |
|
|
szatox Advocate
Joined: 27 Aug 2013 Posts: 3136
|
Posted: Sat Nov 21, 2020 8:48 pm Post subject: |
|
|
Quote: | Unmerge the extra kernels and clean up the /usr/src/... directory. | The biggest impact here comes from 'make clean' after building your kernel.
Sources take around 1GB.
The build residue (object files , I guess) is like 6 GB. Madness! |
|
Back to top |
|
|
figueroa Advocate
Joined: 14 Aug 2005 Posts: 2963 Location: Edge of marsh USA
|
Posted: Sat Nov 21, 2020 9:02 pm Post subject: |
|
|
I usually keep three kernel in /usr/src and /boot. I don't buy 6 GB.
Code: | $ du -h --max-depth=0 /usr/src/linux-4.19.152-gentoo
1.3G /usr/src/linux-4.19.152-gentoo |
Used to be 1.2 GB with the 4.9 series.
Modules in /lib/modules are negligible is size:
Code: | $ du -h --max-depth=0 /lib/modules/4.19.152-gentoo
5.3M /lib/modules/4.19.152-gentoo |
_________________ Andy Figueroa
hp pavilion hpe h8-1260t/2AB5; spinning rust x3
i7-2600 @ 3.40GHz; 16 gb; Radeon HD 7570
amd64/23.0/split-usr/desktop (stable), OpenRC, -systemd -pulseaudio -uefi |
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21633
|
Posted: Sat Nov 21, 2020 9:07 pm Post subject: |
|
|
I build the objects in a separate directory structure to keep the sources clean. Sizes vary by system, but my biggest is ~850M for the object directory. 6GB seems like either debug information was built into all the objects, or the kernel was built with huge numbers of optional features (like allyesconfig). |
|
Back to top |
|
|
Anon-E-moose Watchman
Joined: 23 May 2008 Posts: 6098 Location: Dallas area
|
Posted: Sat Nov 21, 2020 9:33 pm Post subject: |
|
|
Hu wrote: | I build the objects in a separate directory structure to keep the sources clean. |
Yep, I run make menuconfig or whatever, set all the options that I want/need and copy the sources to a /tmp/subdir (tmp is a tmpfs).
I don't mind the little extra time it takes to compile all the sources, as I know everything is being built at the same time.
Besides running -j14 and keeping it all in memory (64G) doesn't take that long. _________________ PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
Back to top |
|
|
szatox Advocate
Joined: 27 Aug 2013 Posts: 3136
|
Posted: Sat Nov 21, 2020 9:38 pm Post subject: |
|
|
That particular 6 GB was for gentoo-sources-5 with a config from gentoo-sources-4 I created a long, long time ago for my virtual machines (qemu and vmware). I had more time back then, and now I am basically always in a hurry, so it sounded like a good idea.
Code: | # cat /etc/kernels/kernel-config-x86_64-4.19.86-gentoo | grep '=y' | wc -l
1427
# cat /etc/kernels/kernel-config-x86_64-4.19.86-gentoo | grep '=m' | wc -l
990
# cat /etc/kernels/kernel-config-5.4.72-gentoo-x86_64 | grep '=y' | wc -l
1462
# cat /etc/kernels/kernel-config-5.4.72-gentoo-x86_64 | grep '=m' | wc -l
980
# ls -lh /boot
-rw-r--r-- 1 root root 6,2M 2019-12-13 kernel-genkernel-x86_64-4.19.86-gentoo
-rw-r--r-- 1 root root 6,6M 11-20 21:56 vmlinuz-5.4.72-gentoo-x86_64
~~/ snip /~~
|
built with genkernel.
And yes, it was literally 6GB of garbage. Can't tell how much exactly, or inspect it anymore, because I wiped immediately after installing the new kernel image... Can't afford to keep this amount of bloat on a vps with 20GB disk. |
|
Back to top |
|
|
|