[SOLVED] Can't start X when booting from Grub on USB stick

[mrjake2]

I'm creating a USB stick with multiple Linux ISOs on it and I'm having trouble getting X to start on TC when I boot that way.  Booting from Virtualbox with the Tiny Core ISO as the disk image works as expected.

Specifically, I have created a GPT/UEFI USB containing a FAT32 partition with all of my ISOs on it.  I know that UEFI is set up correctly because I can UEFI boot other images I have on the USB and I get proper X support in each of them (Mint, Ubuntu, Kali).  I use Grub to boot the ISOs.  I can boot Tiny Core and get to a command prompt, and I see that it properly loads all of the required libs at boot for X support.  However when I run startx the screen goes black, there is a frozen underline cursor in the upper left corner, and the system becomes unresponsive.  This happens from both Virtualbox and my HP laptop (I've tried both UEFI and Legacy MBR boot).  Interestingly, though, when I boot from the USB stick using qemu (which uses legacy MBR boot), it starts X just fine.

I can't switch to a different tty to look at the log output when this happens since the system is frozen.  However I believe this is a Vesa issue, because when I boot to the command line and run 'XVesa -listmodes', I only get the following:

Code: [Select]

interrupt pointer (seg 0 off 0) doesn't point at ROM
interrupt pointer (seg 0 off 0) doesn't point at ROM
0x0013: 320x200x8 (vga compatible) PseudoColor

It's also worth noting that when I run "xsetup" I don't get the expected list of vesa modes (I'm assuming because the list above is incomplete); I just get a blank line and the program exits.

Here is my grub.cfg entry for Tiny Core:

Code: [Select]

set extract_path="/AIO/Files/Linux/TinyCore-current.iso"
export extract_path

set gfxmode=auto
insmod all_video
insmod gfxterm
terminal_output gfxterm

menuentry "Tiny Core - iso" --class core --class gnu-linux --class gnu {
echo Loading ${extract_path} ...
loopback loop ${extract_path}
echo Loading Kernel ...
linux (loop)/boot/vmlinuz iso=/dev/sda2/${extract_path} loglevel=3 showapps nozswap nomodeset syslog cde text  pause multivt
echo Loading RAM-Image ...
initrd (loop)/boot/core.gz
echo Booting ...
}
On my system I've confirmed that /dev/sda2 is the correct device.  I have also tried adding a boot parameter of "vesa=800x600x32", but that didn't change anything either.

The solution to the problem can be found here:
http://forum.tinycorelinux.net/index.php/topic,23544.msg147796.html#msg147796

    [EDIT]: Marked topic as solved and added a link to the solution.  Rich

[Rich]

Hi mrjake2
Is it possible that  nomodeset  kernel parameter is causing the issue?

[Rich]

Hi mrjake2
I just realized you don't have a  waitusb  option included on the  vmlinuz  line. You can use:

Code: [Select]

waitusb=5for a 5 second delay to wait for the USB device to settle and show up, or:

Code: [Select]

waitusb=15:UUID="6635-DDD1"This will wait up to 15 seconds but continue as soon as the device is detected. Replace  6635-DDD1  with your devices  UUID.

[mrjake2]

Hi Rich - I've actually tried both of those already.  They don't seem to make a difference.  I really doubt the waitusb param has anything to do with it regardless since all of my libraries get loaded correctly from the USB.  I don't see any change to the output of "Xvesa -listmodes" when I remove "nomodeset" from the params, and I get the same behavior with the system freezing.

[Rich]

Hi mrjake2

... I get proper X support in each of them (Mint, Ubuntu, Kali). ...

Are they using  Xvesa , or are they using something else (Xorg or Xfbdev)?

... Interestingly, though, when I boot from the USB stick using qemu (which uses legacy MBR boot), it starts X just fine.

I can't switch to a different tty to look at the log output when this happens since the system is frozen.  However I believe this is a Vesa issue, because when I boot to the command line and run 'XVesa -listmodes', I only get the following:

Code: [Select]

interrupt pointer (seg 0 off 0) doesn't point at ROM
interrupt pointer (seg 0 off 0) doesn't point at ROM
0x0013: 320x200x8 (vga compatible) PseudoColor
...

It appears you don't have or it can't find a  BIOS  or a  video BIOS.  Qemu includes a bunch of  bios  and  vgabios  files.

[mrjake2]

After poking around more tonight, I realized one important thing I said above was incorrect: I double-checked my settings, and I discovered that I actually can boot the Tiny Core ISO from grub - but only in Legacy MBR mode.  I also verified that Grub itself recognizes the available VESA modes by running the 'videomode' command from the grub command line, which showed me all of the expected vesa modes.

So at this point, it seems like the video modes are being correctly loaded by the kernel during MBR boot, but not during UEFI boot.  This seems odd though - shouldn't the kernel know how to look up the available video modes, regardless of whether the disk uses MBR or UEFI?  It's unfortunate, though, as I really need to be able to UEFI boot this for computers that don't have a legacy MBR option (of which there are an increasing number).

In response to your specific questions below:

Are they using  Xvesa , or are they using something else (Xorg or Xfbdev)?

I believe they are using Xorg.

It appears you don't have or it can't find a  BIOS  or a  video BIOS.  Qemu includes a bunch of  bios  and  vgabios  files.

Yep, that makes sense given what I discovered above.  However I'm pretty confused as to why the video BIOS settings are available in Grub whether I boot it from MBR or UEFI, but then they only seem to get passed down to the Tiny Core Linux kernel in MBR, not UEFI.

[curaga]

Vesa is a BIOS thing, so certainly it can be broken by bios settings for integrated graphics at least. Xfbdev works with the EFI framebuffer, and of course you can install Xorg with the many drivers to cover a lot of ground.

[emmi]

Have you tried "set gfxpayload=keep"?

[mrjake2]

I've tried the suggestions above but I haven't had any success yet.  I moved over to a frugal install to hopefully be more in line with the standard way of running TC. Xvesa was still freezing up on my HP Laptop, and Xfbdev simply wouldn't start, so I've tried to get Xorg-7.7 running instead just because it's got good logging.  I can always move back to one of the lighter weight x managers later if possible.

The issue is that whenever I go into gfxmode, whether in the console or in X, I get a garbled screen and can't do anything.  Because of this I can't even get to a command line when I UEFI boot (I believe because UEFI booting always goes into graphics mode), so I've done all my troubleshooting in MBR boot mode.

This is my menuentry from grub.  I've tried it with all of the commented out lines uncommented as well, but when I did that then I was back in graphics mode with a garbled screen and couldn't see the command line anymore.  Commenting them out at least got me the ability to poke around in console mode.

Code: [Select]

loadfont "unicode"
#set gfxmode=800x600,auto
#set gfxpayload=keep
#insmod all_video
#insmod vbe
#insmod vga
#insmod gfxterm
#terminal_output gfxterm

search --no-floppy --label --set=root "AOIBOOT"
menuentry "Core" {
 linux /boot/vmlinuz quiet waitusb=5 pause loglevel=3 showapps syslog text
 initrd /boot/core.gz
}

With a frugal install I am now able to see the available vesa modes using Xvesa (although I do see some weird errors at the top - I'm including those in case it's helpful):

Code: [Select]

tc@box:~$: Xvesa -listmodes
Int 10h (0x4F01) failed: 0x014F (function call failed)
VBE version 3.0 (Intel(R) SKL/KBL Mobile/Desktop Graphics Chipset Accelerated VGA BIOS)
DAC is fixed, controller is VGA compatible, RAMDAC causes snow
Total memory: 65472 kilobytes
0x0013: 320x200x8 (vga compatible) PseudoColor
0x0107: 1280x1024x8 PseudoColor
0x011A: 1280x1024x16 TrueColor [5:6:5:0]
0x011B: 1280x1024x24 TrueColor [8:8:8:8]
0x0105: 1024x768x8 PseudoColor
0x0117: 1024x768x16 TrueColor [5:6:5:0]
0x0118: 1024x768x24 TrueColor [8:8:8:8]
0x0112: 640x480x24 TrueColor [8:8:8:8]
0x0101: 640x480x8 PseudoColor
0x0111: 640x480x16 TrueColor [5:6:5:0]
0x017D: 1920x1080x8 PseudoColor
0x017E: 1920x1080x16 TrueColor [5:6:5:0]
0x017F: 1920x1080x24 TrueColor [8:8:8:8]

output of "lspci -nnk |grep VGA -A3", which looks different from what I get when I run it on Ubuntu (I have Intel integrated graphics 620):

Code: [Select]

00:02.0 VGA compatible controller [0300]: Intel Corporation Device [8086:5917] (rev 07)
Subsystem: Hewlett-Packard Company Device [103c:8544]
00:04.0 Signal processing controller [1180]: Intel Corporation Skylake Processor Thermal Subsystem [8086:1903] (rev 08)
Subsystem: Hewlett-Packard Company Device [103c:8544]

And finally, I'm attaching my Xorg.0.log.  I can see that it's attempting to use 4 different drivers - intel, modesetting, fb, and vesa, but after trying all of them ultimately settles on Vesa.  Beyond that point I'm not sure if any of the errors are actually important or not (one looks like it has something to do with OpenGL), but it again results in a garbled screen.  For what it's worth, I have a working Ubuntu live usb as well, and when I compared the Xorg logs I saw that Ubuntu is using the modesetting driver, not the intel driver.

[mrjake2]

Have you tried "set gfxpayload=keep"?

I gave a more comprehensive reply above, but in short, if I try to set gfxterm/gfxpayload from grub, then I get the same garbled screen when I boot the kernel as I do when I try to start x. 

[curaga]

Please install xf86-video-intel. TC tries to keep minimal deps, and so installing Xorg does not pull in all the various drivers.

[mrjake2]

Please install xf86-video-intel. TC tries to keep minimal deps, and so installing Xorg does not pull in all the various drivers.

I actually already had it downloaded but it wasn't in my onboot.lst.  Putting it at the top of onboot.lst. actually made things worse - the boot screen looks like it starts in console mode, then gets to the point where it shows all the apps it is loading in yellow, and then the screen gets all garbled again even before it gets to the login prompt (I'm assuming it gets garbled as soon as it loads the intel driver).

I'll try to remove it from onboot.lst and see what happens when I log in and try to load it manually, but I expect it will be the same thing.

[mrjake2]

I tried removing xf86-video-intel from onboot.lst, and instead loading it with tce-load after I get to the login prompt.  As expected, the command prompt looks fine when TC first boots up, but as soon as I load the intel driver with tce-load the screen becomes garbled and unresponsive.

[Juanito]

Loading xf86-video-intel loads graphics-KERNEL, which is probably the cause of the lockup.

You could load graphics-KERNEL from the console prompt to double-check?

[mrjake2]

Loading xf86-video-intel loads graphics-KERNEL, which is probably the cause of the lockup.

You could load graphics-KERNEL from the console prompt to double-check?

Hi Juanito -  confirmed.  Loading graphics-KERNEL without xf86-video-intel causes the same issues with the screen.  How can I resolve this?  I'm happy to use VESA modes for this, I just can't seem to get vesa drivers to work either.  As I mentioned above modesetting is the X driver that I've gotten to work with other distros so that would be fine too.