How do I check if an USB drive is bootable? - virtual-machine

I just created an USB drive and would like to check if it's correctly bootable without rebooting my actual computer. How should I do?

Under Linux, you have to know which device path got the drive with for example with dmesg | tail after insertion, let's assume it's /dev/sdb.
Qemu
sudo qemu -hda /dev/sdb or sudo qemu-system-x86_64 -hda /dev/sdb for 64 bits.
VirtualBox
VBoxManage internalcommands createrawvmdk -filename ~/usb.vmdk -rawdisk /dev/sdb
sudo chmod 666 /dev/sdb*
then add ~/usb.vmdk as a disk in a VM and boot on it
Don't hesitate to add other ways to do.

While it won't show if the stuff on the filesystem is capable of handling the whole boot thing you can check the boot flag with fdisk -l <drive> from a shell on a reasonably good *nix. (Which essentially tells the bios if it should try to boot the thingie or not.)

Related

How to launch openbios from Qemu

Good day,
So I am following this coreboot v3 + OpenBIOS tutorial Here .
In the instructions I have the following...
mkdir foo
cd foo
wget http://www.coreboot.org/images/9/9d/Qemu_coreboot_openbios.zip
wget http://www.coreboot.org/images/0/0d/Vgabios-cirrus.zip
unzip Qemu_coreboot_openbios.zip
unzip Vgabios-cirrus.zip
mv qemu_coreboot_openbios.bin bios.bin
cd ..
qemu -L foo -hda /dev/zero -serial stdio
I noticed that qemu has been replace or is implemented with qemu-system.
command I am running
qemu-x86_64 -L foo -hda /dev/zero -serial stdio
When I run the command, I see just qemu run it's typical and not find a disk.(which I expect since the disk switch points to /dev/zero) but none of the payloads run as I would expect from the tutorial.
What am I doing incorrectly?
Should I use a different version of qemu?
Should I create a dummy disk for this?
Qemu seems to be ignoring the files in the foo directory.
The examples are not up to date, as you have noticed by the renaming of qemu to qemu-system-x86_64.
I managed to get the examples to work using only the cirrus video card, and by renaming the outputs of the zips (bin - bios files to bios-256k.bin). I did this because by adding the -L option I specify the bios location and qemu will look for a file called bios-256k.bin as the bios. The command to run the bios with cirrus (all done while in the foo directory) was
qemu-system-x86_64 -L . -vga cirrus -serial stdio
Both machine types pc and q35 worked.

NFS client under WSL - mount.nfs: No such device

I am getting the following error trying to mount a nfs export.
sudo mount 192.168.1.175:/mnt/nas /mnt/c/nas
mount.nfs: No such device
Any ideas on how to fix this?
As of October 2020: You can mount nfs with wsl2, but wsl2 itself requires a hardware virtualization available. See here: https://github.com/microsoft/WSL/issues/5838
If like me you are stuck on WSL1 you can work around this issue by mapping the drive in windows. Use the Map Network Drive feature and create a drive letter for your nfs mount e.g. G:
Now in WSL you can mount that drive letter:
sudo mkdir /mnt/g
sudo mount -t drvfs G: /mnt/g
from: How to Mount Windows Network Drives in WSL
I have not tested the access speed to a drive mapped through to WSL like this but I would expect it to be slow!
The error indicates the nfs kernel modules are not loaded correctly and
also verify the exported path "/mnt/nas" exists on sever "192.168.1.175" or not.
first of all,we understand nfs is one of tctp/ip protocol, so one client and one server are needed, So our purpose is sharing a dir on windows or wsl to a another linux, that means the windows or wsl is a server, all you guys are right about wsl nfs, it doesnt work if we use the wsl nfs inside, we can make a another nfs server on windows instead of wsl, and configure the share dirs right which we can find the dirs on wsl, e.g. /mnt/d/WORK/tftpserverDir, after that we can mount successfully. those are tips of me:
make a nfs server on windows
I dowwnload from this:
https://www.hanewin.net/nfs-e.htm
configure the shared dir in exports file
D:\WORK\tftpserverDir -name:nfsroot -umask:000 -public -mapall:0
mount the share dirs on your dst linux
mount -t nfs -o nolock -o tcp -o rsize=32768,wsize=32768 172.10.10.80:/nfsroot /sdcard/mnt

Can ARM qemu system emulator boot from card image without kernel param?

I've seen a lot of examples how to run a QEMU ARM board emulator. In every case, besides SD card image param, QEMU was also always supplied with kernel param, i.e.:
qemu-system-arm -M versatilepb \
-kernel vmlinuz-2.6.18-6-versatile \ #KERNEL PARAM HERE
-initrd initrd.gz \
-hda hda.img -append "root=/dev/ram"
I am palying with bootloaders and want to create my own bootable SD card, but don't have a real board yet and want to learn with an emulated one. However, if run as described above, QEMU skips bootloader stage and runs kernel.
So what should I do to emulate a full boot sequence on QEMU so that it executes bootloader? Should I get a ROM dump and pass it as a -bios param?
You can do that by feeding the uboot image. I never used ROM dump.
QEMU BOOT SEQUENCE:
On real, physical boards the boot process usually involves a non-volatile memory (e.g. a Flash) containing a boot-loader and the operating system. On power on, the core loads and runs the boot-loader, that in turn loads and runs the operating system.
QEMU has the possibility to emulate Flash memory on many platforms, but not on the VersatilePB. There are patches ad procedures available that can add flash support, but for now I wanted to leave QEMU as it is.
QEMU can load a Linux kernel using the -kernel and -initrd options; at a low level, these options have the effect of loading two binary files into the emulated memory: the kernel binary at address 0x10000 (64KiB) and the ramdisk binary at address 0x800000 (8MiB).
Then QEMU prepares the kernel arguments and jumps at 0x10000 (64KiB) to execute Linux. I wanted to recreate this same situation using U-Boot, and to keep the situation similar to a real one I wanted to create a single binary image containing the whole system, just like having a Flash on board. The -kernel option in QEMU will be used to load the Flash binary into the emulated memory, and this means the starting address of the binary image will be 0x10000 (64KiB).
This example is based of ARM versatilepb board
make CROSS_COMPILE=arm-none-eabi- versatilepb_config
make CROSS_COMPILE=arm-none-eabi- all
Creating the Flash image
* download u-boot-xxx.x source tree and extract it
* cd into the source tree directory and build it
mkimage -A arm -C none -O linux -T kernel -d zImage -a 0x00010000 -e 0x00010000 zImage.uimg
mkimage -A arm -C none -O linux -T ramdisk -d rootfs.img.gz -a 0x00800000 -e 0x00800000 rootfs.uimg
dd if=/dev/zero of=flash.bin bs=1 count=6M
dd if=u-boot.bin of=flash.bin conv=notrunc bs=1
dd if=zImage.uimg of=flash.bin conv=notrunc bs=1 seek=2M
dd if=rootfs.uimg of=flash.bin conv=notrunc bs=1 seek=4M
Booting Linux
To boot Linux we can finally call:
qemu-system-arm -M versatilepb -m 128M -kernel flash.bin -serial stdio
You will need to pass it some kind of bootloader image via -bios (or a pflash option), yes. I doubt that a ROM dump would work though -- typically the ROM will assume much closer fidelity to the real hardware than QEMU provides. You'd want a bootloader written and tested to work with QEMU. One example of that is if you use the 'virt' board and a UEFI image which is built for QEMU.
Otherwise QEMU will use its "built in bootloader" which is a handful of instructions that are capable of booting the kernel you pass it with -kernel.

Found unknown Linux distribution on /dev/sdb2: grub configuration dual boot Arch Linux and NetBSD-7.0

I have Arch Linux on /dev/sdb1 and NetBSD-7.0 on /dev/sdb2.
On Arch Linux when I run sudo grub-mkconfig -o /boot/grub/grub.cfg I get a message like Found unknown Linux distribution on /dev/sdb2 but when I reboot, there is no grub option for that unknown Linux distribution which I know it is NetBSD-7.0.
How can I add NetBSD-7.0 to my grub menu option when rebooting.
There is a similar post, currently looking into it.
UPDATE: I mounted NetBSD partition with sudo mount -t ufs -o ro,ufstype=ufs2 /dev/sdb2 /mnt/ (ufstype=44bsd did not work) and then ran grub-mkconfig -o /boot/grub/grub.cfg but yet the issue persists.
UPDATE: Rebooted and pressed c to get the grub command line. Following commands booted the NetBSD-7.0:
ls
Ran ls to see the correct name of disks and partitions, /dev/sdb2 on Linux was (hd0,gpt2) on Grub. Then ran the following:
insmod ufs2
set root=(hd0,gpt2)
knetbsd /netbsd
boot
And NetBSD-7.0 booted.
To add NetBSD option to Grub menu, modified file /etc/grub/40_custom on Arch Linux like below:
menuentry "NetBSD-7.0"{
insmod ufs2
set root=(hd0,gpt2)
knetbsd /netbsd
}
However, after modifying 40_custom like above, NetBSD option does not appear on Grub menu. I don't know why.
Unless you have a typo, it looks like the 40_custom file is in the wrong directory. it should be located at /etc/grub.d/40_custom, notice the .d.
If your /boot is located on a separate partition, make sure that it is mounted with mount /boot before generating the grub.cfg. Otherwise your new grub.cfg won't be used.
Check which partition grub is loading the configuration from by running echo ${prefix} within the grub command line. It's possible that grub is loading the configuration from a partition that you don't expect.
Verify that netbsd was added to the config with grep -i netbsd /boot/grub/grub.cfg before rebooting to avoid some frustration after generating grub.cfg

qemu is not able to boot u-boot uImage binary

I've used buildroot to build a qemu compatible Linux kernel and root filesystem. I am emulating for the MPC8544DS machine and used the qemu_ppc_mpc8544ds_defconfig to generate these components. I was able to successfully build the kernel and the root filesystem. And was able to run it under qemu.
However when I tried to run uboot instead of the Linux Kernel (and the associated rootfs) it fails. Here is the way I invoke qemu to boot u-boot:
qemu-system-ppc -nographic -M mpc8544ds -m 512 -kernel ~/CrossCompilation/u-boot.bin and it fails like so:
Wrong image type 52, expected 2
qemu: could not load kernel '~/CrossCompilation/u-boot.bin'
I do not understand what else could be wrong. I've checked various blog posts over the internet and almost all of them use uboot.bin as the kernel (as opposed to srec and other formats)
could someone shed some light on the various image type numbers and which ones fit where?
UPDATE: This is how I compiled my u-boot
cd to u-boot dir
make distclean
make mrproper
make ARCH=powerpc CROSS_COMPILE=~/CrossCompilation/buildroot-2014.08/output/host/usr/bin/powerpc-buildroot-linux-gnuspe- MPC8544DS_defconfig
make ARCH=powerpc CROSS_COMPILE=~/CrossCompilation/buildroot-2014.08/output/host/usr/bin/powerpc-buildroot-linux-gnuspe-
Try removing the -kernel option. Make sure everything stay as is:
qemu-system-ppc -nographic -M mpc8544ds -m 512 ~/CrossCompilation/u-boot.bin