Tiny Core Linux
Tiny Core Base => TCB Talk => Topic started by: tucari on August 10, 2015, 03:00:17 PM
-
Hi there!
Long time lurker, first time poster.
I've been trying without too much luck to get TinyCore PXE booting to X. I'm loading using iPXE:
kernel http://192.168.0.28/vmlinuz64
initrd http://192.168.0.28/modules64.gz
initrd http://192.168.0.28/rootfs.gz
initrd http://192.168.0.28/initramfs.gz
I need the 64bit kernel as it is the only one to boot on our Mac Pros from the EFI version of iPXE. The initramfs contains the extensions from TinyCore-6.3.iso cde folder... laid out into /tmp/builtin/optional.
The extensions are loading, but I'm getting "failed in WaitforX" error on boot.
I'd really like to get the whole thing working in a single initrd, but that seems a long ways away considering this prob i'm having!
If I use the 32-bit kernel, the system boots fine. I was reading about Xvesa not being supported on 64-bit but assumed this was corepure64 related. If that's the case which are the base extensions needed to boot to X using the 64-bit kernel?
Thanks you so much in advance.
-
You cannot use 32 bit tczs with corepure 64 bit kernel.
Use tinycorepure64.
Why not use nfs for the tce directory. That way you pxe boot and it behaves like it is on a hard drive.
http://wiki.tinycorelinux.net/wiki:netbooting
-
You cannot use 32 bit tczs with corepure 64 bit kernel.
Use tinycorepure64.
Why not use nfs for the tce directory. That way you pxe boot and it behaves like it is on a hard drive.
http://wiki.tinycorelinux.net/wiki:netbooting
Gerald,
Many thanks for your reply.
Apologies for my ignorance, but Is there any way to run a 64-bit kernel and run a 32-bit userspace with tinycore? I have no need to run 64-bit programs, but need to boot from a 64-bit UEFI kernel.
Thanks again
Jon
-
..Is there any way to run a 64-bit kernel and run a 32-bit userspace with tinycore? I have no need to run 64-bit programs, but need to boot from a 64-bit UEFI kernel.
There is a way - vmlinuz64, modules64 and rootfs - as opposed to vmlinuz64, modules64 and rootfs64 for corepure64.
Whilst corepure64 boots uefi for me, I'm not sure that core64 ever did...
-
..Is there any way to run a 64-bit kernel and run a 32-bit userspace with tinycore? I have no need to run 64-bit programs, but need to boot from a 64-bit UEFI kernel.
There is a way - vmlinuz64, modules64 and rootfs - as opposed to vmlinuz64, modules64 and rootfs64 for corepure64.
Whilst corepure64 boots uefi for me, I'm not sure that core64 ever did...
Cheers,
That is exactly what i've been doing, but X will not start. In the scenario you describe, is Xvesa the likely culprit?
Thanks
-
There is no 64-bit version of Xvesa
-
You can replace Xvesa with Xfbdev, and add a vga=xxx bootcode in your bootloader.
-
You can replace Xvesa with Xfbdev, and add a vga=xxx bootcode in your bootloader.
Absolutely, positively fantastic! this worked an absolute treat. Thanks so much to everyone for their help. I now finally have an image that I can netboot via PXE and also BDSP on PC and Mac! Now just need to compile partclone into a tcz and I've got an awesome base for a netbooted machine imager.
-
One more peculiar issue, Xfbdev comes up perfectly on the PC but on the Mac (which is booting the kernel via iPXE-EFI) the vga= line is being ignored and coming up at the native res of the screen... and is also inverted (the background is a nice orange colour)... I have tried dropping to prompt and using Xfbdev -screen 1024x768 but it continues to load at my native 2560x1080
It is definitely being passed the kernel options because quiet works (and I also seemingly need to specify initrd=core.gz for the mac to find root)
-
Try vga=ask and see what vesa modes are available for the frame buffer.
You could also try Xorg.
-
Yeah, EFI ignores the resolution, only taking the presence of vga=xxx into account, signing that the framebuffer should be used. Inverted colors should not happen though.
edit: If you look at the "c" in the core logo in the center, is it white or brown?
-
http://www.spinics.net/lists/linux-fbdev/msg08940.html
> Probably efifb should be looking at something to determine if display
> is RGB or BGR...
Right - normally we get it from the firmware graphics driver, but on a
few generations of Intel Macs they gracefully omitted an implementation
of that part of the spec, which is why we have a DMI table that just has
best-effort entries.
Go Apple.
-
Hi gents,
This seems to be a problem that Apple, in their infinite wisdom, have created. I'm using a Mac Pro 4,1 but will test this further on our newer machines. Its purely a cosmetic issue though: i'm using tinycore to run apps for cloning (the apps are custom, but will use partclone in the background to do the heavy lifting). We clone up to 10 machines at a time (video editing facility) so I'm writing a server based system that can manage the process from a central webgui (not unlike FOG).
Regarding the Red and Blue switch, I've been reading up on it and there seems to be a patch floating around for fbdev... i shall get that compiled and get back to you. I have tried Xorg, with the same issue so will probably stick with xfbdev just for simplicity. I don't really want to get into using anything other than framebuffer because we have many different machines, both pc and mac, booting this image. Xfbdev-old also exhibits the same problem. If i take a screenshot it comes up normal so here's a picture... SMPTE bars confirm red/blue switch.
Thanks again
(http://s23.postimg.org/k6gr3n0d3/image1.jpg) (http://postimg.org/image/k6gr3n0d3/)
(http://s23.postimg.org/l671zcfiv/image2.jpg) (http://postimg.org/image/l671zcfiv/)
(http://s23.postimg.org/sng9ek51z/image3.jpg) (http://postimg.org/image/sng9ek51z/)
-
The info on what the color channels are comes from the kernel, so ideally it'd be fixed there. You could add an option in Xfbdev to flip the channels, but then you'd have to detect when to use the option - same effort as having the kernel detect it.
-
The info on what the color channels are comes from the kernel, so ideally it'd be fixed there. You could add an option in Xfbdev to flip the channels, but then you'd have to detect when to use the option - same effort as having the kernel detect it.
Hmm, would appear this could be an issue considering the Mac's lacking EFI. We have many 4,1's.. some with NV cards, some with ATI. I have a suspicion that the ATI's would probably be fine and will try this theory tomorrow. Was not an issue I was expecting, i must say! tinycorepure64 also exhibits the same problem, would the kernel be the same as the one i'm using? I've tried using Xorg with the NV driver but get a black screen (I'm assuming because it requires a kernel module, and the tcz is for a 32-bit kernel). If I were to get this working, would Xorg automatically detect the card and use the appropriate driver?
Many thanks
EDIT: was reading that Nouveau driver should work with EFI and i guess this will also fix my resolution issue (i'm not going to be able to change the framebuffer res even if the color problems go away). I've added the driver to my image and it is loading, but Xorg is still using framebuffer... :(
-
We have only one official 32- and one 64-bit kernel per release, so yeah, the same.
Nouveau is pretty buggy, I wouldn't recommend using it. Your black screen was probably caused by that, not wrong configuration or similar.
Of course you could hack around it and make your GUI greyscale ;)
-
Cheers for the reply.
I could hack around it as I'm using opera in kiosk mode, and could flip colour channels on the fly. Just seems like a bit of a filthy hack! :) Add to that the fact that I'm not exactly sure which machines this is going to occur on. Haven't get tried it with a Mac 4,1 with a Radeon. Couldn't get nouveau working, the card is quite old (GT120). I wonder if there is anything that can be changed in efifb to flip the framebuffer before starting Xorg... will have to have a poke around. As I'm booting from iPXE I can determine the machine model and boot a seperate kernel for these machines if need be, and keep an initrd consistent for Mac and PC. is there any way to talk to efifb from kernel args?
Thanks
-
efifb has no such option. The options it has are base, stride, width, height - nothing for colors.
-
Curaga,
Thanks again for your help.
I've been trying to get an nvidia driver working, with zero success. I assume this is because I am running the 64-bit kernel, and the nvidia and nouveau tcz's contain kernel modules for the 32-bit kernel. would this be correct?
If I were to compile one of these drivers on corepure64 then move the module, is this likely to work?
all the best.
jon
-
Hmm, that didnt work :) I think maybe i'm confusing what is required here.
The NV driver at least makes the screen go black, so xorg is actually trying to use it.. now to somehow get the logs when this happens .. :)
-
The kernel won't load incompatible modules, and the -nv driver doesn't use kernel modules at all. Any extension with modules has the kernel version in the name. Nouveau is not shipped at all given how unstable it is.