Cloning mga1 to dualboot Cauldron

[morgano]

Simple idea: i want to test out chauldron on same system, and have possibility to work on same user files.

If i keep it that way the transition to mga2 i simple and safe, and i can continue the same way then usig mga2+chauldron.

As getting to chauldron means updating from mga1 and changing repos, the quickest would be to clone all mga1 partitions, and add entry in boot menu. Can someone enlighten me on if that includes the /boot partition (i have such one separate from / )

I will manually maintain same user and group ID:s on the two systems.

I will then have a large partition with user file folders that I mount or link as folders into the /home of both systems. So there is no version conflicts between application files such as KDE, Firefox... Some version independent user programs goes here too, as well as virtual machine disk images. Part of this is stored locally, part from NFS.

Now add some twist:
I must have all user files encrypted in case of theft (mine and customers secrets)
That means gparted can not handle them, and diskdrake fail resizing and deleting.
(have to read up on doing all by command line I guess...)

/boot must not be encrypted - and i guess I must have one for mga1 and one for chauldron.

Current status is I have Mageia 1 fresh installed, in dual boot with Windows 7
( W7 used as SSD updater environment; http://forum.corsair.com/v3/showthread.php?p=541149 )

Here are the partitions on my disk ( a 120 GB SSD )

__Partitions
94 MB ext4 /boot - Mga1 boot
100 MB NTFS? "System Reserved" - W7 boot (Windows installer made this)
16 GB NTFS W7 "C:"
--above partitions are primary, below logical in an extended container --
5 GB NTFS for sharing files (Well i may try to use Win 7 now i have it...)
200 MB ext4 -intended as Cauldron /boot
9 GB left unused - maybe install service system here, or another distro for testing
81 GB (the rest) is one encrypted LVM; vg0, set up by mga1 installer

__Inside vg0
10 GB ext4 mga1 / *1)
4 GB swap
--Plan to add:
10 GB ext4 chauldron /
55 GB ext4 local user files and user programs *2)
2 GB free for LVM snapshot functionality


*1) I know it is generally better to also divide it in at least /home, maybe /var and /tmp, but i keep it simple as i know no tool that handle resizing etc so I intend to have just one partition per system including /home, separate /boot and a common swap (hibernate do not work anyway), and:
*2) user folders mounted or linked into each home.
(as well as mounting user folders from ethernet file server)


I can test and brake the system as it takes only 20 minutes do do a full disk image restore or backup to external 2TB SATA drive.

[juergen_harms]

What you intend should work perfectly - I have excellent experience with a similar setup, although I do not use encrypted partitions (but I do not think that encrypting will create serious difficulties if you solve the /boot question). You are right, defining user IDs in a coordinated way is essential.

For user data, I use - just as you plan - a separate (non-bootable) partition with /common as root. I replicate the home directory structure there, eg /common/home/harms contains all my data files, and dito /common/home/guest. When I install a new system (i.e. with a new /home/harms directory), a script links the directories from the common partition to the newly made /home/harms directory.

Having this shared /common partition makes other things easy: my user ssh keys sit in a template directory on the shared partition. That allows to have password-less login on my LAN without needing lengthy setup activities, even if I boot back and forth between - say - Mga1 and cauldron. In the past I simply linked files from /home/harms/.ssh to the template files under /common, but I am presently changing this to cloning. Similar for system ssh keys: their template is in /common/etc/ssh/... Retrospectively, I realise that quite some thought has gone into structuring the hierarchy in /common (version-independant user programs: they sit in /common/usr/local...) - applying Unix conventions under /common makes finding things easy.

Since I do not encrypt, I do not know about the /boot problem - my /boot and /home are in the root partition (as do all other standard linux system directories). With encryption, at a guess I would leave all system files in the bootable (non-encrypted) root partition, and create a small encrypted /home partition for each mga, cauldron, testsystem - whatever system (even if all user data sits on the encrypted "/common" partition, /home must be encrypted since you get copies of user data in cash, trash, history files that are under /home. My /home/harms at present is only 380 kBytes (I configure my thunderbird mail folders on the common partition: this way the daily backup of the common partition also backs up my mail folders - I do not backup the home directory). I know that mozilla hogs memory for creating its cache files - I had recently wiped them out, the demand for space will grow. Similar consideration for trash files (under .kde4). Maybe that helps you when you choose the size if your home partitions

Would a copy of my /boot/grub/menu.lst be of help?

[morgano]

Thank you Juergen

About what to encrypt
I do not have very serious secrets here, but realise that it do not take much extra cpu resource to encrypt "everything", so why not. Some secrets about system can be found in /etc, print cache and other things in /var and /temp...

About /boot
I think i should have only one, common /boot
Because, if I understand it correctly (but please correct me if i am wrong) grub resides there - and/or is set up from info there - and for it to be handled correctly from all systems they need to input ad output the same data.
But also initrd is stored there, one for each kernel for each system. Hopefully the systems have enough intelligence to not muck with other systems initrds during kernel upgrades.

But.. normally multi booting is done using one /boot in each installed systems root ?
I wonder how it works then...?
Next problem is if i install another distribution, that maybe want other content in /boot and treats it differently? But I guess i am clear as long it uses grub.
Maybe most safe is to chainload, see http://www.brunolinux.com/05-Configurin ... _grub.html

Attempt 1:

1) Clone /
used diskdrake to create an exactly as big partition for Cauldron / of same type as my mga1 /, and used dd on running mga1 to clone the content to it. (I would prefer the source not be in use, but I do not know how else to reach them in the encrypted LVM...)

2) Clone /boot
used gparted to copy sda1 (mga 1 /boot) to sda6 (cauldron /boot), sda6 is bigger and gparted automatically expanded it such after copy. (it is OK for /boot to be in an extended partition, BTW)

3) Fix identities
Edited partition label on cauldron /boot partition, and UUID on that and its / partition. (the latter has no Label) (How: uuidgen generates a new number and tune2fs -U thatnumber /dev/sdaX sets it. Check by command blkid )

Fix linking
3) Add chainloading to mga1 grub boot.lst (how: see link above)
-- primary partitins count from
-- mount cauldron / and /boot partitions somewhere in mga1 /mnt for the following, and later acess --
4) Edit partition numbers in cauldron /boot/grub: boot.lst and install.sh (device.map identical; same drive)
5) Edit cauldron fstab for partitions

BUT ...something went wrong: after selecting the chainload choice i added, i do not get the second grub menu, instead

Code: Select all

  Booting 'Cauldron'

root (hd0,5)
  Filesystem type is ext2fs, partition type 0x83
chainloader +1

Error 13: Invalid or unsupported executable format.

Press any key to continue...

(And when i press a button i get back to the first menu.) So not even the first step works...
Ideas? fsck on the partition suceeded OK, and except the edits it is a copy of the first, so what can have failed?!

Would a copy of my /boot/grub/menu.lst be of help?

Yes please, always interesting

(Ohh!!, sorry for misspelling Cauldron before...! )

[juergen_harms]

/boot
If you use configfile menu items, linux expects a separate /boot for the partitions concerned (see my example below). Doing it this way allows to include - say - a PCLinuxOS partition into your multiboot, and it should solve the failure to boot you are suffering

General remark on laying out your boot
You are taking a very "active hand" in laying out your disk, many things I have never done and would not feel safe with. Here is what works for me (and worked again the other day when I replaced my broken disk):

I use the installer of a Mageia iso DVD and the customise partition layout option:

- it detects windows partitions and puts them in /dev/sda1 and /dev/sda2 (sda1 is a fat partition for manufacturer diagnostics, sda2 the ntfs-3g windows production system - if there is no diagnostics partition, the ntfs-3g partition goes to sda1)
- it creates an extended partition /dev/sda3, all subsequently created ext4 partitions will go into this extended partition
- it puts the initially installed partition into /dev/sda5 (no idea why not sda4) and the swap partition into /dev/sda6
- each time you hit "add partition" (for additional linux partitions - bootable or not) it creates a new partition at sda7, sda8 and so on - to be subsequently used for installing a bootable system (the system your are installing has the mount-point /, all others have a generic name at your choice), or as a non-bootable data file-system

If I use gparted (for instance when needing to do resizing I have more confidence in gparted) I apply the same overall layout. Initially (back in lilo times) I had tried to manually determine partition numbers: normally that worked well for some time, and than "all at sudden" - when I created a new partition, the installer changed all partition number to have it its own way, which normally resulted in a mess. I do not know whether this is still so - using the installer-determined partition numbers keeps me safe from such incidents.

I do not need to do other manual actions, except - once a new system is running, create mount points for the other partitions where necessary and correspondingly modify /etc/fstab. (My description is slightly simplified: although partition labels are not required, in fact I create partition labels that correspond to the mount point I will use - this is helpful for having a script that automates the creation of mount-points and modification of /etc/fstab. Similar consideration for identities: identities of newly create partitions are determined automatically by the installer - no need to touch them; nevertheless, when I adapt my /etc/fstab I change from UUID to /dev/sd.. specifications - much easier to handle).

I do normally not run install.sh, except when I want to change the bootstrap sector from some other system partition to the one currently running to get its boot menu at the next boot.

You are cloning entire partitions rather than installing, that is different from what I normally do - but I think the partitioning aspect should be independent (and my recent experience confirmed: there are 2 alternatives for cloning: (a) using dd, establishing a binary copy into a stringently similarly sized partition, and (b) file cloning (for example tar cfv - . | (cd /media/LaCie; tar xf -), copying each file of the system one by one, which provides some more flexibility.

My /booot/grub/menu.lst
I do not yet have a cauldron partition, but that will look just like the test partition

Code: Select all

timeout 10
color black/cyan yellow/cyan
gfxmenu (hd0,4)/boot/gfxmenu
default 0

title linux-standard (Mageia 1 Production)
root (hd0,4)
kernel (hd0,4)/boot/vmlinuz BOOT_IMAGE=linux root=/dev/sda5 resume=/dev/sda6 splash=silent vga=788
initrd (hd0,4)/boot/initrd.img

title linux-test8 (Mageia 1 Test)
root (hd0,7)
configfile /boot/grub/menu.lst

title linux-nonfb
root (hd0,4)
kernel (hd0,4)/boot/vmlinuz BOOT_IMAGE=linux-nonfb root=/dev/sda5 resume=/dev/sda6
initrd (hd0,4)/boot/initrd.img

title failsafe
root (hd0,4)
kernel (hd0,4)/boot/vmlinuz BOOT_IMAGE=failsafe root=/dev/sda5 failsafe
initrd (hd0,4)/boot/initrd.img

title windows
root (hd0,0)
makeactive
chainloader +1


[morgano]

EDIT Now i saw your post Juergen, will read later, must go on work /EDIT

I was reading a recent grub manual (1.99) saying logical partitions start from 5 (and my cauldron /boot is first logical). (I did not read the part saying primary partitions start from 1, and i see they start at 0 in the files here...

Now i realise i have old grub, so i should set (hd0,4) instead, as per manual 0.97, and sure enough i see version 0.97 installed.

-Um, well, that fails differently:

Code: Select all

root (hd0,4)
 Filesystem unknown, partition type 0x7
chainloader +

BOOTMGR is missing
Press Ctrl-Alt-Del to restart

But... Filesystem 0x7 ... = NTFS? That is just plain wrong.

What do work is to start my clone directly from same grub, and i can see it is the cloned system as i can make different changes to the desktop so i can see where I am But I should not upgrade kernel. Well i can do that too, but must manually make sure the right initrd is used. Better to get it chainload as intended.

[morgano]

(Work got delayed)

Thank you so much, Juergen! That configfile method works.

(And i need to use numbering as (hd0,5) but i still can not see why)

I have now similar content as you, except all the /boot parts of the paths as they already are separate /boot partitions.
Also added configfile in the chauldron menu.lst so i can jump back too if i select wrong reboot selection

OK, this is nifty, but still uses the same bootloader program all time.
So what if I install another distro that use recent grub? That distro installer will set up the numbering as per the new standard, and will thus be mis-read by this old version of grub?
Well that is not a current problem, and i know what to look out for.
But it would be best if chainloading worked.

Just for testing i added chainloading in chauldron menu, jump to that using configfile method and when i try to chainload back i get exactly the same error as if i try to chainload cauldron as my in earlier post above.

[juergen_harms]

to use numbering as (hd0,5) but i still can not see why

the reply is simple: grub starts counting drives and units at 0: sd6 maps to hd(0,5) - 0 for sda and 5 for 6

So what if I install another distro that use recent grub

by "recent" and "new", do you mean grub1 / grub2 differences? as far as I know, you will probably have problems with grub2 distros (i.e. Ubuntu), with grub1 distros I did not have any problem (I did a lot of distro testing when I started getting doubts about Mandriva and did not yet know about Mageia - always making the distro work in my multi-boot setup).

Unless you can avoid it, I would for the moment, or at least initially, not invest time in making multi-boot work with grub2 partitions - I guess there will, anyhow, be collective getting wise on grub2 (Mageia3?) You could have a look at the Gnu Make Manual - but IMHO time spent on learning fancy things about make is not well spent - you risk to invest on obsolete stuff or to become a lone explorer of things around the corner. There has, recently, been a discussion in this forum on Mageia and grub2.

I forgot to mention one drawback of the "configfile" option of grub: if you add another partition and want to boot into it from all the existing partitions, you have to modify menu.lst in each of these partitions.

[morgano]

Yes this works and i will leave it here.

No, grub partition numbering according to its manual 0.97 say first primary partition is 0, and first extended) is number 4.
I guess the extend container is number 4, because first actual logical partition (my sda6) is number 5 according to my grub version.

[jaywalker]

If I remember correctly, the first MSDOS partitioning scheme only foresaw one main partition containing everything and being bootable - think MSDOS/PCDOS. The partitioning scheme allowed for a maximum of 4 of these partitions, with the proviso that only one should be bootable at any one time. Then came the 1990s. When there was perceived to be a need (and discs were big enough to warrant it) to have more than 4 partitions the bodge, which would still fit in the original basic partition table, was to invent a thing called an extended partition type and allow one of these to take the place of one of the original "primary" bootable partitions. The new rules were that this extended partition could contain any number of logical partitions in a linked list structure which avoided the inflexibility of a limited size partition table.#

So ever since then, if you want more than 4 partitions on an MSDOS partition table disc then the last one in the primary partition table would be "extended" type. You could now only have 3 optionally booted partitions; 1, 2 and 3. The extended partition itself was number 4 so the logical partitions it contains start at number 5.

You do not need to use all 3 primary partitions, but the extended partition is always number 4.

In grub-legacy terms that means a disc with more than 4 partitions might look like this:

(hdn,0): primary bootable partition
(hdn,1); optional, possibly bootable and/or hidden primary partition
(hdn,2: optional, possibly bootable and/or hidden primary partition
(hdn,3): extended partition

(hdn,4): first extra data partition
(hdn,5): another data partition
(hdn,6): foreign OS partition
... etc.

And when you have got your head around all of that, I heard somewhere that grub2 is changing again to base all its drive and partition counts from 1 instead of zero.

[Ken-Bergen]

So ever since then, if you want more than 4 partitions on an MSDOS partition table disc then the last one in the primary partition table would be "extended" type. You could now only have 3 optionally booted partitions; 1, 2 and 3. The extended partition itself was number 4 so the logical partitions it contains start at number 5.

You do not need to use all 3 primary partitions, but the extended partition is always number 4.

In grub-legacy terms that means a disc with more than 4 partitions might look like this:

(hdn,0): primary bootable partition
(hdn,1); optional, possibly bootable and/or hidden primary partition
(hdn,2: optional, possibly bootable and/or hidden primary partition
(hdn,3): extended partition

(hdn,4): first extra data partition
(hdn,5): another data partition
(hdn,6): foreign OS partition
... etc.

And when you have got your head around all of that, I heard somewhere that grub2 is changing again to base all its drive and partition counts from 1 instead of zero.

You do know what MSDOS means don't you? The MS stands for MicroSoft and the DOS stands for Disk Operating System nether of which have anything to do with the actual hardware only how you access it.
Four primary partitions is an hard drive Master Boot Record limitation and has nothing to do with the operating system.

On the system I'm posting from there are three primary partitions, a data partition, a swap partition and an extended partition. The extended partition contains five additional partitions one of them being /boot which is where my Linux installation boots from.