dCorePlus-bionic UEFI/BIOS iso

[Jason W]

I have uploaded a dCoreplus-bionic iso to the release candidates area.  I have test booted it after burning to cdrom and to usb with the dd command on BIOS machines.  The iso also works in Virtualbox in both with UEFI and BIOS booting.  On a modern UEFI machine, the goal is one can burn the iso to cdrom or usb and boot with it, set up wireless networking, then import dCore-usbinstall in the running session to create a UEFI bootable usb that has a tce directory on an ext2 filesystem on the usb.  Syslinux in the iso is version 6.0.4. 

Please download and test, especially those with UEFI boxes. 

http://tinycorelinux.net/dCore/x86/release_candidates/dCore-bionic/dCorePlus-bionic-bios-uefi.iso
http://tinycorelinux.net/dCore/x86/release_candidates/dCore-bionic/dCorePlus-bionic-bios-uefi.iso.md5.txt

[PDP-8]

Good news Jason!

That bionic iso boots up on 4 of my uefi-only machines:  two different model Intel Computesticks, an Acer laptop, and an Intel NUC set for uefi-only.

I did note that on all of the boxes, after the grub menu times out (or if you just hit enter on the Jessie option), there is about a 30 second wait while the screen is totally black.

(not sure if Jessie is just a typo in the grub menu, or part of the kernel 4.14 thing or what ...)

After that 20-30 second period, the large square cpu active graphic blocks appear, followed by the usual boot-stanza vga text.

Intel NUC:  boots to command prompt, but issuing startx brings up the X server.  All other machines boot to gui with no intervention.

Ah, good to see dCore up and running for me again.

[Jason W]

I also see the long pause with only a black screen with both grub and isolinux boot.  I will look into what kind of progress feedback can be done.   Glad to hear it is working on your machines.  On my box with an Nvidia card, I have to issue startx after booting as it falls back into console mode for some reason, but not on a setup with an Intel video chip.

Oops, yeah the jessie entry is a typo, will fix. 

[Jason W]

Ok, I fixed the typo and also grub and isolinux have progress indicators during the loading of the kernel and initrd images.  New isos re-uploaded.

[PDP-8]

YES to the new iso's!

STARTUP - thank you for the progress indicators.  Those of us with Atom processors are keen for cstate lockups, although that is also due to a good kernel config.  Keeping my eye on it, but so far, so good.

SHUTDOWN - all machines properly shutdown, and turn the power off.  However, just before shutdown, I notice this on all:

Code: [Select]

xinit - unexpected signal 15
Virtual Terminals?  Am I supposed to have at least one, or do I need to look at my dCore notes again.

Aterm notes - not a boot specific item, but 3 out of the 4 machines boot up in full resolution on my 1920x1080 monitor.  Looks good, and of course if I add a graphics driver to the one machine, that can be fixed.

However, aterm seems to have no locale?  In other words, my old standby for quickie first-run configurations of

Code: [Select]

aterm -fn 10x20 &
or
aterm -fn 12x24 &
can't load the fonts, although xlsfonts indicates they are available.  I'll add my own fonts later, but perhaps for the total newbie who isn't savvy on the ways to edit .Xdefaults right out of the gate might find these mono-spaced and slightly larger fonts helpful for first configurations.  Especially for uefi-only modern machines with higher resolution displays to start with.

Not a big deal right now, but just an operational kind of note for today's world.

[PDP-8]

Heretical concept:

Maybe save for later discussion not related to booting ...

Retire Aterm as standard?

I noticed in .Xdefaults that urxvt / rxvt is already kind of pre-configured.  Unlike this old gray-beard that likes using aterm with terminus bitmap fonts, perhaps RXVT is the better choice as default because dCore is already set for TTF fonts, the tip about sizing is already in .Xdefaults and so forth.

Think of the children!    Maybe it's time to retire Aterm, (or hide it, yet still be available command-line) and let those who want it get it themselves from the ubuntu / debian repos instead - because those who want it already know it only supports bitmapped fonts, and not TTF and won't pull hairs out trying to make it do so....

[PDP-8]

Another non-boot issue, but maybe pick off this low hanging fruit ...

Trying to activate uxterm from the menu is unsuccessful because ..

Code: [Select]

uxterm tried unsuccessfully to use locale en_US.UTF-8 by setting $LANG to "en_US.UTF-8"
Ok, back to just boot issues ...

[PDP-8]

Heh, more fruit and not much booting talk!

XTERM - aha!  In this one, I *can* bring up a quickie larger font but instead of using "-fn" as usual with aterm, I use "-fa" and it works with no locale probs:

Code: [Select]

xterm -fa 10x20 &
or
xterm -fa 12x24 &
I guess what I'm saying is that for the new kids, there are too many terminal choices and varying options to figure out.

Mentioned again only as it is likely with the uefi-only boxes, the graphics driver already included will drive most displays to the higher native resolutions of today at boot time.

[PDP-8]

Back to real boot issues ..

Well, not a showstopper, but funny!

Intel NUC:
usb stick is second in bios booting bootorder.  bootle-renio neighborino.

If I boot and stand back, hands-off, it will boot up in full native resolution.  ALBEIT I still have to manually issue "startx"

If I manually interrupt the boot by telling the system which device it should boot from (F10 in my case), and point it to the sda device, it will NOT boot in full res.

In this case, manually editing the grub.cfg telling it my native resolution, aka

Code: [Select]

set gfxpayload=1920x1080x24
It will be forced into full res no problem.  OR, I can simply change the bootorder in the bios to make the sda the first in line, and native res again.

But I'm puzzled as to why the differing boot orders in bios seem to affect the graphics res that way.  Not that I need an answer, as I can always cure it by changing my grub.cfg properly.

I'm starting to wonder if halting the grub menu with an "e" just to look around changes things...

Interesting - there must be some sort of weird interplay with gfxpayload commands and their interaction.

Not that it's a problem, because I can fix it easily enough, but I would have been ranting about something like this a few years ago.

[Jason W]

Hi PDP-8.  Thanks for testing.  Multiple terminals are accessed by adding "multivt" to the boot command line.

As for the xinit - "unexpected signal 15"  is seen as X is being killed across the dCore ports.  It does not affect the next boot or the backup.  For reference if one does not want to see this error, then create the file /tmp/k5_skip with the following contents and back it up:

Code: [Select]

xinit

I can't see xterm text in a modern resolution, I have created a file below to make xterm readable for me:

~/.X.d/xterm:

Code: [Select]

#!/bin/sh

xrdb -merge ~/.Xresources


And also a file ~/.Xresources:

Code: [Select]

Xft*antialias: true
XTerm*background:   black
XTerm*foreground:   white
XTerm*cursorColor:  grey
XTerm.vt100.geometry:   80x25
XTerm*scrollBar:    true
XTerm*rightScrollBar:   true
XTerm*saveLines:    10000
XTerm*faceName:     BitStream Vera Sans Mono
XTerm*faceSize:     17
XTerm*toolBar:      off


I don't use aterm or uxterm normally, but I will look into how to deal with them. 


Thanks for your observations in your last post.

[PDP-8]

Ah, thank YOU for doing all this work on dCore!

Multivt - done.  Checked my notes.  Easy fix.

Uxterm not firing up from menu:
AHA!  When uxterm complains about not finding the locale, it is *only* on the Intel NUC, which I have to start the gui manually with startx.  So somehow, the need to manually use startx only on the Intel NUC means I'm probably losing other necessary configs making uxterm unhappy.

Why on the NUC only?  I don't know, but I'll try to find out.

Otherwise, on other machines, uxterm fires up ok from the menu.  Weird.

Losing track of SCE backup drive:
Hm - even after setting the backup properly, it only seems to work with the NUC.  BUT, on the computestick, I have to reset it every time I reboot.  Gotta' feeling a LABEL or UUID would help me there.

Note that I'm using the same usb stick and just moving it from machine to machine in a portable fashion - I'm not dedicating a stick to each machine.

Video resolution circus:
Hilarious because depending on whether I manually choose the usb stick to boot from, or let the bios just time out, when it gets to the grub menu it is either fully screen, or just a smaller square.   And even then, that depends on whether I let the grub menu timeout, or if I interrupt it to look at or modify it with "e" and continue on.

I see no alcohol near me, so we're cool there.

Actually - none of this is a showstopper - but totally fun to discover...

[PDP-8]

Two different .Xdefault files depending on how X starts!

Jason - you're messing with me right? 

I noticed that on the Intel NUC, where I have to use startx to fire up the gui, in .Xdefaults, there are settings for Aterm and URXVT, but no xterm...

Code: [Select]

.
.
urxvt*background: black
urxvt*foreground: white
urxvt*font*xft:DejaVu Sans Mono: size=20
.
.
And so on.  But in order to work with urxvt / rxvt, I have to change at least the first letter to uppercase... but that's why I was thinking that rxvt (which can use the Urxvt syntax in .Xdefaults) was already on board.

But let's move on ...

The machines which boot up straight into the gui, have XTERM  configurations at the end of the .Xdefaults file...

So looks like there are two .Xdefaults on board, and if you have to manually start the machine with startx, it will pick up the one that has urxvt configs.  Otherwise, if it boots straight into gui, you'll see the other .Xdefaults with the xterm configs.

Ok, maybe I will have a drink now.

[PDP-8]

BAD NEWS: I found the problem for my mayhem..

Seeing mydata.tgz in a few places they shouldn't belong, I started over with a fresh-burn (gpt of course) and looked closely.

Partition Troubles:
Intel Computesticks and the Acer Laptop:

All three of these machines only recognize one partition, and it *isn't* automounted.  That partition contains the filesystem with this on it

Code: [Select]

EFI/   boot/   release.txt   isolinux   syslinux.cfg
I removed some ctrl-m's from the syslinux.cfg file, but that seems only cosmetic.

That's the only filesystem recognized.  In my haste during earlier testing, it will allow you to set this as the "tce set-drive".  Probably not the best place for mydata.tgz

But that's the only choice on these machines.

INTEL NUC
This one actually detects partitions properly.  It will in fact automount both partitions on the drive.  Of course, you need to set your tce set-drive properly to the proper partition.

What was freaking it out was apparently seeing the mydata.tgz that was created on the wrong partition from the other machines.  And informing me I had already set my tce set-drive and not allowing modification from the tool.

When I thought something was funky, that is when I deleted all the mydata.tgz, and thats when the lightbulb went off and I started over fresh and noticed the issue with the chromesticks and the acer.

So only the Intel NUC is really usable real-world right now.  Starting over also solved all the terminal weirdness and even boots straight into X no problem.

I can't explain why the other machines only see the wrong partition though...

[PDP-8]

Jason - nevermind my drama..

I found an old tce directory on the hard drive on the NUC from a project about a year ago.  Yeah, not good.

Taking a break - like sleeping for a week....

Not my thread so someone else uefi jump on in!

[Jason W]

Are you using dCore-usbinstall after booting the iso off that was burned (dd' d) to usb?, as that will create a GPT first partition and an ext2 second partition.  The GPT partition created is 30MB larger than the sum of the size of the files that will be contained on it.  The ext2 second partition uses the rest of the space on the usb.  The tce directory is automatically created on the ext2 partition on first boot of the created usb.  The partition of the tce directory is specified by label in the boot command line used on the usb's boot config file so it will only use that one. 

Or was the usb you tested with created with dd or Rufus?

Thanks.