Announcement

**mr_raider** · Oct 21, 2020, 01:53 PM

The questions I have:
- Why is part of the Linux partitions an "extended" partition, but why is the root partition outside of it? Did I do this? I followed the partition instructions from a web-site, so it is possible... I do understand the reasons for the extended partition.

this is a limitation of the old msdos parttition scheme which win xp uses. It's teh only way to have so many partitions

- Any comment on the 30GB size of the swap partition in light of the amount of 8GB RAM in my system?

Overkill. 8 or 16gb would be enough if you hibernate.

Why is there /dev/sda6 which is practically empty? Is there a need or reason for that? Can I delete that? How did it get there? I do not recall it explicitly creating it, but again, it is possible...

You created it for some reason. Or there was an old install there. It is currently not mounted so your OS is not using it. To check the countents, mount it with a command like:

Code:

sudo mount /dev/sda6 /mnt

-

Why is /dev/hda7 locked?

It's your active / system. It's always locked and must remain mounted when running within the system.

To accomplish what you want I see three options:

1. This is by far the slowest option:
a) Delete the undesired partitions outside the extended part.
b) Resize /dev/sda3.
c) Then resize the individual components of sda3 one by one.

this must be done from a LivUSB environement, not within the OS. If you have a rotational drive, each resize operation will take hours. It's faster on an SSD

2. The easiest option. Delete all partitions that are not windows. Reinstall your OS with the desired partition scheme manually.

3. Intermediate option. Delete all teh non desired partitions. Create a single new primary partition to encompass the free space. Mount the new partition in a convenient location in your home directory under a convenient location, i.e. /home/myusername/extrastorage

Tell us how you want to proceed so we can guide you. Whatever option you choose should be preceded by a backup of critical data. You can hose your data if you are not careful

**oshunluvr** · Oct 22, 2020, 10:11 AM

First, let me say thank you for the excellent post. You provided all needed info and asked good, solid questions. I appreciate the time you took to get the post right the first time.

Originally posted by orbanp View Post

The questions I have:

- Why is part of the Linux partitions an "extended" partition, but why is the root partition outside of it? Did I do this? I followed the partition instructions from a web-site, so it is possible... I do understand the reasons for the extended partition.
MBR partitioning only allows for 4 partitions called "primary" partitions. To exceed 4 partitions, one of the primary partitions needs to be an "Extended" partition. Extended partitions can hold (for practical purposes) 63 "Logical" partitions. Partition numbers 1-4 are reserved for primary partitions (the extended partition is a type of primary partition). The root partition (sda7) is not "outside" the extended partition, it is a logical partition within the extended partition.

- Any comment on the 30GB size of the swap partition in light of the amount of 8GB RAM in my system?
Way too much. You need 8GB if you're going to hibernate, Probably only 1-2 if you're not. IMO, You don't have to have a swap partition at all unless you're using a COW file system or are going to install multiple linux distros. You can use a swap file instead.

- Why is there /dev/sda6 which is practically empty? Is there a need or reason for that? Can I delete that? How did it get there? I do not recall it explicitly creating it, but again, it is possible...
No reason for it. ~~Probably a bad partitioning tool left room for alignment or something XP had done a long time ago like a recovery partition.~~ Yes you can delete it

- Why is /dev/hda7 locked?
Because the file system on it is mounted. The partitioning tool won't let you modify a partition with a mounted file system because you would likely destroy your data.

As mentioned I would like to add all the empty spaces to the home partition.
What would be the best way to accomplish this?
"Easiest" for me would be to do this from within Linux but I would not want to loose my system!
I do have a 2TB external USB drive that I partially use for backup for my own files (not the complete system, using rsync).
Honestly, your drive partitions are kind of a mess. The "easiest" way to add space to your linux partition is to partition and the 195GB empty space by mounting it somewhere and moving data to it. However, this is not anywhere close to the best way. It's difficult to understand how you ended up where you are because sda2 and sda6 both are linux formatted but appear to have nothing on them and aren't being used. I suspect the reported "used" space is the default 5% block reserve that ext4 allocates if you use default settings when formatting.

If this were my system. here's what I'd do:
Delete sda2 and sda6 (this assumes they are empty)
Remove the swap partition from any install that's using it (based on your screen shot, it's not being used anyway) and delete sda5.

This leaves you with:
- sda1 - Windows xp (293GB)
- unallocated space (255GB)
- sda2(formally sda3) - Extended partition (383GB)
- unallocated space (108GB)
- sda5(formerly sda7) (275GB)

In the first unallocated space, create a new sda2 partition of 30GB (this will move the extended partition back to sda3).
Do a new 18.04 install to sda2 and set it up as your main boot distro.
Use your USB drive to move your entire home folder with all your personal files off of sda5.
Delete sda5 and sda3.
Create a new sda3 with ALL the remaining free space (608GB)
Copy your entire home folder contents (not the /home/ folder itself, but everything that is in it) to sda3
Mount sda3 as /home in your new Linux install.
Done.

You then would have:
- sda1 - Windows xp (293GB)
- sda2 - Linux install (30GB)
- sda3 - Linux /home (608GB)

Nice and clean with plenty of free space and a separate home partition which is a good idea for several reasons.

NOTES:
When you copy /home, be sure you get all the hidden files and folders too.
30GB is plenty of space for a Linux install even with games and everything you can think of. Most of the file space will be used in your home.
If you need swap, make a swap file.

OPTIONS:
If you want to save some space for a playground or future use, leave some at the end by making sda3 smaller.
If you are planning on dumping windows eventually, you will end up with all that space before your Linux partition. It may be difficult to use it easily because of the partition limitations of MBR drives. In that case, you may want to make sda2 an Extended partition and put your Linux install and home partitions in it as Logical partitions sda5 and sda6 instead. There's no reason not to do it this way - I mean it won't effect anything except the device names which you'll rarely reference anyway - and it will leave you with a lot more flexibility in the future.

Whatever you decide to do, please report back on your decisions, successes, and failures (hopefully none of those!) and welcome to Linux and Kubuntu Forums dot Net!

**oshunluvr** · Oct 22, 2020, 10:32 AM

BTW, you could use a partitioning tool like gparted from a bootable LiveUSB and delete the unused partition and move the linux install up the drive. However, I do not recommend this as the chances of killing your data are too high IMO.

**orbanp** · Oct 25, 2020, 06:31 AM

Hi mr-raider, oshunluvr,

Many thanks for the replies, to both of you! I really appreciate the help!
Very enlightening and educational!

I have been reading up and mulling over your replies...
Yes, I can see that the partitioning is a mess!

Tentative plans are as described by mr_raider in option1: delete partitions /dev/sda2 and /dev/sda6 and then resize/move /dev/sda3 from a liveCD.
I would leave the swap partition, but reduce its size.

While installing the system anew is tempting, I have installed far too many programs, additions that presumably I would have to reinstall.
That would be a major inconvenience.

Only down side to option 1 as far as I can see is that there are no separate linux and home partitions.
Eventually I plan to get a faster platform, possibly with SSD, and in that case it would be advantageous to have those separate partitions.

Looking at my backup command, it looks like I am backing up more than just my user files.
This is the command I have been using:
sudo rsync -aAXv / --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} ./

Any comments, suggestions on the above?

Thanks, Peter

**mr_raider** · Oct 25, 2020, 06:38 AM

I just realized that some recent versions of the installer put stage 2 of grub in the extended partition, just ahead of the first logical volume. Moving the boundaries may hose the bootloader. You should have a live USB ready in case you need to rescue the install.

**orbanp** · Oct 25, 2020, 07:44 AM

Originally posted by mr_raider View Post

I just realized that some recent versions of the installer put stage 2 of grub in the extended partition, just ahead of the first logical volume. Moving the boundaries may hose the bootloader. You should have a live USB ready in case you need to rescue the install.

Thanks for the warning!
Interesting info about the place of the bootloader!
So deleting that partition would delete the bootloader too!

I have been using Super Grub2 to repair the bootloader, and running grub-install from 18.04.
Do I presume correctly that if I delete that partition grub-install would put the bootloader in a "more appropriate" place?

Thanks, Peter

**mr_raider** · Oct 25, 2020, 07:36 PM

Originally posted by orbanp View Post

Thanks for the warning!
Interesting info about the place of the bootloader!
So deleting that partition would delete the bootloader too!

I have been using Super Grub2 to repair the bootloader, and running grub-install from 18.04.
Do I presume correctly that if I delete that partition grub-install would put the bootloader in a "more appropriate" place?

Thanks, Peter

The answer is "it depends"

Windows XP did not align the first partition the same way. It used old sector boundaries rather than MB. The net result is computers of that vintage have very little space in the area before the first partition boundary. That's the space where bootloaders live. At some point grub became too big to fit in there so only the first stage lives in that area, linking to a second stage usually at the start of the first linux partition. Windows 7 onward created a much larger gap before the first partition which solved that problem.

I can't predict what will happen if you try to move sda3's left boundary. That will be necessary step to resize the logical volumes inside the extended partition. Make sure you have a backup of any precious data.

**orbanp** · Oct 27, 2020, 06:19 AM

Originally posted by mr_raider View Post

The answer is "it depends"

Windows XP did not align the first partition the same way. It used old sector boundaries rather than MB. The net result is computers of that vintage have very little space in the area before the first partition boundary. That's the space where bootloaders live. At some point grub became too big to fit in there so only the first stage lives in that area, linking to a second stage usually at the start of the first linux partition. Windows 7 onward created a much larger gap before the first partition which solved that problem.

I can't predict what will happen if you try to move sda3's left boundary. That will be necessary step to resize the logical volumes inside the extended partition. Make sure you have a backup of any precious data.

How much room do you need for the Grub2 bootloader?
Presently the NTFS (first) partition starts at sector 63, and with 512 bytes per sector that is about 31.5kB room.
I guess I could move up the beginning of the first partition and shrink a bit.

Thanks, Peter

**oshunluvr** · Oct 27, 2020, 08:22 AM

Originally posted by mr_raider View Post

I just realized that some recent versions of the installer put stage 2 of grub in the extended partition, just ahead of the first logical volume. Moving the boundaries may hose the bootloader. You should have a live USB ready in case you need to rescue the install.

I'm not sure I understand what you're trying to say here or what you mean exactly, but the above statement as I read it is incorrect. This info from the GRUB wiki:

GRUB on systems using BIOS firmware:
1st stage:boot.img is written to the first 440 bytes of the Master Boot Record (MBR in sector 0).
2nd stage: diskboot.img is the first sector of core.img (called stage 1.5 in GRUB Legacy) with the sole purpose to load the rest of core.img and is written by grub-install.

On MBR partitioned disks: core.img is stored in the empty sectors (if available) between the MBR and the first partition.

On GPT partitioned disks: partitions are not limited to 4, thus core.img is written to its own tiny (1 MiB), filesystem-less BIOS boot partition.

3rd stage: core.img enters 32-bit protected mode, uncompresses itself (the kernel of grub and filesystem modules to reach /boot/grub), then loads /boot/grub/<platform>/normal.mod from the partition configured by grub-install. If the partition index has changed, GRUB will be unable to find the normal.mod, and presents the user with the
GRUB Rescue prompt, where the user “can” find and load normal.mod, or the linux kernel.
The /boot/grub directory can be located on any partition (GRUB can read many filesystems, including NTFS). Depending on how it was installed it's either in the root partition of the distribution, or a separate /boot partition.

4th stage: normal.mod (equivalent of stage 2 in GRUB Legacy) parses /boot/grub/grub.cfg, optionally loads modules (eg. for graphical UI) and shows the menu.

Startup on systems using UEFI firmware
Common on motherboards since ca. 2012.
/efi/<distro>/grubx64.efi is installed as a file in the EFI System Partition, and booted by the firmware directly, without a boot.img in sector 0.
/boot/grub/ can be installed on the EFI System Partition as well.

Note where 4th Stage - not 2nd stage - is in /boot/grub. The main take-away point of the above is in no case does GRUB use any part of the drive other than: The first 440 bytes of the MBR, The space after the MBR and before the first partition (or, if a GPT partitioned drive, the required BIOS BOOT partition), and /boot/grub folder wherever it resides.

Additionally NO DATA is ever addressable on an Extended partition. The only function of an extended partition is to hold Logical partitions. However, this isn't all that important because Logical partitions are addressable even if GRUB becomes unbootable. It's apples and oranges - the partition table type has nothing to do with it. In other words, GRUB not being bootable or even not installed at all doesn't magically make Logical partitions become unreadable.

Having a bootable thumb drive around is always a good idea just in case an update borks GRUB, but that happening has zero effect on partitioning. If you want more disk security, make a backup of your partition table on the thumb drive so it can be restored.

I have written extensively elsewhere on this forum about both topics: GRUB and the BIOS-BOOT partition for GPT drives and how to backup an MBR partition table.

**mr_raider** · Oct 27, 2020, 12:13 PM

Originally posted by oshunluvr View Post

I'm not sure I understand what you're trying to say here or what you mean exactly, but the above statement as I read it is incorrect. This info from the GRUB wiki:

Note where 4th Stage - not 2nd stage - is in /boot/grub. The main take-away point of the above is in no case does GRUB use any part of the drive other than: The first 440 bytes of the MBR, The space after the MBR and before the first partition (or, if a GPT partitioned drive, the required BIOS BOOT partition), and /boot/grub folder wherever it resides.

Additionally NO DATA is ever addressable on an Extended partition. The only function of an extended partition is to hold Logical partitions. However, this isn't all that important because Logical partitions are addressable even if GRUB becomes unbootable. It's apples and oranges - the partition table type has nothing to do with it. In other words, GRUB not being bootable or even not installed at all doesn't magically make Logical partitions become unreadable.

Having a bootable thumb drive around is always a good idea just in case an update borks GRUB, but that happening has zero effect on partitioning. If you want more disk security, make a backup of your partition table on the thumb drive so it can be restored.

I have written extensively elsewhere on this forum about both topics: GRUB and the BIOS-BOOT partition for GPT drives and how to backup an MBR partition table.

I seem to recall legacy installs failing sometimes on older PCs running Win XP. These disks had the first partition boundary on sector 63 which did not leave enough space for grub's core.img file. In those cases it suffed the core.img somwehere else inside the logical partitions. IIRC the problem was particularly present when using LVM, RAID or btrfs root partitions.

Newer PCs with win 7 had 1MB aligned partitions so it was never an issue.

**oshunluvr** · Oct 27, 2020, 12:51 PM

Originally posted by mr_raider View Post

I seem to recall legacy installs failing sometimes on older PCs running Win XP. These disks had the first partition boundary on sector 63 which did not leave enough space for grub's core.img file. In those cases it suffed the core.img somwehere else inside the logical partitions. IIRC the problem was particularly present when using LVM, RAID or btrfs root partitions.

Newer PCs with win 7 had 1MB aligned partitions so it was never an issue.

Yes, regarding the partition boundary on old windows PC beginning before 63 that is true. GRUB 2 needed more room than GRUB Legacy. I've never heard of or seen GRUB 2 relocate itself to another part of the disk in those cases, only fail to install. I last encountered this in 2010 on a Dell laptop that had originally had Windows XP on it. However, that was GRUB "Legacy" not GRUB2. The use of the term "Legacy" with two different meanings might be part of the confusion.

GNU GRUB 0.97 was simply known as "GRUB" or "GRUB 0" but after the release of the new version of GRUB, called "GRUB 2" or for a short time "GRUB PC", the old version was then often referred to as "GRUB Legacy". As far as I know, no Linux distro has distributed GRUB 0 since 2015 and most switched in 2012. I used LILO most of the time in those days as I found GRUB 0s menu.lst a PITA to maintain.

Today, when we refer "Legacy" booting, it's most common meaning is "Non-UEFI" or "BIOS boot" not the use of GRUB 0.

I believe the problem you recall was one related to GRUB 0 and AFAIK never occurred with GRUB 2. GRUB 2 will simply fail to install if space is insufficient, at least IME. This is actually worse in some cases because if you're unprepared for this eventuality, you can end up with an unbootable machine. What I learned back then when GRUB 2 was new was some Windows utility or program would put a few bits into the area GRUB 2 needed and it would detect the data at installation and fail (never had it relocate itself). The solution was to zero those sectors before installing Linux and then it always went swimmingly.

Of course, GPT introduced a different set of issues, but again as long as you're aware and prepared it's no big deal.

GRUB failures seem to be the most feared circumstance by new-ish Linux users but with only little practice and familiarity are easily remedied. I've never had a GRUB failure result in data loss. The key is to keep that bootable USB thumb drive around.

**orbanp** · Oct 29, 2020, 06:58 AM

Just a quick update.
I deleted sda2 and sda6 partitions and moved sda7 to the beginning.
Now I ave about 90GB free space.
The re-partitioning wrecked the boot-loader as I was forewarned, but with the SuperGrub2 disk I could boot into Linux and then reinstall grub.
Now both systems boot.
I left the swap partition, but interestingly it is not used by the system. Why is that?
This is how the partitioning looks like now.

I still have that un-allocated ~250GB space, I might install 20.04 there.

Thanks for the help, Peter

Attached Files

**oshunluvr** · Oct 29, 2020, 08:12 AM

swap has to be mounted in fstab before it will be used or you can manually turn it on from the command line using the "swapon" command. In you case, "sudo swapon /dev/sda5"

**orbanp** · Oct 29, 2020, 01:08 PM

Hi oshunluvr,

Thanks for the continuing education, I really appreciate it!
The swapon command turned on the partition.

This my fstab file:

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sda7 during installation
UUID=5b9e2c67-a3df-4842-a869-8923c90c66a2 / ext4 errors=remount-ro 0 1
/swapfile none swap sw 0 0
/dev/fd0 /media/floppy0 auto rw,user,noauto,exec,utf8 0 0

Originally I did create a swap partition but it looks like that the system created a swap-file definition in the fstab file instead.
Is this done by default?
Do I see this correctly?

These are the UUIDs of the partitions:

peter@AMDX2U: $ blkid
/dev/sda1: LABEL="WXP_Part" UUID="6AA8E2E5A8E2AF2F" TYPE="ntfs" PARTUUID="ceaa1a9f-01"
/dev/sda5: UUID="baf03039-31de-4c5c-a107-8618bbfe7985" TYPE="swap" PARTUUID="ceaa1a9f-05"
/dev/sda6: UUID="5b9e2c67-a3df-4842-a869-8923c90c66a2" TYPE="ext4" PARTUUID="ceaa1a9f-06"

Am I correct to assume that replacing the </swapfile> with the UUID number of /dev/sda5 in the fstab file would mount the swap partition at boot time?
This is the line I would use:

<UUID="baf03039-31de-4c5c-a107-8618bbfe7985" none swap sw 0 0 >

Thanks, Peter

Announcement

Partitioning question

Partitioning question

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment