Jump to content











Photo
- - - - -

Add Linux cheat code based on disk UUID being found?


  • Please log in to reply
18 replies to this topic

#1 stepdown

stepdown

    Newbie

  • Members
  • 19 posts
  •  
    Czech_ Republic

Posted 05 March 2017 - 09:39 AM

Hi everyone, my first post/question in this forum, which I've followed from time to time in complete awe. I have a limited understanding of grub4dos, although I've used it for years to dual boot Windows and Linux.

 

This is my setup. I carry a single USB stick with me and an external USB drive. The stick holds Linux boot files (initrd, vmlinuz), the USB external disk holds the rest of the Linux system. I use the same stick+disk on several different PCs, and it works well.

 

Here my need. Some PCs need different cheat codes to be able to boot, for instance, I need to blacklist some modules _on the kernel line_. This is very hardware specific, i.e., PC A needs cheat code X, PC B needs cheat code Y, etc. So far I've managed the cheat codes with a proliferation of menu.lst entries, each entry specific to one PC, but this is getting unwieldy, and the user has to know which PC is which.

 

If grub4dos could detect disk UUIDs, and the boot entry could be written such that it adds the cheat codes conditionally, based on finding a specific UUID. It this possible and how? Roughly this entry would "run" some code that implements this pseudo-code

CHEATCODE = ""
For UUID in all hard disk drives
  Switch(UUID)
    Case "abc":
      CHEATCODE = "blacklist=module1  custom_code1"
      Break
    Case "def":
      CHEATCODE = "blacklist=module2 custom_code2 custom_code3"
      Break
EndFor
kernel /vmlinuz %CHEATCODE%
initrd /initrd

Of course, the Case labels and CHEATCODE values are specific to the hardware pool that the stick is being used on, but at least such an entry would be easy to update for new hardware, and the stick could be given to users who can't tell which PC is which.

 

My idea of using UUIDs might be too limiting; I recognize that UUIDs don't scale up well. For instance, if G4D could probe PCI hardware, then the blacklist cheat code could be written for an entire group of PCs without limiting it by UUID. But I don't think that G4D is so advanced that it can probe hardware other than disks. This is why I thought about using UUIDs. If there are better ways, please tell me.

 

Anyway, I would appreciate if anyone could lead me into writing a boot entry that implements the above pseudo-code. Thank you

 

 



#2 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 05 March 2017 - 09:46 AM

Yes, g4d can list PCI IDs using a grub4dos program.

If you make an Easy2Boot USB drive, try the Utilities menu.

 

It would be easily possible to get it to look for specific PCI IDs.

 

It is also possible to detect in many cases, BIOS and Manufacturer and maybe model too by searching for BIOS strings.

See "\_ISO\docs\Sample mnu files\E2B Menus\BIOS Detect and Run.mnu"

 

if you have a specific example (Make\Model + menu .cfg lines) I would be happy to supply example code.


Edited by steve6375, 05 March 2017 - 11:00 AM.


#3 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 05 March 2017 - 10:02 AM

P.S. Are you sure multiple entries actually work, e.g.

kernel /vmlinuz blacklist=module2 custom_code2 custom_code3

or

kernel /vmlinuz "blacklist=module2 custom_code2 custom_code3"

Most linux scripts are not able to cope with spaces in parameter values???



#4 stepdown

stepdown

    Newbie

  • Members
  • 19 posts
  •  
    Czech_ Republic

Posted 05 March 2017 - 11:04 AM

Thanks Steve, I will look into the two resources you listed.

Yes, I'm sure that the specific Linux OS that I boot can handle multiple cheat codes that are separated with spaces.

 

Thanks



#5 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 05 March 2017 - 11:23 AM

Here is an example for Model detection

You can use the SearchBS.g4b batch file in your own USB drive if you wish.

# Looks for a BIOS string to find PC Model
# Search strings (e.g. "eeepc") are not case-sensitive
# 0x7ff+0x01 searches 512 bytes at end of BIOS ROM, 0x600+0x40 will search the BIOS VGA ROM area
# 0x680+0x180 searches all of BIOS from 0xD000:0 to 0xFFFF:F (and so will be slower)
# remove the " > nul" text if you want to see the strings that it has found
title Boot Ubuntu (detect system model)\n Auto-detect based on BIOS strings
set GOTSTR=
set MATCH=
set bl=
if not exist MATCH call /%grub%/SearchBS.g4b 0x780+0x80 "eeepc" > nul
if not exist MATCH if "%GOTSTR%"=="1" set bl=emodule1 && set MATCH=1
if not exist MATCH call /%grub%/SearchBS.g4b 0x780+0x80 "ASUS Z87" > nul
if not exist MATCH if "%GOTSTR%"=="1" set bl=modulez87 && set MATCH=1
if not exist MATCH call /%grub%/SearchBS.g4b 0x780+0x80 "virtualbox" > nul
if not exist MATCH if "%GOTSTR%"=="1" set bl=vbmodule1 && set MATCH=1

# add more here
if exist MATCH echo bl=%bl%
pause
# can boot to linux here...
boot


#6 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 05 March 2017 - 12:05 PM

# Look for a BIOS string to find PC Model
# Search strings (e.g. "eeepc") are not case-sensitive
# 0x7ff+0x01 searches 512 bytes at end of BIOS ROM, 0x600+0x40 will search the BIOS VGA ROM area
# 0x680+0x180 searches all of BIOS from 0xD000:0 to 0xFFFF:F (and so will be slower)
# remove the " > nul" text if you want to see the strings that it has found
# This example sets blacklist modules depending on what Model we find
# We can also set nomodeset parameter for specific models
# Note that a blacklist must NOT contain spaces or the values after the space won't be parsed correctly by linux!
# ATTENTION: The modules used are for example only - they are not real module names!
iftitle [if exist $HOME$/ubuntu-16.10-desktop-amd64.iso] Boot Ubuntu (detect system model for blacklist)\n Auto-detect based on BIOS strings
set ISO=ubuntu-16.10-desktop-amd64.iso
set GOTSTR=
set MATCH=
set bl=
set modeset=
if not exist MATCH call /%grub%/SearchBS.g4b 0x780+0x80 "eeepc" > nul
if not exist MATCH if "%GOTSTR%"=="1" set bl=emodule1,module2 && set MATCH=1
if not exist MATCH call /%grub%/SearchBS.g4b 0x780+0x80 "ASUS Z87" > nul
if not exist MATCH if "%GOTSTR%"=="1" set bl=modulez87 && set MATCH=1
if not exist MATCH call /%grub%/SearchBS.g4b 0x780+0x80 "virtualbox" > nul
if not exist MATCH if "%GOTSTR%"=="1" set bl=vbmodule1,module3 && set modeset=nomodeset && set MATCH=1
# add more pairs of lines here
if exist bl echo -e -n $[0x0E]Using blacklist=%bl% %modeset% && pause --wait=3 > nul
# suppress messages from QRUN
set redir=> nul
# Map ISO automatically by calling QRUN
/%grub%/QRUN.g4b $HOME$/%ISO%
# (0xff) will have ISO - root should be (0xff)
if not exist /casper/vmlinuz.efi pause ERROR: Wrong ISO? && configfile (md)0xa000+0x50
kernel /casper/vmlinuz.efi  file=/cdrom/preseed/ubuntu.seed boot=casper blacklist=%bl% %modeset% quiet splash ---
initrd /casper/initrd.lz
# can boot to linux here...
boot

Example for Ubuntu (with 'pretend' modules) - not tested for blacklisting!



#7 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 05 March 2017 - 12:13 PM

title Boot Ubuntu with PCI Check\n Check for known PCI IDs
# get PCI IDs into memory
/%grub%/DPMS/chkpci > (md)0x300+2
set bl=
cat --locatei=EN_8086&DEV_27B9 (md)0x300+2 > nul && set bl=Device 27b9
# add more here
echo Found %bl%
pause
# can now use %bl% in kernel parmeters, etc.
boot

Here is PCI check example (without kernel.initrd lines).

Note that the locatei= string must be 16 or less characters which is why is starts with EN and not VEN!



#8 stepdown

stepdown

    Newbie

  • Members
  • 19 posts
  •  
    Czech_ Republic

Posted 05 March 2017 - 01:06 PM

Steve, thank you very much!  I'm educating myself on EB2 and experimenting with your three examples. Will report back.



#9 stepdown

stepdown

    Newbie

  • Members
  • 19 posts
  •  
    Czech_ Republic

Posted 05 March 2017 - 01:39 PM

The BIOS approach is very flexible, there is a lot of information that can be matched to target hardware models as a group, and even single out a specific PC. However, I have trouble matching a system UUID. Running "dmidecode | more" in Linux I get to this record:

...
Handle 0x0001, DMI type 1, 27 bytes
System Information
        Manufacturer: Dell Inc.
        Version: 00
        UUID: 4C4C4544-004B-6B10-8132-B7C04F0C3440
 ...

So I added this entry to menu.lst

title 3 detect system UUID based on BIOS
set GOTSTR=
set MATCH=
set bl=
if not exist MATCH call /%grub%/SearchBS.g4b 0x780+0x80 "4C4C4544-004B-6B10-8132-B7C04F0C3440"
if not exist MATCH if "%GOTSTR%"=="1" set bl=dell && set MATCH=1
if not exist MATCH call /%grub%/SearchBS.g4b 0x780+0x80 "Dell "
if not exist MATCH if "%GOTSTR%"=="1" set bl=dell && set MATCH=1

# add more pairs of lines here
if exist bl echo -e -n $[0x0E]Using blacklist=%bl% %modeset% && pause --wait=3 > nul
pause
# can boot to linux here...
boot

and I can see that "Dell " is matched several times, but the whole UUID isn't found at all. Are there string patterns that SearchBS.g4b can not search?


Edited by stepdown, 05 March 2017 - 01:41 PM.


#10 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 05 March 2017 - 01:42 PM

Use a search string of less than 17 characters?



#11 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 05 March 2017 - 03:11 PM

As a side note and generally speaking, it is not a particularly good idea to make overcomplex menu.lst entries (although it is possible if you know what you are doing) but the good thing about grub4dos is that you can write a separate batch file that may be invoked from the menu.lst, which can (say) set a few variables and then proceed to boot.
This way it is easier to debug/troubleshoot.
Given that you have a limited number of PC's maybe instead of the UUID of a given filesystem (which is obviously dependent on a specific disk, which is more likely to be changed/modified) you may want (should the PCI ID detection route be too complex) to use instead the MAC address of the NIC of the machine, something *like* (Steve6375's RMPREPUSB site):
http://www.rmprepusb...ub4dos_examples
 

# Look for specific BIOS or System type
#0x680 = D000:0 - the start of the DMI and BIOS area
#0x180 = 30000h - the length of the search, so it will finish at F000:FFFFh - i.e. end of BIOS area
#So if the DMI string was 'EeePC' on one system and 'DELL' on another, then use
set SYSTEM=
if "%SYSTEM%"=="" cat --locate=\x45\x65\x65\x50\x43 (md)0x680+0x180 > nul && set SYSTEM=EeePC
if "%SYSTEM%"=="" cat --locate=\x44\x45\x4C (md)0x680+0x180 > nul && set SYSTEM=DELL
<more here>
if "%SYSTEM%"=="" pause --wait=3 ERROR: No BIOS strings found that I recognise! && configfile /menu.lst
echo "%SYSTEM%" found:
# Next line displays the hex string and following bytes for user interest!
cat --hex --length=0x80 --skip=%?% (md)0x680+0x180
if "%SYSTEM%"=="DELL" set MYISO=/dell.iso
if "%SYSTEM%"=="EeePC" set MYISO=/EeePC.iso
<more here>
# now do stuff with the correct ISO!


# check mainboard MAC address - e.g. MAC address is 00:23:54:58:32:6b
cat --locate=\x00\x23\x54\x58\x32\x6b (md)0x680+0x180 || pause --wait=3 WRONG SYSTEM! && halt


# Lock a menu entry to a MAC address (so that this will only work on one system which has MAC address = 00:23:54:58:32:6b!)
# Use SCANBIOH.exe DOS tool from Beta Downloads page to find the correct memory location that contains your MAC address
# You can also use this technique to match against your mainboard serial number or model type
# See http://reboot.pro/14...post__p__130251for details.

The above link is on this thread (originally UUID related):
http://reboot.pro/to...d-in-this-code/
here (changes in board software prevent resolving those links nowadays):
http://reboot.pro/to...-code/?p=130251

:duff:
Wonko

#12 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 05 March 2017 - 03:22 PM

The system UUID may exist as binary

 

try searching for 4C4C4544 as 

 

--locate=\x4c\x4c\x45\x44



#13 stepdown

stepdown

    Newbie

  • Members
  • 19 posts
  •  
    Czech_ Republic

Posted 05 March 2017 - 06:20 PM

Thanks Steve and Wonko for your continued support. So I had time to try matching the generic string "Dell ", the system UUID, and the MAC address. I already reported success on finding "Dell " as a string with SearchBS.g4b. The system UUID can be matched as binary by byte-swapping each of the first three UUID components - on Intel platforms. Details here https://software.int...nt/topic/295694. So in my case matching 4C4C4544-004B-6B10-8132-B7C04F0C3440 becomes --locate=\x44\x45\x4c\x4c\x4b\x00\x32\x81 I didn't have much luck matching the MAC, yet, mostly because I haven't found a Linux equivalent of SCANBIOH.EXE from which to get the MAC address memory location.

#14 stepdown

stepdown

    Newbie

  • Members
  • 19 posts
  •  
    Czech_ Republic

Posted 05 March 2017 - 06:21 PM

Thanks Steve and Wonko for your continued support. So I had time to try matching the generic string "Dell ", the system UUID, and the MAC address. I already reported success on finding "Dell " as a string with SearchBS.g4b. The system UUID can be matched as binary by byte-swapping each of the first three UUID components - on Intel platforms. Details here https://software.int...nt/topic/295694. So in my case matching 4C4C4544-004B-6B10-8132-B7C04F0C3440 becomes --locate=\x44\x45\x4c\x4c\x4b\x00\x32\x81 I didn't have much luck matching the MAC, yet, mostly because I haven't found a Linux equivalent of SCANBIOH.EXE from which to get the MAC address memory location.



#15 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 05 March 2017 - 06:29 PM

If you have a E2B drive, just copy ScanBIOH.exe to the USB drive, boot to FreeDOS menu entry in DOS submenu and run ScanBIOH directly from the E2B drive.



#16 stepdown

stepdown

    Newbie

  • Members
  • 19 posts
  •  
    Czech_ Republic

Posted 07 March 2017 - 08:54 AM

Hi Steve, I built an E2B flash drive. This thread is going to morph into my experience with E2B. I found it very slow, that's the main problem. Partition 1 (p1) fat32 90 GB, p2 ext4 28 GB, p3 Linux swap 2 GB. P1, MBR, PBR prepared with RMUSBPrep february 2017 version following the E2B setup page. P2 and p3 created with gparted on my Linux PC. I tested the drive on 2 PCs. First PC takes 165 seconds to go through the 100 cycle USB speed test (Utilities menu entry). Running the same test on the same PC in a QEMU 860 MB RAM session takes 77 seconds. Running the speed test on another PC takes 106 seconds. The flash drive is a USB3 VERBATIM STORE 'n' GO 120 GB connected to USB2 ports in all tests. I tested the drive speed with nirsoft's USB speed test; 8 GB/s write, 26 GB/s read is the result. I did read the E2B FAQ concerning slow speeds. I haven't tried installing the speedier USB BIOS yet, I will, later. However, I'm inclined to think that the slowness arises from the USB stick rather than the BIOS. I booted other flash drives on those PCs before without any speed issues.

#17 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 07 March 2017 - 09:40 AM

That's incredibly slow! My USB 2 eeePC takes 10 seconds (3s with fast g4d USB driver) and a slow flash drive about 20 at worst.

QEMU is an emulator and will always be slow. For instance, my USB 3 SSD under VirtualBox gives 1 second for 100 loops but QEMU gives 13 seconds.

I suspect your PC BIOSes are running at USB 1 speeds???

Try the Utilities - Install fast grub4dos USB 2.0 driver menu entry and then do the speed test.

Anyway, let's not pollute this thread...

I would be interested in how your grub4dos menu is progressing...

 

P.S. For E2B, P3 is required to be unused for linux+persistence cases.


Edited by steve6375, 07 March 2017 - 09:50 AM.


#18 stepdown

stepdown

    Newbie

  • Members
  • 19 posts
  •  
    Czech_ Republic

Posted 07 March 2017 - 10:38 AM

I agree let's not pollute this thread. I can start a new thread about E2B. Which section is most appropriate?

#19 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 07 March 2017 - 10:39 AM

http://reboot.pro/to...ent-discussion/






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users