View previous topic :: View next topic |
Author |
Message |
LIsLinuxIsSogood Veteran
Joined: 13 Feb 2016 Posts: 1179
|
Posted: Sat Jan 20, 2018 4:16 am Post subject: Downsizing / partition (SOLVED) |
|
|
Quick question, I am working on the production laptop that I can't screw up for any reason
What I wanted to do is reduce the size of the partition sda4 which is currently where everything is mapped (other than some semi-important but really unimportant files in /boot are).
I'm currently booted in via livecd, but because I've never actually done this before I wanted to see if there was some ideal way of checking to make sure that data isn't going to be overwritten...whatever that means?
I'm comfortable using the different tools for it, CLI tools gdisk or fdisk or any others that could do the job. Just basically wanting to create on this hd enough space to do a bit more stuff, including maybe separating /home to its own partition.
How can I check to make sure the current disk space used isn't going further on the disk than I might expect? (I guess as an alternative, if it makes sense to do this I will backup the system now, which also allows for a more "compact" restore if that is another options and I need help please, thanks!)
Last edited by LIsLinuxIsSogood on Tue Jan 23, 2018 6:31 am; edited 1 time in total |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54099 Location: 56N 3W
|
Posted: Sat Jan 20, 2018 10:30 am Post subject: |
|
|
LIsLinuxIsSogood,
This is a three step process.
1. Make a backup and validate it, its risky.
2. Shrink the filesystem. Not all filesystems support that. extX is OK.
3. Shrink the partition so its no smaller than the filesystem.
If you mess up and have a partition that's smaller that the filesystem, mount will spot it and refuse to mount the filesystem.
Its mostly harmless as lon as you do not make new partitions/filesystem using the 'not empty' space.
There may be some one step tools but I've never tried them.
If you mess up, there is step 4
4. Restore from the backup you made in step 1. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
cboldt Veteran
Joined: 24 Aug 2005 Posts: 1046
|
Posted: Sat Jan 20, 2018 2:43 pm Post subject: |
|
|
I've done this using sysrescue CD, then invoking Xwindows from there (startx), then running gparted. Makes the process fairly simple. |
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21497
|
Posted: Sat Jan 20, 2018 5:53 pm Post subject: |
|
|
As a corollary to the very good advice to prepare a backup, you should also collect a backup of the partition table before you resize anything. In the event of minor mistakes, you may be able to use this backup to revert to your starting state far more quickly and easily than by restoring the full system backup. Write the partition table backup to storage you can keep until you are completely satisfied that everything worked. This may mean a tmpfs if you are confident in wall power. It may mean a USB stick, or a filesystem on a separate physical drive that will not be touched at all by this resize operation. (Since this is a laptop, you probably don't have a spare drive, but the principle applies elsewhere.)
Do not place it on the drive you plan to modify. You may need to unmount the filesystems from that drive to get the kernel to reread the partition table. If you reread the table, then find that you broke it, you would be unable to access the filesystem on which your partition table backup is kept. Hence, separate drive, tmpfs, separate computer, etc.
Ideally, your partition table backup should be a machine readable form that can be used to exactly restore the partitions without you entering any sizes or offsets. For MBR partitions, sfdisk can do this with the option --dump. See man sfdisk for full instructions. Beware that the short name of --dump is -d, but that the GPT aware sgdisk considers -d to be short for --delete. According to the manual, sgdisk has --backup and --load-backup for saving and restoring the table.
For shrinking the filesystem, if it is an extX family, and you do not mind some wasted I/O, there is an option for resize2fs to tell it to shrink the filesystem to the minimum size that does not lose data. The filesystem will then be 100% full and aligned to the head of the block device that contains it, allowing you to shrink the device to the greatest degree without leaving live data outside the shrunken device. Beware that even with this approach, it is still your responsibility to ensure Neddy's point 3 constraint is satisfied. The tools are perfectly willing to let you shrink the device so far that it breaks the filesystem. Generally, my approach is:- Verify the filesystem backup.
- Unmount the target filesystem.
- Fsck the target filesystem.
- Pick a temporary size for the filesystem. This may mean telling resize2fs to minimize the filesystem or it may mean picking a size that will fit in the partition. Usually, I undersize the filesystem by a bit to allow some slop. For example, if I wanted to reduce to 12G, and I had a usage of only 5G, I might resize the filesystem down to 11.8G.
- Capture a partition table backup. This can be done concurrently with the resize.
- Resize the partition to my target of 12G
- Verify that the partition table has been reread.
- Fsck the filesystem again to check that fsck does not believe the filesystem is outside its device.
- Read-only mount the filesystem. Verify that it mounts and looks good.
- Unmount the filesystem.
- Tell resize2fs to grow it to fit all available space. This will grow it from 11.8G up to 12G. This should be very fast, since it only changes control structures. It does not relocate data into the newly added space.
- Done.
|
|
Back to top |
|
|
Ant P. Watchman
Joined: 18 Apr 2009 Posts: 6920
|
Posted: Sat Jan 20, 2018 7:01 pm Post subject: |
|
|
Be warned: if your end goal is to add a sda5, and your sda1-4 are MBR primary partitions, it won't work. |
|
Back to top |
|
|
LIsLinuxIsSogood Veteran
Joined: 13 Feb 2016 Posts: 1179
|
Posted: Tue Jan 23, 2018 6:31 am Post subject: |
|
|
Thanks this was very cool to learn about the cli tools that interface with gdisk and fdisk, since I also usually attempted avoiding that and opting for a more visual tool like gparted myself. But being aware of this additional option to use commands to control those functions for GPT or GUID partition that is something I will have to toy with here.
Too bad though i guess that i didn't see it in time to be able to take Hu's advice to shrink the filesystem first, so I ended up with I guess a bit longer process or command by just going about things the basic way and shrinking the partition using gparted. Next time I have to do this I will definitely think to use resize2fs tool, and that seems like a good thing to maybe experiment with on my new partition which remains empty at this point.
Thanks for the advice and marking as SOLVED!
FYI, In case it helps to note that the answer provided by c33t is actually the answer to Neddy's question about this...
Code: | There may be some one step tools but I've never tried them. |
Maybe gparted, I'm not sure if that shrinks the filesystem or not but I assume it must for it to work! |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54099 Location: 56N 3W
|
Posted: Tue Jan 23, 2018 11:24 am Post subject: |
|
|
LIsLinuxIsSogood,
Rule 1. Assume nothing.
You have given some very good advice yourself. Practice with something expendable. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|