I don’t understand:
Who wrote it?
Is it supposed to be a sub chapter of “How to get virtio running for storage?”?
Why is a test image required, why can’t the existing image be changed after it has been booted just for testing? Or alternatively, why not mount the image, make the change, then boot it?
Please elaborate.
Who wrote it?Is it supposed to be a sub chapter of “How to get virtio running for storage?”?
Why is a test image required, why can’t the existing image be changed after it has been booted just for testing? Or alternatively, why not mount the image, make the change, then boot it?
Please elaborate.
I did. Yes its meant to be under that heading but it ended up somewhere by mistake.
The OP’s description of the bug exactly matches everything I’ve been thru when trying to get this to work.
What I mean by ‘test image’ is a beta build of Whonix that incorporates symlinking as described here:
That should work apparently.
b.) linux/udev : you could suggest that the vdX devices should be symlinked or other to sdX so that your fstab finds the devices independent of how they're connected.
[quote=“HulaHoop, post:2, topic:383”][quote]b.) linux/udev : you could suggest that the vdX devices should be
symlinked or other to sdX so that your fstab finds the devices independent
of how they’re connected.[/quote][/quote]
This is a suggestion to be taken to linux/udev developers. Outside my ability.
I see. What about the mechanism you propose at the end of: Dev/KVM - Whonix Its best if we at least try that and revert back if its not robust enough?
Considering the time investment I put into this particular feature to work, I am really eager to have it in some way.
Sure thing! As a perfectionist, I also must have this!
I would like to pursue this.
First question, have you tested Dev/KVM - Whonix ?
Second question, what is the official suggestion by kvm devs to solve this as a distro?
Sure thing! As a perfectionist, I also must have this!
Good to know 
First question, have you tested https://www.whonix.org/wiki/Dev/KVM#System_gets_unbootable.3F ?Second question, what is the official suggestion by kvm devs to solve this as a distro?
No I haven’t done it but, but maybe the UUID fix works and so we simply bypass all this fiddling with the grub files.
I never found a solutio to this from the IRC channel. Even though there’s 400 people on there at any given time, they never reply. The only time someone did, they had no idea what was wrong, but recommended this as a way to label drives. From KVM’s official documentation thy recommend using a UUID based system to avoid issues.
Breaking news!
Here is what works so far:
As per Dev/KVM - Whonix
unifying all disk references in these files including additionally /etc/fstab to vda
works with virtio-blk. the machine makes it past the point where it always hung up.
I tried a kernel and grub update followed by running: “sudo update-grub” and the changes survived with no ill effects and the vm boots all right.
One thing I noticed before changing the values was tht they all differed from one another probably causing all this:
[code]/boot/grub/device.map
/dev/disk/by-id/ata-VBOX_HARDDISK_VB3680cb3a-83f0b2f8
/boot/grub/grub.cfg
/dev/sda1
/etc/fstab
/dev/disk/by-uuid/040e91c3-400d-406c-bbfd-b5e08b5945b6[/code]
I’ll try changing them all according to the uuid in /fstab and report back. If all copies of Whonix have this uuid then we can subsitiute it for all refernces in these files and be done with it.
Confirmed. When the same uuid is used in all places in these three files it works.
There is also KVM mailing list.
And also http://unix.stackexchange.com/ has often given me good answers to development questions (User adrelanos - Unix & Linux Stack Exchange) - just need to ask them in a generic, non-Whonix way.
Breaking news!
Can you say please which file you have changed to what? Post the modified files?
There is also KVM mailing list.And also http://unix.stackexchange.com/ has often given me good answers to development questions (User adrelanos - Unix & Linux Stack Exchange) - just need to ask them in a generic, non-Whonix way.
I am not sure what to ask. Could you please post what it is you are trying to find out on SE?
The patching works and is stable after the many conditionsI tested above kernel, grub upgrades and the update-grub command all in that order. From what I’ve seen its a problem that doesn’t depend so much on KVM as it does on the way the qcow2 image partition identifiers are generated in the images.
Is VirtualBox a dependency for Whonix builds? Why else would the disk id had VBOX_HARDDISK in there?
What I’ve posted above is what I am seeing before changing all root paths to vda based nomenclature. Same works if that uuid is inserted instead in these three files.
What is needed is just the patching of root paths in /boot/grub/device.map /boot/grub/grub.cfg /etc/fstab
What my files look like now:
/boot/grub/device.map
After update-grub the file is blank
/boot/grub/grub.cfg
[code]#
if [ -s $prefix/grubenv ]; then
load_env
fi
set default=“0”
if [ “${prev_saved_entry}” ]; then
set saved_entry=“${prev_saved_entry}”
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z “${boot_once}” ]; then
saved_entry=“${chosen}”
save_env saved_entry
fi
}
function load_video {
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
}
insmod part_msdos
insmod ext2
set root=‘(/dev/vda,msdos1)’
search --no-floppy --fs-uuid --set=root 040e91c3-400d-406c-bbfd-b5e08b5945b6
if loadfont /usr/share/grub/unicode.pf2 ; then
set gfxmode=640x480
load_video
insmod gfxterm
fi
terminal_output gfxterm
set timeout=5
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
menuentry ‘Debian GNU/Linux, with Linux 3.2.0-4-686-pae’ --class debian --class gnu-linux --class gnu --class os {
load_video
insmod gzio
insmod part_msdos
insmod ext2
set root=‘(/dev/vda,msdos1)’
search --no-floppy --fs-uuid --set=root 040e91c3-400d-406c-bbfd-b5e08b5945b6
echo ‘Loading Linux 3.2.0-4-686-pae …’
linux /boot/vmlinuz-3.2.0-4-686-pae root=UUID=040e91c3-400d-406c-bbfd-b5e08b5945b6 ro selinux=1 enforcing=1 vga=0x0317
echo ‘Loading initial ramdisk …’
initrd /boot/initrd.img-3.2.0-4-686-pae
}
menuentry ‘Debian GNU/Linux, with Linux 3.2.0-4-686-pae (recovery mode)’ --class debian --class gnu-linux --class gnu --class os {
load_video
insmod gzio
insmod part_msdos
insmod ext2
set root=‘(/dev/vda,msdos1)’
search --no-floppy --fs-uuid --set=root 040e91c3-400d-406c-bbfd-b5e08b5945b6
echo ‘Loading Linux 3.2.0-4-686-pae …’
linux /boot/vmlinuz-3.2.0-4-686-pae root=UUID=040e91c3-400d-406c-bbfd-b5e08b5945b6 ro single selinux=1 enforcing=1
echo ‘Loading initial ramdisk …’
initrd /boot/initrd.img-3.2.0-4-686-pae
}
menuentry ‘Debian GNU/Linux, with Linux 3.2.0-4-486’ --class debian --class gnu-linux --class gnu --class os {
load_video
insmod gzio
insmod part_msdos
insmod ext2
set root=‘(/dev/vda,msdos1)’
search --no-floppy --fs-uuid --set=root 040e91c3-400d-406c-bbfd-b5e08b5945b6
echo ‘Loading Linux 3.2.0-4-486 …’
linux /boot/vmlinuz-3.2.0-4-486 root=UUID=040e91c3-400d-406c-bbfd-b5e08b5945b6 ro selinux=1 enforcing=1 vga=0x0317
echo ‘Loading initial ramdisk …’
initrd /boot/initrd.img-3.2.0-4-486
}
menuentry ‘Debian GNU/Linux, with Linux 3.2.0-4-486 (recovery mode)’ --class debian --class gnu-linux --class gnu --class os {
load_video
insmod gzio
insmod part_msdos
insmod ext2
set root=‘(/dev/vda,msdos1)’
search --no-floppy --fs-uuid --set=root 040e91c3-400d-406c-bbfd-b5e08b5945b6
echo ‘Loading Linux 3.2.0-4-486 …’
linux /boot/vmlinuz-3.2.0-4-486 root=UUID=040e91c3-400d-406c-bbfd-b5e08b5945b6 ro single selinux=1 enforcing=1
echo ‘Loading initial ramdisk …’
initrd /boot/initrd.img-3.2.0-4-486
}
if [ -f $prefix/custom.cfg ]; then
source $prefix/custom.cfg;
fi
[/code]
/etc/fstab
[code]/dev/disk/by-uuid/040e91c3-400d-406c-bbfd-b5e08b5945b6 / auto defaults,errors=remount-ro 0 1
proc /proc proc defaults 0 0
/dev/cdrom /mnt/cdrom0 iso9660 ro,user,noauto 0 0
/swapfile1 swap swap defaults 0 0
[/code]
Only when using the --vbox switch.
Nice catch. This is a bug.
hard drive serial of build machine leaks into image #249:
https://github.com/Whonix/Whonix/issues/249
Next testers-only version will most likely not include a /boot/grub/device.map anymore.
## Whonix /etc/fstab changes.
You were using Whonix 8, not 8.6.2.8? Because 8.6.2.8 doesn’t modify /etc/fstab anymore. swap-file-creator (GitHub - Kicksecure/swap-file-creator: Adds encrypted swap file to the system - for better protection of locally stored data and to aid environments with low RAM. https://www.kicksecure.com/wiki/swap-file-creator) encrypts and mounts the swap file on boot without any changes to /etc/fstab required.
Whonix 8.6.2.8
user@host:~$ cat /etc/fstab
/dev/disk/by-uuid/26ada0c0-1165-4098-884d-aafd2220c2c6 / auto defaults,errors=remount-ro 0 1
proc /proc proc defaults 0 0
/dev/cdrom /mnt/cdrom0 iso9660 ro,user,noauto 0 0
# some other examples:
# /dev/sda2 none swap sw,pri=0 0 0
# /dev/hda1 /Grml ext3 dev,suid,user,noauto 0 2
# //1.2.3.4/pub /smb/pub cifs user,noauto,uid=grml,gid=grml 0 0
# linux:/pub /beer nfs defaults 0 0
# tmpfs /tmp tmpfs size=300M 0 0
# /dev/sda5 none swap sw 0 026ada0c0-1165-4098-884d-aafd2220c2c6 is fixed.
So no more changes to /etc/fstab required either way?
Asked on stackexchange a vital question before acting blindfolded:
You were using Whonix 8, not 8.6.2.8?
Yes
So no more changes to /etc/fstab required either way?
Yes
As for your question I have looked up and posted on Dev/KVM about how to verify which drivers are in use for a given piece of hardware. Please read the stuff I posted in there. It took some time and effort to find this info and incorporate it.
see: hwinfo --short
Also are the answers posted for the blocker satisfactory? Could we close them now as solved after adding the relevant tidbits to the user wiki?
Yes.
Sorry. I missed it. I was only reading this:
Breaking news!
Fix available since git tag 8.6.4.4 (in dev-only repo GitHub - adrelanos/nothing-to-see: Temporary Git Tags for Whonix).
Technically speaking, this is the fix:
https://github.com/Whonix/anon-shared-build-fix-grub/commit/e7e50d18f6269eb983cc36f469478478e10815b8
Changelog (related to grub/kvm only):
We can now change
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2'/>
<source file='/var/lib/libvirt/images/Whonix-Gateway.qcow2'/>
<target dev='hda' bus='ide'/>
</disk>to
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2'/>
<source file='/var/lib/libvirt/images/Whonix-Gateway.qcow2'/>
<target dev='vda' bus='virtio'/>
</disk>No changes in the images required anymore! You can use whatever you wish and boot. You can even toggle from hda to vda. Bonus: somehow you can even still toggle from hda / vda after you have run “sudo update-grub” in the image.
Let’s use 2) instead of 1) for next testers-only release?
Can you please update out kvm xml files from 1) to 2)
Does qemu support virtio as well?
Let's use 2) instead of 1) for next testers-only release?Can you please update out kvm xml files from 1) to 2)
Does qemu support virtio as well?
;D nice work Patrick. Yes lets use this for the next testing release. I will update the xmls.
virtio still uses a qemu back-end but relies much less on it. There is a purely non-qemu mode that provides even faster throughput for NICs and disk called vHost. vHost is a kernel module and is automatically leveraged by libvirt if its there and also if libvirt is set to virtio mode for these devices. Removing the ‘name=qemu’ allows use vHost as the backend does not become a hard requirement.
in summary no more further intervention by us needed after this point.