USB Boot target device into FOG OS Live (FOSL) for debugging

[george1421]

@Sebastian-Roth I’ll run into the office and grab one of the newer dells to test the efi booting. I have to run into the office anyways since I forgot my travel computer bag on Friday. I won’t be back in the office until Wed, so I may not have a chance to test it if I don’t have a viable system.

[george1421]

Critical review of FOG Debug booting.

Geo image:
This image booted on crusty Lenovo T43 and e6400 in 32 bit bios mode no problem
Booted OK on e6220 in bios mode both 32 and 64 bit
Booted with error on e6220 in EFI mode with both 32 and 64 bit with error “No C<something> No suitable video mode found. Booting in blind mode” The <something> part was due to sloppy hand writing. Since there was no console I can’t tell if the system actually booted or not. I’m suspecting that it was running since it didn’t panic anywhere. There probably needs a kernel parameter passed since the font was really tiny like a 132x56 console resolution, where bios mode had traditional 80x25 resolution.

ISO image:
Used unetbootin to “burn” iso image to 16GB usb drive.

Issue observed, unetbootin creates an entry called default with a 10 second timeout.

1. This default value selected the x64 bit kernel. This fails if the booted device has a 32 bit CPU. I assume it is picking this up from the grub menu. Suggestion make the 32bit kernel default or users will see you have the wrong processor try again message.
2. The default option (on a computer with 64 bit processor causes a kernel panic “unable to mount root filesystem”

Dell e6220
BIOS mode:
Default: Resulted in kernel panic
x64 booted to command prompt
x32 booted to command prompt
EFI mode:
Selecting the usb flash drive from the efi boot menu caused a pause then started booting from hard drive. I never got to the grub menu.

Lenovo T43
BIOS Mode (only)
Default resulted in kernel panic
32 bit booted to command prompt
64 (not supported)

Dell e6400
Bios Mode (only)
Default resulted in kernel panic
32 bit booted to command prompt
64 (not supported)

I looked at the syslinux.cfg that unetbootin created. And I can see that the 64 bit kernel does have the lead over the 32 bit kernel. I suggest that this order be changed in the grub menu to make the 32 bit kernel default. I’m not sure what happened. But as you see unetbootin copied the 64 bit bzimage and renamed it to ubnkern and copied init.xz to ubninit. The copied bzImage has the right size, but the copied init.xz is only 2.8MB in size.

label unetbootindefault
menu label Default
kernel /ubnkern
append initrd=/ubninit loglevel=7 init=/sbin/init root=/dev/ram0 rw ramdisk_size=127000 pcie_aspm=off consoleblank=0 isdebug=yes

label ubnentry0
menu label FOG 64-bit Debug Kernel
kernel /boot/bzImage
append initrd=/boot/init.xz loglevel=7 init=/sbin/init root=/dev/ram0 rw ramdisk_size=127000 pcie_aspm=off consoleblank=0 isdebug=yes

[george1421]

Critial review FOG Debug booting

ISO image:
Burned iso image to flash drive using: dd if=multi.iso of=/dev/sdb

BIOS booting on e6220
Invalid partition table! and will sit there until enter is pressed. Then GRUB menu is displayed but only option is x64 kernel. x64 kernel does boot to command prompt

UEFI booting on e6220
Grub menu not displayed. Error message displayed: “Error: disk `’ not found. Entering rescue mode… grub>”

When I reinsert the flash drive into my computer, ubuntu could not mount it. I assume I did something wrong with either the format or the way dd was used.

For reference this is the structure of the flash drive

sdb      8:32   1    15G  0 disk 
├─sdb1   8:33   1   136K  0 part 
├─sdb2   8:34   1   2.8M  0 part 
└─sdb3   8:35   1  56.4M  0 part 

In preparation for rebuilding my direct path, when I ran fdisk it reported that the usb flash drive was in GPT mode and it only reported one partition in fdisk. I did see the procedure to go the gpt route but I elected to go the vfat route which only required one partition with MBR. Just saying not implying anything.

[george1421]

Working back with my image. For EFI booting when I boot with grub2 in efi mode I get the following error message.

Error: no suitable video mode found.
Booting in blind mode

After a little research I found I needed to add this to the grub menu then the fog kernel would boot in EFI mode.
insmod efi_gop
insmod efi_uga
insmod font

So I updated the grub.cfg menu to this:

set timeout=10
set default=0


menuentry "FOG 32-bit Debug Kernel" {
 linux  /boot/bzImage32 loglevel=7 init=/sbin/init root=/dev/ram0 rw ramdisk_size=127000 pcie_aspm=off consoleblank=0 isdebug=yes
 initrd /boot/init_32.xz
}

menuentry "FOG 64-bit Debug Kernel" {
 insmod efi_gop
 insmod efi_uga
 insmod font

 linux  /boot/bzImage loglevel=7 init=/sbin/init root=/dev/ram0 rw ramdisk_size=127000 pcie_aspm=off consoleblank=0 isdebug=yes
 initrd /boot/init.xz
}

If I picked the 64 bit kernel it would boot without issue. If I selected the 32 bit kernel it would get the error message.

Now the thing I don’t know, is this error message because of FOG or is it because of something is missing in the kernel itself that grub is inserting? Would this explain why some devices which boot in efi get a black screen?

As a side note, if I leave those settings in place and boot in BIOS mode and select the 64 bit kernel I get warning messages and have to press enter to start booting the kernel, so this is not a viable option for multi booting.

[Sebastian Roth]

Awesome stuff! We are making progress here I reckon. Some of my findings:

• need to add --modules=part_gpt to the grub-mkrescue call to make it work with UEFI machines (don’t ask me why!) - updated the
• automatic arch selection is not a great idea - using two menu entries like George is better I find
• instead of grub modules efi_gop and efi_uga we probably can use all_video which is handled a lot better if we are using a multiboot (bios+uefi) ISO
• don’t use unetbootin to “burn” the ISO onto a USB stick as it is altering the bootloader (fail!) - use dd, rawwrite, win32diskimager or any other simple tool that does a sector by sector copy (you might need to rename .iso to .img)

Uploaded a new ISO image called debug_v2.iso: https://drive.google.com/folderview?id=0B-bOeHjoUmyMM2c4LV90Z1NyNWc&usp=sharing

[george1421]

I started testing the debug_v2.iso

To move the iso image to my usb flash drive I used the dd command.

sudo dd bs=4M if=debug_v2.iso of=/dev/sdb

The copy worked as it should. I ejected the usb drive and reinserted it into my ubuntu laptop. This error was thrown when I inserted it and the laptop tried to mount it.

Error mounting /dev/sdb3 at /media/jondoe/ISOIMAGE1: Command-line `mount -t "hfsplus" -o "uhelper=udisks2,nodev,nosuid" "/dev/sdb3" "/media/jondoe/ISOIMAGE1"' exited with non-zero exit status 32: mount: wrong fs type, bad option, bad superblock on /dev/sdb3, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail  or so

I’m suspecting this is related to the laptop being in bios mode and using mbr disks. I’m not really concerned about it. Just noting that once you create the usb flash drive its not mountable. I don’t have a efi linux system to confirm if it is a bios vs efi vs gpt issue.

The usb booted correctly in efi mode on an e6220 laptop. It also booted correctly in bios mode. I did note something strange. If I booted in 32bit efi mode, issue a reboot at the command prompt and then rebooted in 64 bit efi mode they kernel would throw an error “Fixing recursion fault but reboot is needed” it waits about 10 seconds then does something similar to a core dump all over the screen. The only seems to be an issue if you switch between 32 bit and 64 bit in efi mode. Rebooting multiple times in 32 bit efi or 64 bit efi works as it should.

Booting in bios mode did thow an error about invalid partition table. I’m not sure if that was an issue with my flash drive from before or not. I’m going to try to fix my flash drive again to make a clean boot then reapply the iso image.

[george1421]

Method #4 Create automated multiboot

I revived / revised my attempt at making an automated fog debug kernel boot image.

This image in contrast to what grub-mkrescue makes, creates a vFAT image that can be mounted by both gpt and mbr systems. The issue I had with the grub-mkrescue flash image is that I could not mount it on my BIOS ubuntu computer or my windows XP computer (not a big loss).

The following script creates a complete boot image that can be moved to a flash drive with dd, win32diskimager or any other disk image tool (not unetbootin).

File: mk.fogdebugboot

#!/bin/bash

if [ -f /tmp/fogkern.img ]; then
    echo Nuking old FOG Debug image
    rm -f /tmp/fogkern.img
fi

echo Make a blank 128MB disk image
dd if=/dev/zero of=/tmp/fogkern.img bs=1M count=128
 
echo Make the partition table, partition and set it bootable.
parted --script /tmp/fogkern.img mklabel msdos mkpart p fat32 1 128 set 1 boot on
 
echo Map the partitions from the image file
kpartx -a /tmp/fogkern.img
 
# sleep 2 seconds, wait for kpartx to create the device nodes
sleep 2
 
echo Make an vfat filesystem on the first partition.
mkfs -t vfat -n GRUB /dev/mapper/loop0p1
 
echo Mount the filesystem via loopback
mount /dev/mapper/loop0p1 /mnt

echo Install GRUB
grub-install --removable --no-nvram --no-uefi-secure-boot --efi-directory=/mnt --boot-directory=/mnt/boot --target=i386-efi
grub-install --removable --no-nvram --no-uefi-secure-boot --efi-directory=/mnt --boot-directory=/mnt/boot --target=x86_64-efi
grub-install --removable --no-floppy --boot-directory=/mnt/boot --target=i386-pc /dev/loop0

echo Download the FOG kernels and inits
wget -P /mnt/boot/ https://fogproject.org/inits/init.xz
wget -P /mnt/boot/ https://fogproject.org/inits/init_32.xz
wget -P /mnt/boot/ https://fogproject.org/kernels/bzImage
wget -P /mnt/boot/ https://fogproject.org/kernels/bzImage32

echo Create the grub configuration file
cat > /mnt/boot/grub/grub.cfg << EOF

set timeout=10
set default=0
insmod all_video

menuentry "FOG 32-bit Debug Kernel" {
 linux  /boot/bzImage32 loglevel=7 init=/sbin/init root=/dev/ram0 rw ramdisk_size=127000 pcie_aspm=off consoleblank=0 isdebug=yes
 initrd /boot/init_32.xz
}

menuentry "FOG 64-bit Debug Kernel" {
 linux  /boot/bzImage loglevel=7 init=/sbin/init root=/dev/ram0 rw ramdisk_size=127000 pcie_aspm=off consoleblank=0 isdebug=yes
 initrd /boot/init.xz
}

EOF
 
echo Unmount the loopback
umount /mnt
 
echo Unmap the image
kpartx -d /tmp/fogkern.img
 
# Write the file to flash drive
# sudo dd bs=1M if=/tmp/fogkern.img of=/dev/sdX

[Sebastian Roth]

@george1421 said:

Booting in bios mode did thow an error about invalid partition table. I’m not sure if that was an issue with my flash drive from before or not.

The error is because on the third partition there is stuff to boot this ISO on Mac OS X. Looks like it is trying to mount it as hfsplus but fails. Not sure why that is.

PS: Great script! Maybe you want to download files first and do a rough size calculation before creating the image file. For example:

...
size=$((`du -lsm KERNEL_DIR | cut -f1` + 4))
dd if=/dev/zero of=/tmp/fogkern.img bs=1M count=$size
parted --script /tmp/fogkern.img mklabel msdos mkpart p fat32 1 $size set 1 boot on

[george1421]

@Sebastian-Roth Interesting on the boot stuff for OSX. I think any error would confuse the user beyond the need to use the debug kernel. I’m not saying its a bad thing but if we can avoid the error, the less questions we will have to answer.

It would be interesting to know if the MBR image I created would work on OSX. I think I remember reading somewhere that the disk needs to be GPT.

I can’t remember right now if I tried the grub-mkrescue image on my T43 (32 bit crusty old laptop). I’ll recreate the flash drive based on the your file and see.

As for the dynamic size, I could do that. Good point on predownloading the boot kernel files. I was just being lazy and picked 128MB knowing that was about twice the size I needed of 60MB.

[sudburr]

This post is deleted!