Hello.

I'm going to re-partition the harddrive to allow for dual-booting, and create separate data and home partitions that are shared between the two distributions. This is the first time I do anything like this, and I need some help.

I think I've figured out most of it but there are some questions I've been unable to find answers to:

1. Will shrinking /dev/sda1 change its UUID?

• /dev/sda1 is bootable and contains Debian /.

/etc/fstab is defined by UUID. If it changes, I won't be able to boot into Debian to edit fstab and run update-grub. And I need to run update-grub after booting into /dev/sda1 (all the partitioning is to be done from a SystemRescueCD when it's unmounted), creating a sort of catch-22.

2. If shrinking /dev/sda1 destroys it, could it destroy the whole partition table?

3. Should a chainloaded Slackware root (on a logical partition) be bootable?

• Grub2 is on the MBR.
• LILO will be on the superblock of /dev/sda8 (the Slackware root partition), and LILO will be chainloaded from Grub2.

The Slackware installer says if LILO is on a root partition's superblock, then that partition must be bootable. But does this apply when /dev/sda1 (Debian root) is already bootable, and Grub2 is already on the MBR?

I read somewhere that only BIOS cares about the bootable flag. That should mean that once Grub2 is loaded, it can chainload LILO, which in turn will load Slackware, regardless if /dev/sda8 is bootable or not. Is that correct?

4. About changing the mountpoint of /home to /mnt/data

After doing all of this (see Information, below) I have to boot into Debian again and tell Debian to mount /home (/dev/sda6) at /mnt/data (and /dev/sda7 at /home).

I know how to change the entries in fstab. Is that it, or do I also have to run update-grub and update-initramfs (or anything else)?

• The /home partition is currently on /dev/sda6. I want it to be mounted in /mnt/data instead.
• I'm going to make a new /home partition on /dev/sda7.

Information

Here's how the harddrive looks now:

This is how it should look when done:

(They are all ext3.)

The only dangerous operation that I have to do in GParted is shrinking /dev/sda1, and then I can (hopefully) just restart the computer and boot into Debian like before.

I figured this is the safest approach, since I won't have to resize the 240 GB partition that contains all my stuff.

Does it sound like this could work?

Thanks in advance.

No. Only a reformat will change its UUID.

More to come in a bit, busy day.

1 members found this post helpful.

gparted is very good, but you can ameliorate all your fears by taking decent backups - before you start screwing with partitions.
1) no
2) no
3) it had better be. But it (and linux boot-loaders in general) doesn't need a boot flag.
4) just changing fstab should be sufficient.

update-grub may be required, and should be run, but is independent of any fstab/mountpoint changes.

a shared home ?. Whoa. Not on (any of) my systems. Get them backups ready.

2 members found this post helpful.

Some comments on that:
If you need a boot flag on one of your partitions can be hardware dependent. I spent a whole day after re-organizing the partitions and installing a fresh system on my laptops harddisk with trouble-shooting (it just did not want to boot, no matter what I tried), until I realized that this machine refused to boot from a harddisk that does not contain a partition with boot flag. Not surprisingly it didn't care at all which partition was flagged, it just wanted to have that flag.

update-grub: to run that that is only required if (as the name says) you want to update the bootloader configuration. So it is not needed when you change partitions not involved in the boot process.
+1 for that. A shared /home will work if you set up different user-names on different distros. If you use the same username this may end in some really weird behavior of your applications, especially if the versions of the same application are far appart, which is to be expected if this is Debian 6 and you intend to install Slackware 14.

1 members found this post helpful.

There is no need to install LILO at all.
Your debian grub2's os-prober will pick slackware up.
Worst case you would have to create a /boot/grub/ directory containing a simple menu.lst file such as

where /boot/vmlinuz-linux and /boot/initramfs-linux.img are symbolic links to your kernel and initrd respectively

Or you could edit the menu.lst file each time you update your kernel, although this would require you to boot into debian and update-grub for the new kernel to show up in grub2 ( this requirement is why I use the above symlink approach.)

EDIT: alternatively, you could add a custom menu entry to Debian's grub for your Slackware kernels ( which is probably not the easy route, but it will work)
https://help.ubuntu.com/community/Grub2/CustomMenus

1 members found this post helpful.

After you shrink /dev/sda1 you will have unpartitioned space outside your extended partition. You will also have to re-size your extended partition to include the space that your shrink provided.

1 members found this post helpful.

Thank you very much for the help.

Backups have been made.

The shared home is going to contain one user per distribution, and only configuration files. You are correct TobiGSD, it's Debian 6 + Slackware 14 -- the two best distributions.

I know but I want to see the LILO screen. Chainloading seems easy to set up, and I probably have to do it in the future anyway. In /etc/grub.d/40_custom:
And in /etc/lilo.conf:
I don't have a menu.lst. Isn't that for Grub legacy?

I didn't know that. I thought free space could be allocated anywhere. In that case I may as well shrink the 240 GB partition too, and leave 38 GB for future BSD installs among the primary partitions.

That means it would be useless to shrink the swap partition, since it's right before the huge 240 GB partition, unless I move it 1 GB to the "left". Since it has 70+ GB on it, it'll probably take hours and I'll get a power outage in the middle of it. Not worth it.

Then it's possible to put those 38 GB in /dev/sda3 and /dev/sda4 later, right?

Yep.

1 members found this post helpful.

Excellent. Thanks again.

You're welcome, glad to be of help.

Just thought I should update this to say how it went, and for future searchers.

Everything worked. Other than Slackware changing the UUID of the swap partition (even though it was already formatted as Linux-swap), so Debian couldn't find it, there were no problems. And this was trivial to fix: just blkid and update the value in fstab.

6 MiB couldn't be allocated at the end of the extended partition -- maybe due to rounding to cylinders, or perhaps it has something to do with fdisk -l reporting a "+" after the block count on the shrunken partition. All the data is intact though, and both systems work fine.