Back in the days of init I often rsync'd a working OS partition to a different partition, edited fstab and presto! it ran.

Now that systemd has been imposed on us to confused and befuddle things, this doesn't work. Some other magic setting in systemd seems to be required. Does anyone know the correct incantation?

More likely is you broke your bootloader.

i have done similar things with systemd installations, so maybe something else went wrong?

What settings on rsync are you using? Out of habit, I usually use rsync -tvlr --delete, but this doesn't seem to copy over special files properly. The result is something that actually boots - it even gets to an XFCE4 desktop (Debian 8 Jessie with systemd). But all sorts of things don't work right, and I can't su to root.

In my case, I just use cp -vax instead of rsync to get those special files (rsync -tvlr --delete is okay for /etc and /home, among others).

But I'm curious what rsync settings will work as well as cp -vax. Thanks!

Much appreciate the replies. I wasn't sure whether it was a simple fix, a stupid error on my part, or just a lack of knowledge and confidence, so thought I'd post just to check.

> i have done similar things with systemd installations, so maybe something else went wrong?

Most valuable: it confirms that the thing is do-able. I've now set up an old machine with a dozen small partitions and will work through the process in greater detail.

> What settings on rsync are you using?

Just rsync -a SRC DEST but I think this is where the problem lies:

> More likely is you broke your bootloader.

I've been using a mixture of REAL Grub and GRUB2 with chainloading to partition boot sectors. The problem is likely here, and I'm grateful for the tips to have localized it quickly..

Thanks to all!

Thanks! I have found my new favorite rsync settings for this sort of thing:

rsync -vax --delete --exclude tmp --exclude home/user/bak /. /mnt/nfsroot/

-v = verbose (I like to see the progress)
-a = archive (preserve most things, such as owner, permissions, special files)
-x = don't cross into other file systems
--delete = delete files from the destination if they don't exist (any longer) in the source
--exclude tmp = exclude /tmp folder
--exclude home/user/bak = exclude /home/user/bak folder

Basically, this makes it copy over just the stuff I want. The bak folder in this example is a big folder full of stuff that I'm not copying over via this process.

Note that in this example, the source partition is the root of the currently running system. That's why I have to restrict it from crossing over into other file systems to do a proper partition copy.

Anyway, it works. But of course it doesn't do anything to install or update grub2.

A nicely detailed example. I'm working with a newly mkfs'd DEST and an unmounted SRC, so the safeguards aren't needed. In my case the crucial questions relate to the contents of partition "boot sectors", which these days I believe can be several sectors, and being binary data are unintelligible to all but the Harry Potters.

I've never investigated nor understood the consequences of invoking, for example ># update-grub /dev/sda6 from /dev/sda2 - does it search /dev/sda6 for a working OS and modify that boot sector accordingly, or does it (pointlessly?) modify it with the parameters for /dev/sda2? Some mysteries must ever so remain.

I'm not really an expert on grub/grub2, although I did pretty much get the hang of grub back in the day. (My working knowledge on the earlier grub is stale from years of disuse.)

I'm not positive, but I don't think update-grub /dev/sda6 is a thing. I mean, maybe? But I've only ever run "update-grub" by itself with no device name. Doing "man update-grub", I see that it's just a stub for running:

grub-mkconfig -o /boot/grub/grub.cfg

Basically, it constructs grub.cfg from various settings and scripts. Typically this will include a step where it searches for other OS partitions to add menu options for them. It then writes the results to /boot/grub/grub.cfg, which is wherever the currently mounted /boot/grub is. Whether or not any boot loader points to this is neither checked nor rectified.

I think you're thinking of "grub-install", which will typically be invoked something like:

grub-install /dev/sda

This will install the grub bootloader to sda's boot sector, and I think it will try and do stuff to make it point to the currently root partition (or /boot if it's a different partition). If you want it to point to a different partition, you can chroot into the alternative root partition. I'm not sure how this part works, whether it's by UUID or partition number pair, or combination.

To reduce confusion, I have always avoided weird chain loading. My preference is to just have the grub bootloader on a drive (not partition) and have a single /boot managed by a single OS take care of things.

> I have always avoided weird chain loading.

OK, so we're coming at this from different directions. I used Gentoo for years until they changed to systemd, then bought a DVD set of Debian 8.2, set up my own on-disk repo, and now use that exclusively.

But back in the Gentoo days I used REAL Grub (grub-legacy) and was quite happy editing its grub.conf to load other partitions, on which I installed the latest versions of whatever distros took my fancy. I quickly realized that most were soon using Grub2 (the Impostor) which uses funky, confabulated scripts to generate god-knows-what, so I took to using - as you suggest - grub-install /dev/sda7 or wherever it was. I then used chainloading to boot these weirdos and it all worked fine. There's one trick you need to know:
Note that makeactive is commented out for sda10, since it's only needed for primary partitions. Use it on an extended partition and it hangs. Apart from that everything was hunky-dory until I moved to a new machine and lost the old setup. I've not yet found the time or patience to plough through the Grub2 docn, especially as the younger generations seem to have lost basic English and can't (or won't) write competent documentation.

Therein lie the roots of my present dilemma.

As an afterthought, I've considered using dd to copy partitions, since this would presumably copy the boot sector(s) along with the rest. Never had time nor patience to pursue it, but maybe one day ...

I use dd all the time, as it will reliably reproduce a dual boot Windows/Linux drive. I generally use it to clone drives, not partitions. If you clone just partitions, then it won't copy the boot sector, or anything other than just the partition. But anyway, dd is much easier and simpler than the crazy stuff you've been putting yourself through.

For that matter, learning grub2 is easier and simpler than the crazy stuff you've been putting yourself through. I don't really understand your resistance to grub2. I have had fewer headaches since grub transitioned to grub2 than I had back with legacy grub. It uses UUIDs by default, so it's pretty robust with respect to when hard drives are moved. It's a pretty sweet deal when you install to USB thumbdrives as much as I do. They tend to get the last drive number...or first, depending on whatever the heck the BIOS does with respect to boot priority. Ugh. What a nightmare that was, especially with PATA vs SATA vs etc...

Besides, all of the up to date documentation you'll find on the internet about using grub for various things are for grub2. I personally just want to get things to work, and I'd rather have the help of the internet's resources than try and figure everything out on my own. So I use grub2.

Not that I'm opposed to figuring something out on my own if I have to. For various reasons, I wanted to figure out how to make a custom grub2 entry to boot with an nfs root. No PXE or tftp server setup; no custom DHCP setup. Just an nfs server and a custom grub2 entry (/boot on a local partition). It took me some wrangling, but I figured it out and I'll be posting a HOW-TO soon. But I'm only going to post this HOW-TO for grub2. It's already a niche problem that 99% don't care about. Doing it for legacy grub would be a ridiculously small niche within a niche.

1 members found this post helpful.

> then it won't copy the boot sector, or anything other than just the partition.

Interesting. I've always viewed the boot sector as being PART of the partition, and the fact that dd skips it points to a hole in my understanding of what's going on.

> the crazy stuff you've been putting yourself through.

Probably a matter of what you grew up with and are used to. In any case I'm a renegade heretic: I've been running as root on Lx now for sixteen years without a worry in the world, despite the shrieks of horror I get from religious fundamentalists when I confess to it. A hangover from the DOS days (DR-DOS 5.0 was my favourite). It's MY machine, I want FULL control of it, and I don't need anyones "permissions" to do as I like. The rest of them can live in fear of "terrists" if they want.

> I don't really understand your resistance to grub2.

I'm a fan of simplicity and human-readable config files. Booting's such a simple process I see no need to confabulate it with a mess of scripts.

> It uses UUIDs by default

Don't like them, and always edit them out in fstab. If the swap partition gets clobbered and recreated, my Debian sits there for two minutes at boot puzzling over it. Yes, the enumeration business has complicated things no end, but once again this is a product of people wanting everything "automatic" instead of just editing a few simple text config files.

We've got two different philosophies about how things should be, and I've long been resigned to being on the losing side, since the creeping corporatization of Lx and the Inet is part of the TransNational Corporate agenda. I'm not alone in my dislike of this: a chap called Linus Torvalds frequently rants against it:

http://www.phoronix.com/scan.php?pag...tem&px=MTY1MzA

... Theodore Ts'o is much more polite but still critical:

https://igurublog.wordpress.com/2014...ainst-systemd/

... and Julian Assange is warning that even Debian is now compromised, especially after they did away with Ian Murdock and Debian prompted signed a deal with Micro$oft:

https://igurublog.wordpress.com/2014...ed-by-the-nsa/

Neither compromise nor resolution is possible: just have to live with an imperfect world. And here's what's coming next:

http://www.cnx-software.com/2016/08/...Development%29

I forgot that it's also possible to put a boot loader in a partition's VBR, rather than just the MBR of the drive itself. It just makes life more complicated, which is why it makes sense to avoid it if possible. But if you aren't avoiding it, then using dd is the most elegant and simplest way of dealing with it.

Since you want to be able to control what's happening when you copy from one partition/disk to another, you really should learn dd. It's a very simple low level tool that lets you copy a byte range to another file or device (you also have an option to copy a byte range to another byte range, for more specialized tasks - such as ONLY copying a boot record or ONLY copying a partition table from an image).

If you don't like dealing with UUIDs and swap, take a look at setting up swap file instead of swap partition. A swap file is a lot easier to resize later on, although admittedly it can make things more complicated on a complex multi-boot playaround machine where you want all OS's to share the same swap. If you set up a swap partition referenced by device enumeration, you're going to have problems whenever that enumeration gets confused (adding/removing a drive, drive order messed with because of how the BIOS handles thumbdrives, or PATA drives, or whatever). Basically, you're making a lot of new points of failure, so don't be surprised when it bites you like it did in this instance.

You might think it's silly that people (like sysadmins) prefer to have boot from a USB drive work without manually editing grub.cfg from a different OS (or on a different computer, or disconnecting internal drives on the subject computer), after figuring out what device enumeration it will be, and then remembering to manually edit it back before booting out, but ... well, I dunno. I'll never go back to the bad old way of doing it, that's for sure.

I think grub2 is simpler and more human readable, given the complexity of a task you want to do with it. Everything's still in grub.cfg if you want to read what it's doing.

i'm sorry, but you are seeing problems as to the opriginal post of your thread which are not related to systemd, as i think we now confirmed.

you yourself are giving the answers in this last post: not using uuids, using "a combination of real grub and grub2" (how is that keeping things simple? why not just use syslinux or lilo?) and insisting on running everything as root.

fair enough, why not, it's your system.

but then you start serious namedropping to support your attitude, saying these people share the same "philosophy", but you only provide links that fuel the ongoing systemd discussion.

which has nothing to do with the problems you are having atm.

whatever.

Tsk! Tsk!

Disobeying the High Priest!

A SINNER!

STONE HIM!!!

erm, did you actually read my reply?

or are you in full adrenalin powered systemd resistance mode now?