On Sat, Jun 25, 2016 at 09:59:55AM -0700, Paul Rogers wrote:
> Once I make a LFS system, I want to make it clonable. As I've finally
> made an x86-64 LFS, that means I'll likely want to clone it to a box
> with only 32-bit LFS as host. I've never had to deal with this
> transition before, and even with a rescue disk, I'd rather ask than have
> to resurrect a screwed-up drive.
>
> Clearly I can't use the 64-bit GRUB programs, but it seems maybe that's
> NOT necessary. Say I've got 32-bit GRUB-1.xx on the host. It seems I
> could point it at the new GRUB, --directory=/mnt/usr/lib/grub/i386-pc,
> then what ("all") it has to do is write the drive's MBR with the code it
> finds there, and copy what's there to --boot-directory=/mnt/boot/grub on
> the destination partition, none of which should require running any of
> the 64-bit code. The directory name even suggests the boot code isn't
> 64-bit code, only the system utilities.
>
> Am I right? Does this work? TIA.
I think it is a very long time since anybody last mentioned
grub-legacy. The details are so different that I would expect a lot
of pain trying to mix versions of grub.
Let's try to work out what you need to do:
What I do when I've got a new machine is to use a SystemRescueCD to
install the new system (my backups are on nfs so I can access them
from the rescue environment), and then chroot to the new system to
install grub.
You cannot chroot from 32-bit to 64-bit. If you use SystemRescueCD,
I think the chroot invocation needs to be preceded by
'SHELL=/bin/bash' - otherwise it errors because its default is zsh.
The following is untested (I no longer have a machine capable of
running 64-bit with any 32-bit systems : the one where I had been
doing that died). So, Caveat Lector!
(i.) Load /mnt/lfs from 32-bit AND copy the kernel to the existing
/boot partition.
(ii.) Add the 64-bit system to the existing /boot/grub.lst.
(iii.) Attempt to boot the new system. If grub-legacy doesn't boot
it, the process is probably broken so give up on these suggestions.
(iii. a) You might find that grub loads the new kernel and transfers
control to it, but the kernel config is unbootable, e.g. missing
driver. If so, fix it on the build machine aand reinstall, or use a
Rescue CD to chroot and rebuild the kernel.
(iii. b) You might have to change user IDs if your new ID doesn't
match what you used to use (LFS now starts at 1000 or 1001, I keep
the old 500 UID which worked for me on Mandrake-7).
(iv.) If it did boot, check the old 32-bit still works. Make a
backup (of both, and current /boot) just in case the next step
trashes things : if it does, you WILL need a rescue CD (I think we
established that your systems probably cannot boot from usb).
So, it turns out I *am* recommending that you burn a copy of
SystemRescueCD and test that it can boot the new machine: if you
have a dhcp server, it should manage to get an address even though
messages may suggest otherwise - use 'ifconfig -a' to find out, it
will probably use the weird enXpsY beloved of fedora and systemd
which is good for consistency when you have multiple network
adaptors.
(v.) Boot the 64-bit system, go to the book's section on Using GRUB
to setup the Boot Process.
Run grub-install as in the book
Then start by looking at what grub-mkconfig thinks is going to work.
grub-mkconfig -o /boot/grub/grub-auto.cfg
(I put it in /boot so that it is still available for reference).
That probably contains a lot of junk (rescue modes, all kernels for
all systems, perhaps a lot of weird grub module loading which might
be unnecessary).
Compare that to the book's instructions for installing grub. Write
your own grub.cfg ensuring both/all systems are listed.
Reboot, try both/all systems starting with 64-bit. If the 64-bit
doesn't boot, use the Rescue CD to chroot and edit grub.cfg. I
would keeep copies of previous semi-good versions whilst I was
removing things which I thought were unnecessary. Repeat until all
is good, make fresh backups for whatever filesystems got changed.
Probably, change perms on grub.cfg to 644 at soem point, to make
editing it less annoying.
Good luck!
ĸen
--
Yes, you CAN fool most of the people some of the time.
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Do not top post on this list.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
http://en.wikipedia.org/wiki/Posting_style
