The last AntiX update on my laptop, included an update of grub. I got a message like "This msdos-style partition label has no post-MBR gap; embedding won't be possible!". Instead it's going to use something called a block chain which is deprecated as less safe.

Apparently I don't have the usual gap between the mbr and the first partition where grub usually puts its stage 2 kernel. I didn't partition this disk; the AntiX installer did. I only do manual partitions when there is more than one system on a machine.

I can get access to gparted by booting from a SystemRescue disc, but is there any simple way to use it to recreate this gap?

Do you have 4 sectors (2048 bytes) free at the start of your disk?

(Although I always create my own partitioning, I thought it always allowed for 4 free sectors at the start of the disk, my present set ups do.)

Apparently not. That must be the absent gap grub is complaining about.

Say what ?.
Evidence, show us the data. "fdisk -l" (a current version) would be a start.

I don't know how the auto install sets up your disk, but if it has a swap partition as the first, you should be able to manipulate it - but it would probably be easier to back up your data & re-install manually.

OK. This is from my laptop. Output of fdisk is:
/dev/sda1 * 1 308320255 308320255 147G 83 Linux
/dev/sda2 308320256 312514559 4194304 2G 83 Linux

/dev/sda2 is the swap according to /etc/fstab. First (root) partition starts on 1, which clearly isn't what is required.

ext4 filesystems can't be truncated from the beginning, so I don't see any way to fix this except to dump out my root partition using something like fsarchiver and repartition the drive. I assume I should then start the root partition on 2048 to create a gap??

For the sake of curiosity, you could try (after having backed up your filesystem) using GParted Live to reduce the swap size, move the swap to the right, then move sda1 to the right a bit to create the required gap. You would then probably have to throw SystemRescueCD or similar at it to reconstruct Grub, or do this step manually.

If you're going to back up your system and are planning to do a fresh install anyway, I would at least give the above a go to see if it does the job.

It's probably better to reduce the size of the root partition. I really don't need 147 GB there, whereas I do need my swap partition to be twice the size of my RAM so that I can hibernate the system.

But I'm pretty sure you can't move the beginning of an ext4 filesystem, only the end of it. So that means deleting the partition, then creating a new one and copying back the filesystem contents onto it.

(Swap should be ID 82)

Unfortunately, I think re installing is in order, quickest/easiest solution.

I don't do anything special when installing, other than creating my own partitioning, & my first one always starts at 2048, so I really don't know how you ended up without.

P.S. If I use a swap partition, it is either the first, preferable as it's the fastest part of the disk, so I'm informed, or the second.

Edit: As for partitioning, I would have a swap equal to your ram, for hibernating, a root partition of 7GB to 10GB, & the rest as your /home.

I've done so in the past. The only thing I've had to watch out for is if the partition is bootable, in which case I usually need to sort out Grub afterwards.

I don't like the idea of reinstalling because of the big update that always follows. I have a monthly download ration. Though I suppose I could always get around that by dumping out my /var/cache/apt directory and copying it back after the installation. That would cause apt to update from the cache and not the repo, wouldn't it?

But I lean by preference to repartitioning. I have been reading the parted manual and it seems you really can move a partition within available space. I don't know how that works exactly because it seems to involve exactly the same kind of sequential rewriting as if you truncated the partition from the beginning, and I know you can't do that with an ext2/3/4 filesystem. But it suggests that the following should work:
1) Take an archive for safety (though there's no really important data on that machine)
2) Truncate sda1 at the end by a MB or so.
3) Slide it up so that it once again abuts on sda2. Now the gap will be at the beginning.
4) Reboot and run grub-install.

That should work, shouldn't it?

Do I actually need a home partition? I don't use that machine a lot, mostly I use it for dumps.

That sounds like a plan. When you worry about truncating a filesystem from the beginning, don't think of it like that - it's the filesystem *container*, i.e. the partition, that you're moving and/or truncating. When you resize a partition, GParted should automatically resize the filesystem within that partition and do it properly with e2fsprogs. So, even if you truncate a partition from the beginning, GParted will truncate the filesystem itself from the end.

If it's of any consolation, I don't think that many of the 20 or so partitions on my hard disk are where they were when I first created them, I've moved them around that much.

No, you don't need a home partition. It's useful for organisational purposes, but especially if you're not using that machine much, it's fine to use the root partition for the home directory.

1 members found this post helpful.

When I used gparted, I discovered some free space at the end of the drive, so I made a new swap partition (with the correct type this time!) and deleted the old one. That made some space at the end of sda1, so I shifted it forwards by adding a 2048 byte offset at the beginning.

I couldn't get grub-install to work from SystemRescue, neither in nor out of chroot, so I crossed my fingers and tried a reboot from the hard drive. Fortunately it worked and I was able to run grub-install without errors or warnings. Which means, I hope, that stage 2 has now gone where it is supposed to.

Now I have to fix up the mess caused by changing my swap partition from sda2 to sda3. I've fixed /etc/fstab and swapon works. Now I have to fix the resume specification in grub and then grub-update.

Thanks for all the help, guys.

Here's a weird thing: when I rebooted, there was a long wait while the kernel looked for a resume device and failed to find one. Traditionally this is specified on the kernel command line (resume=/dev/sda2). So I checked gub.cfg and then /etc/default/grub, intending to change it to sda3, and couldn't find any reference to it. Maybe modern kernels don't need to have this specified any more but just check in /etc/fstab for the swap partition.

Turned out it was the initramfs that had the old resume device set. I ran update-initramfs and it picked up what is now the correct device /dev/sda3. So that should be that.