I'm having a problem installing and booting a 13.37 kvm guest ( -current as of 30/3/2011 ). Considering that the -current images support virtio, this should be straightforward, but the install proceeds normally until the lilo install ( to mbr ) at which point there is a complaint about /dev/sda not existing. Well it wouldn't because /dev/vda is the partitioned/installed disk.

I then tried to install from the prompt:

Had a problem with lilo so added the following to lilo.conf:

and reinstalled lilo successfully this time ( albeit with a few moans and groans ). Now boot fails with:

Tried booting with:

Linux root=/dev/vda2

... but no go. Same message as above but "vda2" this time.

Help?

Robby

before installing lilo manually you should do a
EDIT: tested it now and still doesn't boot with the huge kernel.

you can do it by booting with the generic kernel and an initrd.

first I changed the above with
the last mount command is not needed if you just finished the install -it's already mounted- but it's needed in rescuing.

run
it should give you the command line to run for generating the initrd.
add it in the lilo.conf section for your OS, re-run lilo, exit and reboot

I think it's necessary to use the generic because the huge kernel doesn't have built in statically the virtio modules so it can't find the disk at boot.

Hi Ponce, thanks for the response. I'm having some trouble with these instructions though. I've done the following:

normal boot from dvd ( without specifying root=/dev/vda2 )
mkdir /mnt/dev
mkdir /mnt/sys
mkdir /mnt/proc
mount -o bind /dev /mnt/dev
mount -o bind /sys /mnt/sys
mount -t proc proc /mnt/proc
chroot /mnt

At this point I get a "chroot: can't execute /bin/sh No such file or dir" error. Originally I had used:

/mnt/usr/sbin/lilo -r /mnt/ -C /etc/lilo.conf

... to take into account that the filesystem was below /mnt. Stumped ... If huge has virtio support, statically or not, then shouldn't it support a virtio installation?

Regards, Robby

You forget to mount the root filesystem first, under /mnt :
Eric

Thanks Eric, I suppose that would help ... that's done the trick. 2 questions:

1. why during lilo installation ( with a normal install ) does lilo think it's installing to sda when it should install to vda?
2, any chance of getting 13.37 to install as a kvm guest without these extra requirements? ( I presume the virtio mods would need to be compiled into the kernel that is installed at installation time - is this different from the iso image's boot kernel? )

Thanks for the help Ponce and Eric

You probably tried to install Lilo automatically; This considers a few defaults (among which /dev/sda); You would need to install it with expert mode, or edit lilo.conf (and run lilo) afterwards.

Also, it is necessary to have the modules loaded prior to the mounting process; Hence, you need it as a initrd.gz. The virtio modules should be loaded. This is the case with a default kernel, naturally you can compile these modules into your own custom kernel, but that may be a wee bit more work :-)

There are a few cons (as well as some pros) to this:
1) it would only work for kvm guests; So, there'd be issues with VirtualBox, VMWare, Xen and what not that use other methods / modules, in some cases even conflicting.
2) It presumes that Slackware should do the thinking for you. That's not Slackware-style. You do some good and logical thinking, and you get the most freedom whichever direction. Consider this "learning Linux", you now learn what is really required to get something done, rather than being led by a menu and no clue of what's actually going on on your machine.
3) Think of the memory footprint for a fairly small amount of people that would use the capability. How many Slackers run kvm-based virtual machines? All those others don't need that in their kernel. Think KISS and you're happy with how things are now.

They were during installation otherwise /dev/vda and networking would not work. This leads me to think that the installation boot kernel image is different from that which is installed to disk.

Ah there's the rub ... I wonder how RHEL/Centos/SL do this though - they work with both kvm ( server and guest ) as well as vbox and others ( of course you choose kvm or zen during install, but vbox can run later if you've chosen kvm, one simply blacklists the kvm mods )

Not necessarily. There's a certain amount of functionality that is already provided in the installer and it wouldn't be a stretch to have other functionality. For eg. what is the diff between having your mouse setup ( as currently done ) and setting up an additional user ( after root ). Someone has made a conscious decision in terms of what goes into the installer ( and kernel ) - that doesn't mean SW is thinking for you, it's simply a convenience. Another example is that btrfs is now available to format non-boot partitions with. Convenience ... and KVM could be another convenience. All these don't mean that SW is any less than what it has been in the past. There's already a lot done in the installer that probably very few understand, certainly setting up lilo ( currently done ) could arguably be construed as being as easy or complex, as setting up SW as a kvm guest.

Good point ... but I think more and more Slackers might be running VMs lately - it's a fantastically useful tool.

My 2 cents worth.

That's correct: for the installer to "guarantee" to work as much as possible, there's a huge kernel used with (almost) everything compiled in. This makes for a bloated kernel, which is no issue for an installer, but is for a live, running system.

They have more people as well as a bigger income due to an "enterprise" edition you have to pay for as well; They (probably) have various different kernels compiled, of which one is chosen (as default) based on what you state in the question listed. But this may mean you're more or less fixed on that choice. Less freedom.

It is! I do so very often, for one; but that you do and why you would do it is very specific. Besides, the current setup allows for the greatest amount of freedom: you choose what you want and how you want it. I find it quite easy to setup kvm-qemu with Slackware both as host and guest. Even switching disks from virtio to ide; I used to setup the systems with IDE as disk interface; At a later point I decided to use virtio disks (since it became available), which required some steps to take afterwards.

I think they are the same.
That is because the kernel of the installer doesn't need to boot from /dev/vda but it detects it after booting loading the appropriate module (and like that for networking).
The panic manifests when you have to boot from the virtio device, but that's the reason the initrd is there for

Thanks all for the info. Thought I'd include screenshots of my initial boot. It still includes some details about fc02 instead of vda2 - I think this has something to do with lilo and non-std devs - maybe someone can chirp on the subject ( nothing in google )?

Attached Thumbnails