View previous topic :: View next topic |
Author |
Message |
paradigm-X Apprentice
Joined: 19 Sep 2013 Posts: 168
|
Posted: Thu Nov 28, 2013 2:18 am Post subject: handbook oversight with Grub and virtio disk |
|
|
On this page of the handbook, http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=10#reboot, in the step at code listing 2.6, which points out how to modify the "normal" procedure if a virtio disk were being used for installation, this is shown:
echo "(hd0) /dev/vda" >> /boot/grub/device.map
Then, in the very next step (i.e. code listing 2.7) this following is shown, which now fails to take account of the aforesaid virtio device:
# grub-install --no-floppy /dev/sda
However, it would fail to install correctly if the virtio disk were being used, in which case it should be made like so:
# grub-install --no-floppy /dev/vda
Perhaps it should be noted although most everyone using a virtio disk at this point would probably catch the oversight. |
|
Back to top |
|
|
miket Guru
Joined: 28 Apr 2007 Posts: 488 Location: Gainesville, FL, USA
|
Posted: Sun Dec 01, 2013 2:24 am Post subject: Re: handbook oversight with Grub and virtio disk |
|
|
Actually, I think you're getting a bonus by having the handbook mention virtio disks at all. Normally the handbook addresses pretty much straight-ahead normal cases with the hopes that guides for more specialized setups point you to the handbook except for how the specialized setup diverges from the handbook.
The sdX series isn't even the only one possible for actual-hardware fixed-disk devices. Before SCSI and friends were so popular, we'd think more in terms of hdX. If you are setting up a really old machine with IDE drives even nowadays, you set up partitions on /dev/hda. Virtio's vdX is just a different kind.
For use with KVM, I generally avoid using a boot loader at all. Qemu lets you specify kernel, command line, and even initrd from the command line. The setup I posted at https://forums.gentoo.org/viewtopic-p-7444096-highlight-.html#7444096 starts an KVM instance that way. |
|
Back to top |
|
|
paradigm-X Apprentice
Joined: 19 Sep 2013 Posts: 168
|
Posted: Sun Dec 01, 2013 3:15 pm Post subject: |
|
|
You're right, come to think of it, that is a bonus! I was only thinking in terms of consistency: it's better to finish what you start, than to leave it like it was. But I would agree, it was an anomaly to see it at all, and the sooner we got back to the norm, the better.
Hey, that link you posted was great because I was even wondering about how to use the feature of booting directly into the kernel, but I had put it off while I was working on some bigger issues with KVM, which are impeding my progress. They don't call them (prior)ities for nothing. Anyway, I must have overlooked it the first time around. Time for a closer look now at your list of gems.
But while we digress from the original topic, I want to take this moment to bring up another issue in relation to KVM booting. It is good to have the kernel and initrd on the host for a number of reasons, not least of which is the security considerations, among others. I mean, I need not worry about malware on the guest trying to subvert the kernel. then again, I am now left wondering about how LUKS encryption on the guest might play out with this method of booting? I have to give it a test now to work it out. Thanks again. |
|
Back to top |
|
|
miket Guru
Joined: 28 Apr 2007 Posts: 488 Location: Gainesville, FL, USA
|
Posted: Mon Dec 02, 2013 7:41 am Post subject: |
|
|
paradigm-X wrote: | I am now left wondering about how LUKS encryption on the guest might play out with this method of booting? I have to give it a test now to work it out. Thanks again. |
Actually, by this time, you might indeed need to think in terms of setting up a bootloader in your image. For the cases we'd been talking about before, where the big thing is getting the VM started and not worrying about how to work out kinks in the boot sequence, supplying the kernel image and so on from the qemu command prompt is a good deal. As you point out, it also has the advantage of making it so the guest can't change it's kernel image or initrd.
On the other hand, when it comes to using KVM to test booting techniques for eventual deployment on a bare-metal host, you'll need to go the whole bootloader route (you have LUKS in mind right now, and I'm looking at trying an emulated UEFI setup using OVMF: http://www.linux-kvm.org/page/OVMF). If your goal is to apply encryption to a KVM guest image that you intend to run routinely from a host, you *might* still get by with kernel and initrd in the host file system, but I don't know if that would be advisable. I don't know enough about LUKS to know for sure.
I do know this, though: what you described in the Handbook documentation needs to be reported as a bug. Here's a great chance for you to meet the Gentoo bugzilla (https://bugs.gentoo.org). I checked to see if there were any open bugs in the documentation mentioning virtio, and there are none. There are two closed bugs that are relevant: 384117 and 467034. That latter one is the one that echo "(hd0) /dev/vda" >> /boot/grub/device.map line into the handbook. You ought to open a new bug pointing out what is missing--and be sure to reference those two earlier bugs. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|