Tiny Core Linux
Tiny Core Base => TCB Q&A Forum => Topic started by: mrjake2 on February 21, 2020, 05:11:02 PM
-
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:
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:
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
-
Hi mrjake2
Is it possible that nomodeset kernel parameter is causing the issue?
-
Hi mrjake2
I just realized you don't have a waitusb option included on the vmlinuz line. You can use:
waitusb=5for a 5 second delay to wait for the USB device to settle and show up, or:
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.
-
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.
-
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:
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.
-
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.
-
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.
-
Have you tried "set gfxpayload=keep"?
-
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.
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):
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):
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.
-
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.
-
Please install xf86-video-intel. TC tries to keep minimal deps, and so installing Xorg does not pull in all the various drivers.
-
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.
-
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.
-
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?
-
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.
-
Do you have either very old or very new graphics hardware?
Do you know the exact name of your graphics hardware (for example intel hd 4200)?
-
Do you have either very old or very new graphics hardware?
Do you know the exact name of your graphics hardware (for example intel hd 4200)?
My hardware is Intel HD Graphics 620. Not especially old or new - it's a laptop I bought at the beginning of 2019, but it looks like that graphics hardware has been around since 2016.
-
The arch wiki recommends not using “nomodeset” or “vga=“ when using xf86-video-intel.
See: https://wiki.archlinux.org/index.php/Intel_graphics
-
The arch wiki recommends not using “nomodeset” or “vga=“ when using xf86-video-intel.
See: https://wiki.archlinux.org/index.php/Intel_graphics
I've tried it both with and without "nomodeset", and both with and without "vga=" - it doesn't seem to make a difference. This is my current grub menuentry, which is resulting in the behavior I described in the last couple posts:
search --no-floppy --label --set=root "AOIBOOT"
menuentry "Core" {
linux /boot/vmlinuz home=LABEL=persistence opt=LABEL=persistence tce=LABEL=persistence quiet waitusb=5 pause loglevel=3 showapps syslog text
initrd /boot/core.gz
}
-
Can you confirm which version of tinycore you're using - x86 11.x?
-
Can you confirm which version of tinycore you're using - x86 11.x?
I am using the one at this link:
http://tinycorelinux.net/11.x/x86/release/TinyCore-current.iso
I had been trying with 10.1 before that and I saw the exact same issues.
It's probably worth noting that on several forums (Gentoo, Arch) I saw people saying that they recommended NOT using the xf86 intel drivers, but instead using the modesetting drivers that are now built into Xorg. When I look at all the other distros I have working on that laptop (Ubuntu, Mint, Kali, Kanotix), all of them use Xorg, and all of them end up using the modesetting driver. I thought I'd try that, but can't figure out how to make that happen in Tiny Core.
-
The modesetting driver is included with xorg-server - if you don't load xf86-video-intel, it will try to load the modesetting driver next.
-
The modesetting driver is included with xorg-server - if you don't load xf86-video-intel, it will try to load the modesetting driver next.
That's what I thought, but when I try to load Xorg without the intel drivers I get this error:
[ 984.765] (EE) open /dev/dri/card0: No such file or directory
[ 984.765] (WW) Falling back to old probe method for modesetting
[ 984.765] (EE) open /dev/dri/card0: No such file or directory
[ 984.765] (EE) Screen 0 deleted because of no matching config section.
For what it's worth, the person in this Gentoo thread had almost exactly the same errors that I got when I don't include the xf86-video-intel drivers:
https://forums.gentoo.org/viewtopic-t-1085452-start-0.html
In his case he finally resolved it by updating his kernel version, but I double checked with uname -r and I definitely have 5.4.3-tinycore. I read through all the suggestions in that thread and they mostly seemed to deal with recompiling the kernel with intel video driver support in the kernel itself rather than as a module. I'm not sure how much of a difference that would make. I'm not an expert, but from reading that thread it sounded like i915 support needed to be enabled in the kernel even if you wanted to use the modesetting drivers.
-
ah - it looks like the modesetting driver needs graphics-KERNEL:
...
[ 82.029] (II) modeset(0): using drv /dev/dri/card0
[ 82.029] (II) modeset(0): Creating default Display subsection in Screen section
"Default Screen Section" for depth/fbbpp 24/32
[ 82.029] (==) modeset(0): Depth 24, (==) framebuffer bpp 32
...
You could try recompiling the kernel with i915 built in?
-
ah - it looks like the modesetting driver needs graphics-KERNEL: ...
[ 82.029] (II) modeset(0): using drv /dev/dri/card0
[ 82.029] (II) modeset(0): Creating default Display subsection in Screen section
"Default Screen Section" for depth/fbbpp 24/32
[ 82.029] (==) modeset(0): Depth 24, (==) framebuffer bpp 32
...
You could try recompiling the kernel with i915 built in?
I can try that tomorrow. It's been probably 25 years since I've compiled my own Linux kernel and I'm a bit rusty. Can I just follow any of the guides out there on how to compile your own kernel? Anything specific I should be aware of regarding compilation for Tiny Core? And finally, does this just require me to make that single change, i.e. change "CONFIG_DRM_I915=m" to "CONFIG_DRM_I915=y"? Do I also need these options that were mentioned in that thread?
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE="i915/skl_dmc_ver1_26.bin"
CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"
-
I am using the one at this link:
http://tinycorelinux.net/11.x/x86/release/TinyCore-current.iso
Hi, guys!
Maybe mrjake2 need to work with 64-bit stuff?
-
You can use the tinycore patched kernel and config from here:
http://tinycorelinux.net/11.x/x86_64/release/src/kernel/
..but, as mentioned, it might be worth trying CorePure64 first.
-
Compiling i915 in vs a module shouldn't change anything - very likely you'd still get the same glitched screen. That firmware mention is new, I didn't know Intel graphics now need firmware (most old ones didn't). So please try first with firmware-i915 and graphics- loaded.
-
Compiling i915 in vs a module shouldn't change anything - very likely you'd still get the same glitched screen. That firmware mention is new, I didn't know Intel graphics now need firmware (most old ones didn't). So please try first with firmware-i915 and graphics- loaded.
Thanks for all the ideas - it's not working yet, but I'm seeing progress.
Switching to TinycorePure64 made it so that I can boot up in UEFI, meaning gfxterm is working now. So at least now I know there is a graphics mode that works on my laptop, I just need to figure out how to get Xorg to recognize it. I tried two different things:
1) loading firmware-i915 and graphics-KERNEL (in that order)
2) loading firmware-i915,graphics-KERNEL,and xf86-video-intel (in that order)
For #1, I see the Tinycore blue background image flash up on the screen very briefly (less than a second), and then it goes black. Switching to another TTY this is the Xorg.0.log output I see:
modeset(0) using drv /dev/dri/card0
modeset(0): Creating default Display subsection in Screen section
“Default Screen Section” for depth/fbbpp 24/32
modeset(0): Depth 24, (==) framebuffer bpp 32
“: RGB weight 888
“: Default visual is TrueColor
(II) Loading sub module “glamoreg1”
Loadmodule: “glamoreg1
Loading /usr/local/lib/xorg/modules/libglamoreg1.so
Module glamoreg1: vendor “X.Org Foundation
compiled for 1.20.6, module version = 1.0.1
ABI class: X.Org ANSI C Emulation, version 0.4
couldn’t get display ddevice
EE modeset(0): glamor initialization failed
I also see this error further down:
(II) AIGLX: Screen0 is not DRI2 capable
(EE) AIGLX error: dlopen of /usr/local/lib/dri/swrast_dri.so failed (/usr/local/lib/dri/swrast_dri.so: cannot open shared object: No such file or directory)
(EE) AIGLX error: unable to load driver swrast
(II) Initializing extension xFree86-VideoModeExtension
(II) Initializing extension xFree86-DGA
(II) Initializing extension xFree86-DRI
modeset(0): damage tracking initialized
modeset(0): Setting screen physical size to 504 x 294
For #2, I get the following error after I try to load xf86-video-intel:
mount: mounting /dev/loop74 on /tmp/tcloop/xf86-video-intel failed: Invalid argument
Of course because of the error I get for #2, when I run startx it just exhibits the exact same behavior as in #1.
-
swrast_dri.so is provided by Xorg-7.7-3d
-
swrast_dri.so is provided by Xorg-7.7-3d
I just added that but I'm still seeing the behavior described above. I looked at the logs and that made the swrast error go away; now the only error left in the log is the one about glamor initialization, so I suspect that's the real issue.
-
"mount: mounting /dev/loop74 on /tmp/tcloop/xf86-video-intel failed: Invalid argument" sounds like a corrupted download. Please check its md5sum.
-
Thanks to everyone who helped on this - I believe my video issues are solved, and now I'm on to trying to get my touchpad working (I'll start a new thread for this to help with searchability). The suggestions above got both Modesetting and Intel drivers working under Xorg; the reason I was getting the black screen was because my onboot.lst didn't include flwm_topside, so there was no window manager (which is why I wasn't seeing any errors!)
I don't see a way to update my original post to say SOLVED with an explanation (someone tell me if there's actually a way to do this). But for anyone else who runs into similar issues in the future, this was the final resolution.
- I was unable to use Xvesa on my HP laptop with Intel HD Graphics 620 at all. Standard Tiny Core did not work, and in fact I couldn't even boot to a graphical terminal in either MBR or UEFI boot modes.
- Moving to Core Pure 64 instead fixed this. I was then able to boot in both MBR and UEFI boot modes.
- Xvesa is unfortunately not available in 64-bit (several forum posts about this), so Xfbdev and Xorg are the only available options. Xfbdev uses significantly less memory than Xorg, but still not as little as Xvesa (looks like around 118M vs 70M or so)
- After switching to Core Pure 64, simply using tce-load to install flwm_topside and aterm allowed me to start X using either Xfbdev or Xorg (of course I needed to install either Xfbdev or Xorg-7.7 as well, respectively). No other packages were necessary.
- Installing firmware-i915, graphics-KERNEL, and xf86-video-intel got rid of all the errors in the Xorg logs, although flwm worked fine even without loading them. I suspect that the errors had to do with acceleration and would impact performance, but not basic functionality.
Additionally, Curaga was correct - my xf86-video-intel download was corrupt. Deleting and redownloading got rid of that error.
-
Hi mrjake2
I will mark your original post as solved and add a link to your last post.