dCore-focal

[PDP-8]

Starting to stray into thread drift ... getting my dCore mojo back.

The answer of course is to sce-import dCore-usbinstaller.  How could I forget that....

I tried that, but using the current Focal release-candidate as the platform to launch dCore-usbinstaller.  Fails trying to write either focal or bionic 64 bit uefi releases.   and I'm trying to figure out why.  Maybe it's because I'm using an rc of focal in the first place.  dunno.

Here's the relevant part of how it goes on a *verified* good stick on /dev/sdb1

Code: [Select]

15267 MB: Size of USB device
46 MB: Size needed for basic install
15221 MB: Size remaining on USB after install

Creating and formatting /dev/sdb1 UEFI partition...

mkfs.vfat 4.1 (2017-01-24)
mkfs.vfat: unable to open /dev/sdb1: No such file or directory

Creating and formatting the remaining space as /dev/sdb2 with ext2...

mke2fs 1.45.5 (07-Jan-2020)
The file /dev/sdb2 does not exist and no size was specified.
tune2fs 1.45.5 (07-Jan-2020)
tune2fs: no such file or directory while trying to topen /dev/sdb2/
Couldn't find valid filesystem superblock.
mount: /tmp/usbinstall: special device /dev/sdb1 does not exist.
Installing for X86_64-efi platform.
grub-install: error: failed to get canonical path of `rootfs' .
Installing for i386-efi platform.
grub-install: error: failed to get canonical path of `rootfs'.

Weird as I can mount the sdb1 partition manually if I want.  Probably something wrong on my end so I'll dig around.  I don't mind ext3/4 - sticks are much more robust these days, especially those that are large and have cells and even controllers to spare when you get 32gb or beyond.

[PDP-8]

Oops - looks like I jumped the gun when you replied!

Gotcha - no sweat.  Totally dig it - a kid could burn using a 3rd party burner just to get online to grab the real dcore-usbinstaller and burn again with something a little less hack-ish than what I normally do.

Pleasure - fun to play and always learning something new.

[Jason W]

There was an issue with a startup script involving fdisk that prevented dCore-usbinstall to work.  It is fixed now, and I uploaded repacked dCorePlus-focal64 related images.  Using dd to write dCorePlus-focal.iso to usb, booting it, and installing and using dCore-usbinstall on the same usb drive works now. 

[PDP-8]

YEAH!  You got it!

I tested like a typical inquisitive new user using Etcher on Windows with the new dCorePlus Focal iso.  Then I used that to burn a more capable usb stick of itself online.

You should be proud!

The only minor thing I would suggest is maybe to put a tiny README in the local directory with perhaps commonly used sce commands.

Example:  wiki's moving, stale info on other forums, or in the case of me right here getting this totally wrong a few messages back:

What I got wrong and should have written:

Code: [Select]

sce-import dCore-usbinstall
not, "usbinstaller".

A readme written by someone who actually knows what they are doing (not me!) might be helpful if they are grasping at straws with google and wikis, and simply wrong info from guys like me.

GREAT job Jason.

[PDP-8]

Occasionally losing Xterm in Fluxbox menu:  (minor thing)

I don't know what sequence of events I'm doing to trigger this, but every once in a blue-moon, when I bring up the Fluxbox applications menu, xterm disappears, leaving only Aterm and UxTerm as my terminal choices.

Not a big deal.  Logging out and dropping to the command prompt, exiting out, and logging back in as tc brings Xterm back into the menu.

It doesn't happen often, and sometimes, it will come back without me having to log out to the commandline.

Otherwise, I'm totally stoked with the RC even though I don't push it as hard as some might.

The only thing I *really* need is to sce-import the graphics-<kernel> sce.  Of course this boots me to native resolution, and the system looks great with the ttf fonts.  I also need it to make my hdmi monitor actually go into powersave, rather than just blank the screen.

Got my Xterm tweaked to my liking in .Xdefaults, but even so, if I want to change out of the native resolution, I just use Xrandr in a shell script.  Of course I then need to change my xterm font setup in .Xdefaults, but this is where the ctrl-right-click menu comes in real handy.  Or fire up Aterm. whatever.

For me, this is production ready, and not an rc!  Then again, I'm not pushing it like a real power-use might.

Nice job man.  If this were 1987, I'd pay you about $20,000 for this kick-ass workstation!

[PDP-8]

More missing Xterm notes:

Bordering on anecdotal crazy, it happened again, but perhaps some data points since I didn't write down every step:

1) Burned a brand new bootable Focal iso.  Used "as is", so I didn't use it to make another Focal stick.  Used tce-setdrive to set my data persistence on a different stick.

2) Everything is working, so I went ahead and loaded graphics-<kernel> package on boot.  Put into my sceboot.lst file.  No problem it all works.

3) But now I noticed later that only Aterm and UxTerm is in the applications menu.

4) So lets fire up xterm anyway from within Aterm with the usual commandline quickie

xterm -fa Mono -fs 14 &

Nope - complaints about not finding the font files.

5) Fiddled around and merely *looked* at .Xdefaults with vi without making any changes.

6) Now Xterm is back in the menu system.  AND now that it is in the fluxbox menus, the simple commandline

xterm -fa Mono -fs 14 &

brings up xterm with ttf fonts and looks great.

Argh - could be the southwest heat baking my brain.  I'll start over and keep better notes..  so weird for xterm to go missing upon first burn and then show up later.

I'm on the hunt now, so I'll do it all over again and keep better notes..

[PDP-8]

Xterm fluxbox menu goes awol notes:

Seems random.  Cut out all the other variables and started with nothing but the read-only bootable iso.  MD5sums doublechecked.

Upon boot, sometimes xterm in the menus is there, sometimes it is not.  When xterm is missing, simply exiting to prompt, exiting out of prompt, and logging back in as user tc brings xterm back into the menu.

OR, if it is missing, and you have designated a persistent data drive, the reboot can bring it back.

BUT, I burned freshly onto new sticks anyway, and the same random behavior of losing xterm is back.

Not a showstopper.  Almost funny now since the fix is simple.  Obviously UXterm, which never goes away is immediately available, as with Aterm.

Note: for us cli-guys I figured out you gotta' watch your options "-fa" when used with Xterm, and "-fn" with Aterm.  Easy to fat-finger and get them crossed.

[PDP-8]

SOLVED! - maybe..

Ok, so when xterm goes missing, you can also simple do

Fluxbox > Restart

Ok that works, but I can't let go of it..

I think I found that if you specify the full-pathname of /usr/bin/xterm in

/usr/local/tce.fluxbox

Seems like merely changing it from {xterm} to {/usr/bin/xterm} does the trick.

Wow, so annoying because it was so random on my box.  I'll keep an eye on it and see if it returns..

[PDP-8]

Update - Once I modified that file manually, it seems the xterm menu option is stable.

Of course, this file gets overwritten by the system - say like when you sce-load htop for example.  Now Htop is in the applications menu along with xterm.  But when you look at the file, the executable for xterm no longer has the full path, just the {xterm} directive again.

Even so, xterm is functioning and stable and in the menus.

I can only think that on this particular piece of hardware, something in the timing doesn't allow a path to be established to xterm on a regular basis.  Maybe if link it to "Bterm" it might catch it fast enough.

Anyway, it's a small thing easily worked around, so I'll just deal with it for now on this single device.

[PDP-8]

Interesting - after doing and sce-import of gparted, and subsequently loading it, it seems like a process is started that won't let you start gparted even as root from the terminal.

Code: [Select]

$ sudo gparted
The process gpartedbin is already running.
Only one gpartedbin process is permitted.
The best I can tell, this process is started right after sce-load'ing it.

And yes, these days I expect to start gparted as root, and thus I don't expect it to show up in the fluxbox application menu, but initiate it from the terminal.  So Fluxbox seems to act appropriately.

Simply put, root can't even start it because I think sce-load is firing up the process first, locking out root.

Just an observation - not a complaint!

[Jason W]

Hi PDP-8.  gparted works fine on my large desktop install of dCore-focal64, but on a clean boot of dCorePlus-focal64 and an import and load of gparted, I see what you see.  Though a pgrep of the processes of gparted and gpartedbin returns nothing, does not seem to be running.   Probably a dependency issue, I will look into it tomorrow.  Thanks for testing. 

[PDP-8]

Right on Jason - I thought I was going absolutely insane since I couldn't find any gparted process running!

no rush...

[Jason W]

Hi PDP-8, I think I found what the issue was.  I looked at the /usr/sbin/gparted shell script and near the top of it was a test if the gpartedbin process was running.  A snippet of it is below:

Code: [Select]

#  Only permit one instance of GParted to execute at a time           
#                                                                     
if test "z`ps -e | grep gpartedbin`" != "z"; then                     
        echo "The process gpartedbin is already running."             
        echo "Only one gpartedbin process is permitted."               
        exit 1                                                         
fi                                                                     
                                                                       
# 

So I did a check of which ps was being used after importing and loading gparted on a minimal dCore system, and it was /bb/ps.  Debian/Ubuntu of course doesn't expect a Busybox version of any utility to be used.  Busybox utilities, as valuable as they are, may not have the same functionality of the full versions found elsewhere, which some packages need.  So I added the procps package to the dependencies of gparted and gparted now runs in a minimal graphic envronment. 

Please re-import and test, and thanks for reporting.

[PDP-8]

OUTSTANDING!  You nailed it - gparted now works perfectly!

No reply necessary - I love BB too, but just maybe, having me cherry-pick the entire Ubuntu repository for you to tweak out the bb'isms isn't something I'd want to look forward to.

So thanks for coaxing gparted to play nice....

[Jason W]

You have a point in testing whether Busybox utilities are an issue.  Perhaps I can create a meta package of all that replaces all the Busybox commands with their full versions if nothing else but for testing purposes.  Would make it easy to determine if Busybox is an issue in any package.  Perhaps could be called "linux-utils" or something.