SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I was just wondering if there are plans to add to the installer support for virtio hdd ( /dev/vda ) since 13.37 did not , I tried to install the 14 but unfortunately seems thing have improved a little but not by much.
1) the installer has virtio support but lilo fails to install
2) I edited the lilo.conf adding
Code:
disk = /dev/vda boot=0x80 max-partitions=7
and added the relevant linux installation , the lilo fires up some warning like "Waring: /proc/partitions references Experimental major device : 252" but it does install
3) the stock kernel though fails to see my disk and dies orrible death with :
Code:
VFS:Cannot open root device "fc02" or unknown-block(252,2)
I know it can be done afterward recompiling kernel and such since I have a slackware 13.37 up and running on virtio , tough the question arise ... how come the installer has virtio support when the stock kernel does not ? am I screwing something obvious ?
You probably did something wrong. The installer has virtio support, but you still have to create an initrd because all virtio support of the kernel has been implemented as modules.
In the installer, you could run "chroot /mnt" after completing the installation process. Then in the chroot, run
Code:
/usr/share/mkinitrd/mkinitrd_command_generator.sh
which will show you the correct command to run in order to create that initrd.gz file with virtio modules included.
Don't forget to update /etc/lilo.conf and re-run lilo.
Just great, using your posts I successfully fixed my boot issues ("disk = ..." in lilo.conf and added virtio modules to initrd.gz).
I have another issue(???). I cannot boot HUGESMP.S kernel from the install ISOs (mini and current) and the huge-smp / gen-smp kernels from the installed Slackware 14 RC3. Each time the boot process stops in the very beginning:
Code:
Loading Slackware-hsmp .......................
BIOS data check successful
Decompressing Linux... Parsing ELF... done.
Booting the kernel.
What are the parameters you pass to that script?
In order to boot off the ISO, BOOT_DEV="c" would be wrong. Also, the Slackware installer will not understand the virtio block device- unless you manually load the virtio drivers you need (the modules are available in the installer).
I don't load any virtio driver at boot. But I had to mention explicitly that HUGE.s boots with no problem, that is how I managed to install the guest Slackware 14 RC3. Also, on the installed guest OS I can boot only the non SMP kernels. The SMP ones stop at the same line (Booting the kernel.)
So, I installed using HUGE.s. Firstly, after reboot (started the QEMU script with no params) I finished with a kernel panic because of the missing virtio modules. I fixed it with:
1. Boot again HUGE.s
2. mount /dev/vda1 /mnt
3. chroot /mnt
4. Added virtio and ext4 modules to initrd.gz
5. Modified lilo.conf
6. exit (to leave chroot /mnt)
7. lilo -b /dev/vda -C /mnt/etc/lilo.conf
And I successfully boot with non SMP kernels (generic and huge). I have network (after loading of other 8139 driver), start KDE.
But huge-smp and generic-smp stop at the mentioned line.
In the installer, you could run "chroot /mnt" after completing the installation process. Then in the chroot, run
Code:
/usr/share/mkinitrd/mkinitrd_command_generator.sh
which will show you the correct command to run in order to create that initrd.gz file with virtio modules included.
Don't forget to update /etc/lilo.conf and re-run lilo.
Eric
First of all thank you for the reply Eric, and sorry for the lack of answer but I ve been away with family and all ;-)
I never messed with initrd since I normally rebuild my kernel to match only the needed stuff ( and I build driver and filesystem static ) , though I want to try it , only one question since I like to slack ;-) this is what I Did :
I rebooted with the Slackware64 Install CD
Code:
mount /dev/vda2 /mnt
mount /dev/vda1 /mnt/boot
chroot /mnt
now I did run the command
Code:
/usr/share/mkinitrd/mkinitrd_command_generator.sh
and got this :
Code:
find: '/sys/block' : No Such file or directory
cat: /proc/bus/input/device: No such file or directory
cat: /proc/mdstat: No such file or directory
mkinitrd -c -k 3.2.27 -f -r (IN /dev/vda2 -u -o /boot/initrd.gs
The first part I think is due to the fact I did not boot with this filesystem so the proc wasn't populated
Though the command seems to have a syntax error in "(IN" so I deleted the "(" and ran it :
Code:
cat: /proc/partitions: No such file or directory
cat: /proc/partitions: No such file or directory
21019
/boot/initrd.gz created
Be sure to run lilo again if you use it
if I try to run lilo nonetheless :
Code:
fatal: do_disk: stat /dev/vda: No such file or directory
and although the system boot with the initrd.gz it goes really bad he he, now I m sure this is all out of ignorance though is it possible to avoid re-run all the installer ;-P
before doing the chroot you gotta make some stuff from the boot system available also to the chroot environment.
execute these commands (before the chroot)
Code:
mount -t proc proc /mnt/proc
mount -o bind /dev /mnt/dev
mount -o bind /sys /mnt/sys
before doing the chroot you gotta make some stuff from the boot system available also to the chroot environment.
execute these commands (before the chroot)
Code:
mount -t proc proc /mnt/proc
mount -o bind /dev /mnt/dev
mount -o bind /sys /mnt/sys
when you get out of the chroot, don't forget to
Code:
umount /mnt/sys
umount /mnt/dev
umount /mnt/proc
Well it did improve mi situation though I still had some more error during boot , so since a new rc got out I simply did it at installation time as Eric suggested and am I and running..
I have another issue(???). I cannot boot HUGESMP.S kernel from the install ISOs (mini and current) and the huge-smp / gen-smp kernels from the installed Slackware 14 RC3.
Just to close this open question:
I changed -cpu parameter in the QEMU script using:
Code:
-cpu host,-nx
This removes 'nx CPU flag'. Now I can boot all available kernels (ISO and guest OS).
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.