"Mike Edenfield" <kut...@kutulu.org> writes: > > Yes , of course it's /possible/, it's just not /practical/.
Perhaps, but still? I don't se how that is less practical than collecting them to a ramdisk? Just do exactly the same steps up to the "cpio | gzip" -part I do agree with most of what you say > > Most Linux users, by a vast but very silent majority, are plenty happy to > put / and /usr on one partition, wipe their hands on their pants, and move > on with life. Thus, the people developing and packaging those required boot > packages can leave them right where they are, and everything works. I agree with that. > Some > Linux users have reasons (largely legitimate ones) why this is not a valid > option. Those users have three choices > > * Move the required packages away from their default installation locations > on their machines, as you're suggestion, and fix the order of your boot > scripts to mount /usr earlier than anything that needs it. > * Install (or develop) alternative versions of the tools that do not have > the same boot-time requirements, thus allowing you to ignore the whole mess. > This is what Walt and his mdev team are making happen. > * Use an initramfs to do whatever specific thing your machine(s) need to do > to make the rest of the software work out-of-the-box. > > So, it's not a matter of one choice working and one not. It's a matter of > one choice being much lower maintenance for the people donating their time > to produce the software in the first place. Yes, that is a very valid point. > If someone (maybe you) were to > figure out the actual steps needed to mount /usr early in the boot, without > and initramfs, without swapping out udev for busybox or whatever, I'm sure a > lot of people would be interested in seeing how that's done. There's a > possibility that it turns out to be way easier than anyone thought, and that > supporting a split /usr becomes "no big deal". In practice, I'm going to > guess that it turns out to be a way bigger maintenance nightmare (and > probably more fragile) than: > > root # emerge dracut > root # dracut -H That's probably the way I'll proceed when I update udev later. But I'll wait a while longer before doing that. I'll going to miss the posibility of starting a kernel with only init=/bin/bash for rescue purposes. But it's not a big deal. > > And probably won't be something that the developers or package maintainers > are going to commit to supporting. > > --Mike Thanks Mike. This is my migration-plan Today I have two disks with both three partitions sda1 / -- sdb1 reserve-root. Regulary rsynced from sda1 sda2 swap -- sdb2 swap sda3 lvm -- sdb3 lvm sda3 and sdb3 is combined to the volume-group vg0, and I have all my other filesystems in vg0. I'm planing to create a vg0/root and copy the contents of / to that, and later remove everything but /boot from the old / How does that sound? -- Christer
