How to move a Ubuntu installation from one disk to another?

I'm going to install Ubuntu 8.10 on a couple of machines at work and since the Internet connection here is dog slow, I've installed Ubuntu with all the latest updates as of a week ago on a separate disk that I brought out to work. But the problem is, how do I transfer the installation over to the disk in the two other machines? I've tried using Ghost (an old version), but that doesn't understand ext3 and creates a lot of errors which fsck doesn't seem to be able to fix without mangling the installation. I've also tried to install Ubuntu on the machine and copy all the folders except /dev, /proc and Lost&found, but I get problems copying some files and when I try to boot, I get a kernel panic from /sbin/init (no such file or directory).

Anyone have any good ideas?

Stig

Just copy the filesystem(s) directly.

First, boot from a Linux LiveCD with the source and destination drives attached. Then make the partitions on the second drive the same as the partitions on the first drive using fdisk or similar. Then copy the partition devices directly, like "cp /dev/sda1 /dev/sdb1". Obviously, make sure you're copying from and to the right place. If you overwrite the source drive accidentally, there's no going back. You don't need to bother with the swap partition, but you'll need to run mkswap on it.

Thanks, Bitt.

Do I need to have the same size for the partitions on both disks? The destination disk is 40GB while the source disk is only 20GB. Or is it possible to resize it after I have copied the partitions over?

Stig

You could resize afterward, but simpler might be to just do a file-by-file copy, something like this (assuming the new target is /dev/sda in this situation):

mke2fs /dev/sda1
tune2fs -c0 -i0 /dev/sda1
mkdir /new
mount /dev/sda1 /new
mkdir /old
mount /dev/sdb1 /old -o ro
apt-get install mirrordir
mirrordir /old /new
umount /old

## and now the tricky part: try to install the MBR bootloader:
grub-install --root-directory=/new/boot /dev/sda
umount /new

## done

Cheers

Actually, I suppose that if the target (new) drive is larger than the original, it might be far easier to just clone the drive entirely, and then resize the data partition afterwards.

Eg. cat /dev/sdb > /dev/sda ; hdparm -z /dev/sda

This copies *everything*": MBR (boot stub + partition table), partitions, swap space, etc..

Then later edit the parition table and then resize /dev/sda1

Personally, I would do the file-by-file copy though.

For the benefit of a complete and utter n00b, why didn't you suggest bit copying one entire drive to the other i.e. dd if=/dev/sda of=/dev/sdb ?

Because he forgot about the bootloader..

Thanks, Mark.

I'll try this tomorrow.

Stig

I actually almost always put the bootloader on the root partition rather than in the MBR, to the point where I forgot about that possibility. Also, copying partition-by-partition means you can leave out the partitions you don't need to copy, like the swap space, or maybe a data-only partition that doesn't need to be ported, which will save time.

I used the mirrordir method and it worked fairly well, except it took a long time to install mirrordir due to the slow link. And I needed to change the uuid of the disk. I guess I could have used tune2fs to change it on the new disk, but I changed it in menu.lst and fstab instead. And I needed to use tune2fs -j /dev/sda1 to create Ext3 filesystem.

But I have another problem. It seems that when I su to root in a terminal, I can't start any graphical programs. I get a GConf error and orbit-root isn't created in /tmp.

Stig

Any difference with "sudo bash" ?

Again, "sudo -s".

Or in this case, just "sudo gui_prog".

The reason is that when you su, your whole environment is cleared and you're running as a completely different user, which means that your X server authorization is gone. You could get around it, but it's either a security problem or a pain in the ass, depending on which way you go. sudo just changes your euid.

sudo changes both the real and effective uid/gid.

You're right, of course. The main point being that it leaves the existing environment (almost) the same.

The reason I'd like to not use sudo at all, is that these two machines are 'public' machines and if someone knows a little about Linux, they might want to start changing a lot of things and create more work for me, one of the reasons I installed Ubuntu in the first place instead of re-installing XP. I have them set to auto-login, so they won't need the password, so sudo might not be a problem, but I still don't know why starting GUI-progs as root is failing when I haven't had problems with it earlier... Haven't had time to check the previous suggestions yet, though.

Stig

Is DISPLAY set in the environment?
Is "root" authorized to pop up windows on the (other) user's desktop?

Have no idea. How do I check that?

Stig

echo $DISPLAY

If not set, then you cannot open windows. You could try setting it with this:

export DISPLAY=:0.0 ## <<-- must match what original user sees

If it still fails after that, then there's some security or something getting in the way. To prove this, you can do this from either root or the original user:

xhost +

and then try to open the window. But this is horribly insecure for many people. Maybe Bitt can help more here now.

Correction.. it seems that xhost + works only when issued by the original user (owner of the X session). Oddly, the man page suggests we could be safer with xhost +root@, but it doesn't work for me here.

Cheers

It would help to know more about what you're trying to do.

I'm trying to imagine a scenario where you want autologin to an unprivileged user, but also want to display a window owned by root.

The only thing I can think of is that you need to do some local administration and don't want to bother logging in as a different user. To which I'd say, "Don't do that; log in as a different user."

I'm not sure who you're asking now, but in case it's me, I'll answer what I'm trying to do.

We have 2 machines that can be used by anyone onboard, and I would like to secure them a little bit so that the users can't easily mess them up. So I have turned on auto-login and plan to not write down the password on the monitors since then they can do whatever they want using sudo. I have set a root password so that I can su to root in a terminal. I can do some things from the terminal, but some things are easier to do using a GUI, so I would need to be able to start the programs from the terminal. I don't know if this is the correct way to do things, but it's worked up until now...

Stig

Oh.. so just enable root logins in gdm/kdm, and log in as root to a total GUI when needed?

But still, the combination of "xhost + ; su root" will also work. You'll want to remove sudo from the system, though, or at least nuke the normal userids from the /etc/sudoers file.

If they're on a network, you can either enable xdmcp, as Mark suggests (Edit: looking back, that's not what Mark suggested, but it is another possibility), or, even easier, just log in remotely using ssh and its X11Forwarding option, which is "-X" for OpenSSH. You'll have to enable it on the server, too, in /etc/sshd_config, or wherever your distribution might put that config file.

Anyway, once you get ssh's X11 forwarding working (not really difficult), just log in remotely and all X clients will be sent back to your local display. No need to even get out of your chair.

Kind of a pain in the ass when you have an autologin enabled. You either have to log out in such a way that it won't autologin again — in which case you have to remember to either log back in as the autologin user, or just reboot, when done — or you have to run a second X server.

..which is just a simple New Session click from the default menus in (K)Ubuntu.

But he probably ought to remove that option too, as part of locking things down.

-ml

man xauth

I would still need to get out of my chair, because these machines are on a seperate network from my machine, but it's not really a big problem to walk up to those machines if I need to to something. And if I log out, it won't auto-login again, it will stay at the login prompt.

I tried xhost +, but I was root when I did it and I got the same error messages. There was something about failing to read listing pairs in '/apps/nautilus/preferences' when I tried to start Nautilus and a lot of:
(nautilus:28773): Eel-WARNING **: GConf error:
Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash. See http://www.gnome.org/projects/gconf/ for information. (Details - 1: Failed to get connection to session: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.)

I think I tried to edit sudoers when I was home and I seem to remember that would break the system, but it could also have been that I tried removing the user from the admin group that broke the system.

I think I'll just enable root login and tell them to reboot the machine if they log out...

Stig

HAHAHAHAHAHA

You's a funny guy, Roger.

I'm pretty sure we were trying to find the easiest way to do this.