Link to home
Start Free TrialLog in
Avatar of Emre Yavuz
Emre Yavuz

asked on

Booting qemu VM from /dev/hda instead of /dev/sda1

Hello,

I am trying to update my old VM installation. I updated the kernel to 4.4.0 and ubuntu 16.04 LTS. However, this VM is being used by old programs which I cannot change its code it's out of my control right now.

I am running following command to run my new VM.

Command with new VM: qemu-system-x86_64 -hda <hard-drive> -smp 16 -m 10G -kernel <my-bz-kernel> -append "root=/dev/sda1 console=ttyS0" -enable-kvm

However, in my old VM installation everything was same except, -append part.
Old command: -append "root=/dev/hda console=ttyS0"  

I want to my new ubuntu 16.04 LTS installation can be booted from /dev/hda as well not only /dev/sda1.

I already tried to change /boot/menu.lst file and /etc/fstab but my tries wasn't successfull. Maybe I am doing something wrong


Please help

Thanks a lot
Avatar of noci
noci

/dev/hda is an old name for devices claiming the device type to be (P)ATA.
later kernel build could access ata disks like all other disks (scsi, iscsi, sas, sata, sd, fc, usb, ... )
/dev/sda1 is booting from partition one of the first disk. (/dev/sda)

Did you try /dev/sda instead?... It does require the bootblock of the disk has the right code inside, and
that /dev/sda1 partition is marked the active partition.
Avatar of Emre Yavuz

ASKER

I mean the thing is there are codes out there which I can't change. I can't try /dev/sda.

It's hard coded as /dev/hda, that's why I want to boot it from /dev/hda not the /dev/sda. Do you think is it possible? I can recompile kernel if it's necessary but not the I can't change how I booted the VM. It's already /dev/hda :S
BTW the command line is passed AS is to the guest VM, it is data for the guest VM. It doesn't matter if the device is externally call something else..
If this is an image from an old existing system (expecting /dev/hda), the why not put /dev/hda on that command line?  Has it been tried?...
Depending on he /dev filesystem used you can add /dev/hda to symlink to /dev/sda if needed.

Not a lot of stuff will depend on /dev/hda mostly it only is a reference in /dev/fstab  specifying that the /dev/hda should be mounted on /.
If you can change fstab and boot options, i would suggest switching to uids.

If you cannot, creating a symlink and other hacks should be feasible by building a custom initrd
Noci, no this is newly build image. I can control image but command line argument is constant it can't change. Software which run the VM with that command is the legacy and I cannot change it.
When I put /dev/hda command it's getting kernel panic error because it can't boot.

I tried to change /etc/fstab to "/dev/sda1 /" mount to "/dev/hda /" also I changed to menu.lst file in boot at the same time but when I tried to boot it with "root=/dev/hda console=ttyS0". I am still getting error


My fdisk -l output as follow even tough I changed the "/etc/fstab"

Device     Boot    Start      End  Sectors  Size Id Type
/dev/sda1  *        2048 18970623 18968576    9G 83 Linux
/dev/sda2       18972670 20969471  1996802  975M  5 Extended
/dev/sda5       18972672 20969471  1996800  975M 82 Linux swap / Solaris

Maybe it might give you some idea?
About the symlink, I tried to create "ln -s /dev/sda1 /dev/hda" but since these are the devices, after reboot this file is being deleted and recreated again and I guess it's causing deletion of them.
I also tried with hardlink but it didn't make difference
Ok the problem is: modern systems/kernels use /dev/sdXY this is also dynamicly defined the moment devfs is mounted. (auto detected). There is not a lot you can do about that.
The Guest VM is the one that dictates what is needs....    You could try Ubuntu from the time PATA was still using /dev/hda (not sure when it changed for them).
You need the device BEFORE you can create a symlink. ( you can try to change initrd image if you are up to it, it is a bit too much work to describe it here).

Ok work around:    
qemu-system-x86_64 is the command issued?.....
which  qemu-system-x86_64
will tell where the original is.
In that case before the running the program calling the VM:  (assuming qemu-system-x86_64 program is in /usr/bin )
Create a script: /usr/local/bin/qemu-system-x86_64
#!/bin/bash

/usr/bin/qemu-system-x86_64 -hda <hard-drive> -smp 16 -m 10G -kernel <my-bz-kernel> -append "root=/dev/sda1 console=ttyS0" -enable-kvm

Open in new window

chmod 755 /usr/local/bin/qemu-system-x86_64
Be sure the PATH environment variable has /usr/local/bin before /usr/bin

This way your program always calls the script, the script uses different parameters  which should work.
If needed the script can be extended to only change the -append or even only if certain images run....

The legacy app is what really needs to be changed though.
Oh btw: fstab is what to mount during boot or pre-configured mounts a user can do ....
It does not tell the kernel what name to use. (fyi, the kernel needs first to initialise all kind of devices and keeps those in devfs filesystem, and later mounts the filesystem, even later still a boot script runs mount -a to  mount all devices that needs to be mounted. mount -a read the /etc/fstab.)  The kernel parameter is only a helpfull  directive to the kernel what device to use for the initial mount of / ).

ls -l /dev/sd*    will show the various disk
ls -l /dev/disk/*  will show alternate names of various devices or volumes. ( is multi disk environments, sd devices get assigned in ready/on-lone order esp with SAN's this may vary. all filesystems have a unique identifier to fix this)

What the kernel inside sees is what you need to supply.
you can create the symlink inside your initrd if you have one. dirty but should work.

changing grub makes no difference as far as i understand since your setup boots the kernel directly without a boot loader.

if you have no initrd and cannot remove the -kernel option or the -append option or other qemu options, i do not think this will be feasible
This question needs an answer!
Become an EE member today
7 DAY FREE TRIAL
Members can start a 7-Day Free trial then enjoy unlimited access to the platform.
View membership options
or
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.