On Wed, Mar 28, 2012 at 9:00 PM, Charles Yost <[email protected]> wrote: > On Wed, Mar 28, 2012 at 7:51 PM, Jordan Uggla <[email protected]> wrote: >> On Wed, Mar 28, 2012 at 10:32 AM, Charles Yost <[email protected]> wrote: >>> On Wed, Mar 28, 2012 at 1:38 AM, Jordan Uggla <[email protected]> >>> wrote: >>>> On Tue, Mar 27, 2012 at 9:28 PM, Charles Yost <[email protected]> wrote: > > Let me start by saying that although your tone could be interpreted as > harsh, I would always rather have helpful harsh criticism, than no > help at all. Thank you again for the time you've spent on this. > >>>>> I am attempting to install grub as the bootloader to a drive image. >>>>> After attempting to use grub-install, then grub-mkimage and >>>>> grub-setup, I cannot find a way to make it work. Can anyone help me? >>>> >>>> What commands did you run, and in what way did they "not work"? (And >>>> for future references this is the type of information that you should >>>> start with when asking for support). >>>> >>>> grub-mkrescue is probably the simplest way to make a bootable disk >>>> image but kpartx and grub-install should work as well (with grub 1.99 >>>> or newer for the kpartx support). >>>> >>> Thanks for the response Jordan. >>> I am using grub 1.99, but I'm not sure that grub-mkrescue will do what >>> I want, because I'm attempting to create a bootable hard-disk image >>> with separate /boot and /root directories. >>> I used dd to create a 1GB image. Then I used parted to partition it >>> with 4 partitions, (partition 1 for /boot, and partition 3 as /) >>> 1049kB-50M, 50M-71M, 71M-547M, 547M-1023MB. Next I used losetup to >>> find a free loop, and losetup $FREE_LOOP disk.img. Next kpartx -a >>> $FREE_LOOP to create block devices for the partitions. I used >>> mkfs.ext3 to format the partitions (such as mkfs.ext3 -b 1024 -L boot >>> /dev/mapper/${FREE_LOOP}p1). I then used losetup --find to select more >>> free loop devices, and used them to mount each partition, keeping >> >> This is where you start to go wrong. The reason why kpartx is >> recommended is because it creates these devices for you, and when you >> use the devices created by kpartx grub's utilities can tell the relationship >> between a partition and its drive. By adding the extra and completely >> unneeded step of creating more loop devices for each partition you're >> making it so that this information is no longer accessible to grub's >> utilities. And since "kpartx -a /path/to/disk.img" will also >> automatically find the first free loop device and use it, I would >> recommend that you don't use losetup directly at all. > > I used losetup to create the initial loop to the disk image, and then > kpartx to create mappings (under /dev/mapper/) for the partitions > within the disk image, and then losetup to create loops back to the > mapped partitions so that I could access the files on them. Do I > understand that I should just be using kpartx for everything? > >> >>> track of which ones I used for which partition. I then write the >>> device.map file using all the loops (eg: (hd0,1) /dev/loop2). Finally >> >> This is also wrong. The device.map is at this point a file which you >> should only use if you want to override the very good logic in grub's >> utilities. By listing a device in the device.map you are telling >> grub's utilities that it is, from the perspective of the firmare at >> boot, a *drive* and nothing more. So if your extra losetup step >> earlier hadn't been enough to confuse grub's utilities into thinking >> that the partitions were separate non-partitioned drives with no >> relation to /dev/loop0, you just explicitly told them that this was >> the case. It may seem odd that device.map accepts device names with >> ',' in them but ',' is actually a common character in device names in >> Open Firmware. Remove the device.map entirely and everything should >> work fine. >> > > Ah, I understand now. I thought device.map was a roadmap to how the > devices would look during booting. > I also misunderstood (hd0,1) to be the same as (hd0,msdos1), which > I've seen used in other places. > >>> I copied in all the files needed (such as all the grub files). For the >>> next few steps I tried several methods. Method 1: using grub-install >>> from the host directory, then chrooting into the mounted image and >>> using grub-mkconfig (eg: --modules=serial >>> --boot-directory=$BOOT_MOUNTPOINT --root-directory=$ROOT_MOUNTPOINT). >> >> --root-directory and --boot-directory actually control the same thing. >> People were confused and limited by the semantics of --root-directory >> and so --boot-directory was created and --root-directory only exists >> for backwards compatibility. In short, if $BOOT_MOUNTPOINT was the >> same as $ROOT_MOUNTPOINT/boot then it shouldn't have caused any >> problem, but removing the --root-directory option will not hurt >> anything and will be more clear. >> > > $BOOT_MOUNTPOINT = The first partition > $ROOT_MOUNTPOINT = The third partition > Only after linux boots does it mount the first partition at /boot > If I understand correctly I should remove the --root-directory option anyways. > >>> Method 2: Â Copying in the GRUB images from /usr/lib/grub/i386-pc, then >>> using grub-editenv to create the grubenv file, then grub-mkimage to >>> create the core.img ($ROOT_MOUNTPOINT/usr/bin/grub-mkimage >>> --directory=$ROOT_MOUNTPOINT/usr/lib/grub/i386-pc --format=i386-pc >>> --output=$BOOT_MOUNTPOINT/grub/core.img --prefix="(hd0,msdos1)/grub" >>> biosdisk ext2 part_msdos serial), then grub-setup (eg: >>> $ROOT_MOUNTPOINT/usr/sbin/grub-setup --directory=$BOOT_MOUNTPOINT/grub >>> --device-map=$CREATED_DEV_MAP "(hd0)") >> >> grub-install is really the only way to go when installing grub. If you >> can't get grub-install to work then it's *very* unlikely that you will >> be to do anything worthwhile manually. >> > > Ok. I will be sure to just use grub-install from now on. > >>> Neither of these methods worked. GRUB starts up, says "error: no such >>> disk" and then dumps me to the rescue prompt. And if I enter 'ls' it >>> shows no disks. >>> I hope I didn't leave anything important out. >>> Thanks, >>> => Charles Y. >> >> Though reading through what I wrote above I've realized that it may >> sound like harsh criticism, all of the mistakes you've made are >> actually very common and understandable and I will try to add notes in >> grub's documentation about these common pitfalls. >> > > I will make the alterations and see if I can get the image to boot. >
Progress has been made, I think, but the image, when copied on to disk, is not booting. It displays: (error: no such device: 69ee516d-d9b4-4075-84e4-8d71d31f3061) I don't have any partitions with this block id on the system I used to create the image, so I can only guess that it was the block id of the device created by kpartx? It then dumps me to the rescue prompt. When at the rescue prompt, I can type ls and it shows (hd0), but insmod normal produces: (error: unknown filesystem.). What should I try next? => Charles _______________________________________________ Help-grub mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-grub
