USB Boot target device into FOG OS Live (FOSL) for debugging
-
@george1421 said:
The one thing that is missing (I think) is once you have your usb flash drive, is a way to refresh the kernels as new kernels are released over time.
I really hope that we can get this streamlined into Tom’s compile tool chain. So if he builds new kernels and inits and uploads those to the website he could also add a current ISO to https://fogproject.org/isos for example. Self updating process within the ISO is not worth the scripting effort I reckon as we will have lots of trouble with NIC issues and people behind proxies. So if we update the kernel people just need to download the most current ISO again.
@Wayne-Workman said:
Just be sure to include “troubleshoot” in the name / menus so that people don’t get the wrong idea and think this is the way to go for every time they wanna use fog.
Sure we will! But this is still a very early stage and I am not sure how well this will work. Would you mind giving it a try? Just download the ISO, dump it onto an empty stick and try booting it on various machines/architectures. I don’t have access to different machines right now as I am not working at university anymore…
-
@Sebastian-Roth I will, just bumping the link for now: https://drive.google.com/folderview?id=0B-bOeHjoUmyMM2c4LV90Z1NyNWc&usp=sharing
-
@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.
-
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.
- 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.
- 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
-
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 promptUEFI 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.
-
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 modeAfter 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 fontSo 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.
-
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
andefi_uga
we probably can useall_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
- need to add
-
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.
-
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
-
@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
-
@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.
-
This post is deleted! -
-
-