-   Slackware - Installation (
-   -   slackware install on asus vivotab note 8 (m80ta) or other bay trail tablet. (

ElfShotTheFood 08-03-2014 10:31 PM

slackware install on asus vivotab note 8 (m80ta) or other bay trail tablet.
Greetings, i am a longtime user of lq but have never needed to actually log in and make a post because i have always managed to search and find the answer i have needed up until now.

i have an asus vivotab note 8 (m80ta) tablet that i would love to be running slackware on, unfortunately the only info available about running linux on this type of machine is for the asus t100 and ubuntu, which is not a flavor of linux that i am interested in. since there is no info available anywhere that i can find, i figured starting a thread here wouldn't be a bad thing

relevant links are

basically, this machine has very similar hardware to the asus t100, and other tablets like the dell venue8 pro but with the addition of a wacom stylus. it is an intel "bay trail" tablet that runs windows 8.1 and can be found rather cheap right now if you look carefully.

anyway, these machines need a bootia32.efi to boot from, instead of the normal x86_64.efi that slack64 boots with. i downloaded the july 23rd edition of the slackware64-current iso from, dd'ed it to a flash drive and since it was read only copied the files to a different flash drive and added the bootia32.efi to the /EFI/BOOT/ folder. this booted me to a simple grub command line in which i tried typing the command line from the /EFI/BOOT/grub.cfg, it managed to boot the kernel, but had a panic that i could not see before it scrolled past and would not scroll back up.

i need to find a way to make a flash drive boot with bootia32.efi and start slackware setup just like a normal boot disk would. i have a decent amount of free space ready for the install, but i have no real idea how to make this happen. anyone have a better idea how to get this little tablet to boot into setup?

i knew going in that getting everything configured and running on this cool little piece of hardware would be a difficult task, but instead i have started the process and hit an immediate brick wall. i have happily used lilo in all my years of slacking and have really no experience at all with grub.

i think it would be great if we could make a boot image for these devices ready for the next official slackware release.


Didier Spaier 08-04-2014 02:49 PM

Hi ElfShotTheFood,

Welcome to LQ after all these Slackware years and congrats for this first post!

I think that your best bet would be to just modify slightly the script that Pat uses to build /EFI/BOOT/bootx64.efi and /isolinux/efiboot.img, just changing the format from x86_64-efi to i386-efi and naming the efi file bootia32.efi instead of bootx64.efi and see what you come up with.

I'm used to modify the installer so if you want I can provide a modified mini-iso within one hour or so, that I would make hybrid (usable on a CD as well as an USB stick).

Just a question: I saw that the Intel Atom Z3740 is a 64 bit SoC, but as we'll use a 32 bit boot sector, shouldn't we ship a 32 bit Slackware installer in the mini-iso?

PS in any case /isolinux/efiboot.img should be rebuild to include the new efi file in /EFI/BOOT

PPS: it will took me longer than expected: I just realized that in Slackware the grub package doesn't ship the modules for i386-efi, so I'm rebuilding a package.

ElfShotTheFood 08-04-2014 06:27 PM


Originally Posted by Didier Spaier (Post 5214879)

PPS: it will took me longer than expected: I just realized that in Slackware the grub package doesn't ship the modules for i386-efi, so I'm rebuilding a package.

yeah, when i tried to run the make-grub script it failed with a missing moddep file. i have the very recent grub source from git, what do i need to run to build a new package with the i386-efi stuff?

edit, and will my amd64 laptop cause compile problems?

edit2 gonna try the slackbuild script in the source folder,,,,, duh

edit3 build failed

.deps/argp-eexst.Tpo -c -o argp-eexst.o argp-eexst.c
In file included from argp.h:22:0,
from argp-eexst.c:25:
./stdio.h:456:1: error: 'gets' undeclared here (not in a function)
_GL_WARN_ON_USE (gets, "gets is a security hole - use fgets instead");
make[4]: *** [argp-eexst.o] Error 1

Didier Spaier 08-05-2014 09:34 AM


Originally Posted by ElfShotTheFood (Post 5214950)
i have the very recent grub source from git, what do i need to run to build a new package with the i386-efi stuff?

Yes, but you can use the source tarball shipped in the source folder.

As is, the SlackBuild first builds the modules for the x86_64-efi target only if EFI_FLAGS is set (hence only if ARCH is set to x86_64), then for the i386-pc target. I assume that Pat wrote it that way because he mainly wanted to use grub to provide EFI-able installers for the 64 bit Slackware.

I just added the line in bold below:

elif [ "$ARCH" = "i486" ]; then
  SLKCFLAGS="-O2 -march=i486 -mtune=i686"
  EFI_FLAGS=" --with-platform=efi --target=i386 --program-prefix= "

and succeeded in building then installing the package in my Slackware-14.1 (32 bit).


and will my amd64 laptop cause compile problems?
The laptop itself no, but using a 64-bit Slackware maybe (but I stay in doubt as even in Slackware64-14.1 the modules for i386-pc are shipped). Anyhow I played it safe and built the modules for i386-efi on a 32-bit Slackware.

Of course you'd have to modify the SlackBuild to provide the i386-efi modules while running it on a 64 bit Slackware though.

I guess that you'll prefer to do that stuff yourself, nevertheless I've put two hybrid ISO images in that you can put on an USB stick just using the dd command. Of course they contain only the installer, so you'll need a separate source of packages. The modified script lies in the /EFI/BOOT folder of each ISO.

Both ISO images contain /EFI/BOOT/bootia32.efi and modified /isolinux/efiboot.img, but one ships the 64 bit initrd and kernel, the other one the 32 bit initrd and kernels.

I just realized that I forgot to remove /EFI/BOOT/bootx64.efi from the 64 bit version. I hope that doesn't hurt but will upload a corrected ISO image with an increased build number just in case.

PS Before someone asks, here is the script used to build the ISO images:

# set SUFFIX as "" or "64" before running me.
# iso and iso64 contain just the /EFI, /kernels  and /isolinux directories
# copied from a Slackware media (EFI added ditto 64 bits for 32 bits).
(cd iso${SUFFIX}
mkisofs -o /tmp/slint${SUFFIX}-14.1-m80ta.iso \
-rational-rock -J -A 'Slackware Install' \
-hide-rr-moved \
-v -d -N \
-no-emul-boot -boot-load-size 4 -boot-info-table \
-sort isolinux/iso.sort \
-b isolinux/isolinux.bin \
-c isolinux/isolinux.boot \
-eltorito-alt-boot -no-emul-boot -eltorito-platform 0xEF \
-eltorito-boot isolinux/efiboot.img \
-V 'Slackware' .
) 2>>${TMP}/log.txt
isohybrid -u /tmp/slint${SUFFIX}-14.1-m80ta.iso

ElfShotTheFood 08-05-2014 11:19 AM

That is awesome. Thank you sir. I must now fight the urge to leave work early and go home to try these out.

I will also see if they work on my sons dell venue8 pro tablet, but he does not yet want Linux installed on it.

Thanks again.

Didier Spaier 08-05-2014 12:49 PM

We don't know if one of these ISO image works on your machine yet...

Anyhow I'm uploading the new slint64-14.1-m80ta-1.iso, that should be done within 35 minutes according to gftp.
EDIT: done.

I should have downsized efiboot.img as bootia32.efi is smaller than bootx64.efi. Oh, well...

ElfShotTheFood 08-05-2014 03:40 PM

all three isos booted straight to the grub command prompt and stopped.......

Didier Spaier 08-05-2014 03:48 PM

You mean that you don't even see the grub's menu (you should see 3 entries)?

Just to make sure that you need a 32 bit EFI, could you try this one:
md5sum is

ElfShotTheFood 08-05-2014 04:45 PM

did not come up with ant menu choices, just the cmd line.

iso 4 did not boot at all

Didier Spaier 08-05-2014 04:52 PM

Then I'll cook an ISO with the same grub modules as here.

EDIT: I am missing the "eval" module in grub-2.0.0. It's late here, see you soon.

ElfShotTheFood 08-05-2014 06:44 PM

thanks again, i really appreciate all your help

ElfShotTheFood 08-05-2014 09:34 PM

from README_UEFI.TXT in the 32bit slackware current

32-bit versions of Slackware do not support UEFI, since the firmware is 64-bit
and conflicts with a 32-bit kernel. To run Slackware on UEFI machines, you'll
either need to use Legacy BIOS mode (if supported by the firmware), or obtain
the 64-bit version of Slackware.

found some other interesting stuff about the grub cmd line here

here are the relevant bits

The proper direct kernel boot is the same thing as direct booting via symlinks except we type in the exact filepath and filenames of the specific kernel and initrd.img files, like this,
grub> linux (hd0,1)/boot/vmlinuz-2.6.27-9-generic root=/dev/sda1
grub> initrd (hd0,1)/boot/initrd.img-2.6.27-9-generic
grub> boot

i had previously tried one really long cmd line from grub.cfg. adapting the above quote to the huge.s kernel and the isolinux/initrd.img got the kernel to boot without a panic, then it switched video modes and the screen stayed blank. hopefully it was slackware setup waiting for me to select a keyboard map and then login as root in an unsupported video mode. gonna go look for a vidmode in one of the asus t100 links in the first post.

edit; the second link, in the first post showed a setting of

video=VGA-1:1368x768e reboot=pci,force

i got a scrambled screen with a blinking cursor that looks like the select a keyboard map screen. gotta figure out the right vidmode. : )

yes, setup is running with scrambled graphics. wooohooo

anyone know how to probe video modes, or tell the kernel not to switch modes?

Didier Spaier 08-06-2014 03:35 AM


Originally Posted by ElfShotTheFood (Post 5215926)
from README_UEFI.TXT in the 32bit slackware current ...

Yes, that's because bootx64.efi and efiboot.img are built with the format x86_64-efi, if I understand well, and Pat probably made this choice because most (but not all) EFI machines need that nowadays.

But in the format i386-efi is used instead, that's why I built accordingly.


[...] then it switched video modes and the screen stayed blank.
Most probably because the handover failed, i.e. the kernel first did set the video mode, then the video driver initially used was removed and another one tried take over the display -- but failed.

Usually this can be cured just appending " nomodeset" to the command line, to prevent kernel mode setting.


anyone know how to probe video modes, or tell the kernel not to switch modes?
The usual way to probe video modes is to include "vga = ask" in the command line, but I don't now if that works in this case.

To tell the kernel not to switch modes you include the " nomodeset" kernel parameter in the command line, as stated above. Sometimes including "vga=normal" in the command line can help.

This document, though basically intended for users of the nouveau driver, is worth reading for anyone interested in kernel mode setting.

As you seem to have founded a promising path, I'll wait for your feedback before trying to make another ISO image.

ElfShotTheFood 08-06-2014 05:05 AM

Nomodeset and vga=normal both gave me the blank screen unfortunately.

Didier Spaier 08-06-2014 11:26 AM

If you are able to go as far as (fake) login as "root" (just before typing setup) then you should be able to grab useful information from your system.

I suggest that you remove the USB key (you don't need it after you have "logged in", as the whole installation system then lies in RAM), plug-in and mount another one (you could just make a mount point for that like /key) then issue following commands:

cat /proc/fb > /key/fb.txt
cat /proc/cmdline > /key/cmdline.txt
cat /proc/cpuinfo > /key/cpuinfo.txt
dmesg > /key/dmesg.txt
lsmod > /key/lsmod.txt
uname -a > /key/uname.txt
lspci -knn | grep -A3 VGA > /key/lspci.txt
umount /key

and maybe others that you'd find useful, then post the results here.

Also, could you tell us exactly what you did to go that far (I mean, being able to run setup)?

All times are GMT -5. The time now is 12:28 AM.