Android-x86 GRUB2?
 

I'm trying to use GRUB2 to boot Android-x86. The following menu entry works fine on a ThinkPad 20FR but not 20UB (which just boots to Android command-line).

I would use the UUID of the partition rather than relying on BIOS generated names.
I'm only guessing, but i'd say that android probably couldn't find it's root partition during the boot process on the 20UB.
Screenshots (even off your phone) are very helpful for diagnostics.

I didn't use a BIOS generated name; I used the name of the partition I installed Android on, which has identical configuration/partitioning scheme to the similar/variant device (ThinkPad 20FR) Android works on.

You didn't really read, did you? It already boots to this partition on the ThinkPad 20UB laptop (what I said it is) but just boots to Android command-line/shell (it's not a rescue shell but bash or something).

Well without screenshots or error messages, your post leaves a lot of room for interpretation.
Perhaps you could post some more useful information rather than attacking the person trying to help?

I wasn't attacking, just pointing out you missed a couple things including that it's a laptop. I don't know of a way to take a screenshot in Android shell and there is no error message. It just says the following.

The command ls shows files/directories/folders with 'android' in them and I can also su, so as originally said, Android does actually boot, just doesn't start GUI. Where would I get an error message about that?

Not super familiar with android x86, but you can always take a photo with your phone & post that.
I found a similar issue over on stackoverflow where one of the answers suggests to modify your boot options to force the use of the vesa graphics driver. This feels like the right answer to me
http://https://stackoverflow.com/questions/18223402/how-to-start-gui-from-command-line-in-android-x86#:~:text=To%20fix%20this%2C%20you%20have,then%20boot%20to%20Android%20GUI.

As in the Stack Overflow answer, I added 'nomodeset xforcevesa' after linux in /etc/grub.d/40_custom, and regenerated /boot/grub/grub.cfg but this didn't change anything... that was for Android 8.1 but I have 9.0 (latest on Android-x86.org last time I checked).

so it would appear that to access the system logs in android, you need to run "logcat" from the command line.

if you run:
logcat -d > /sdcard/log.txt

you should get a log file that we can examine to figure out what is actually happening.

I couldn't create a log because Android-x86 started read-only, and I couldn't find out how to mount a USB flash drive to write to instead (dmesg, /dev, lsusb being different, and there's no lsscsi).

you can remount your filesystem as rw

# mount -o remount,rw /sdcard

you may need to adjust the mountpoint to suit your system

With those instructions I managed to get a log but it's about 422KB... don't know that it'd fit here and may be better to put somewhere else...

You can post to pastebin and share the link

Android-x86 log
 

Here's the Android-x86 log though I'm not expecting anyone to look through much of this because it's almost half a megabyte, so unless you know exactly what things to search for, I don't want to waste a lot of people's time. I still have the older ThinkPad I can use if I really want to use Android. I wish I could report this to Lenovo but they'd probably just say they don't 'support' Android...

I can see from the log that patchoat is failing to load, this is what brings up your ART (android runtime).
it seems to be attempting to load an address that is not available on the newer machine.
have you tried a fresh install on the newer machine? IIRC android can be a bit funny about changing hardware since it's designed for phones & tablets

On a deeper reading of the log, your android install is referring to it's internal config files to locate hardware that was configured at install time.
This is not being found since it's booting on fundamentally different hardware.
I think without significant re-writing of configuration files, you'll have a lot of trouble running the same installation on multiple devices.
I suggest having individual installations per hardware configuration.