Tiny Core Linux
dCore Import Debian Packages to Mountable SCE extensions => dCore x86_64 => Release Candidates => Topic started by: Jason W on December 29, 2019, 09:02:11 PM
-
Work on dCore-focal has begun. It is using Ubuntu Focal Fossa. Ubuntu Focal Fossa is to be released in April 2020, but it is never too soon for me to start the work to make this Ubuntu release into a dCore.
-
Hi Jason, I hope you are doing fine! I have some Corona-induced spare time to work on my computers. I wanted to add an entry about printing to the wiki but that seems to be down since a couple of days. Looking around in the forum, it seems eerily quiet, too. I sincerely do hope that development has not halted in the meantime! Do you still plan on releasing dCore-focal anytime soon?
Sincerely, Stefan
-
Hi sm8ps. I have been sidetracked recently as my 64 bit PC died on me, my new one has arrived and hopefully I will be back at it soon. I also notice the quiet in this part of the forum, but I am hoping that means things are just working as they should. Either way, dCore is useful I think and the final release of Ubuntu Focal is the 23rd of this month so it is not too early for a dCore-focal.
-
Great news! I support your point of view about dCore working just the way it should. And it is much more than simply useful, it is miraculous! It makes things possible like running a 2018 OS on Centrino hardware from 2005 better than on the crappy 2018 laptop with a traditional installation. Many thanks for all your efforts, Jason!
-
I'm waiting too :) :)
Great work Jason
-
Hi
I'm not using dCore anymore.
I'm using standard distro.
best regards
-
Goodbye and arrivederci, JLS! I am sure you will be back sometime.
-
I'm still here, and hope for long time, dCore wihout problems in my Pc's
-
dCore-focal64 is now uploaded to release candidates.
http://tinycorelinux.net/dCore/x86_64/release_candidates/dCore-focal64/
-
Awesome, thank you so much, JasonW! Looking forward to testing as soon as possible. Will take some time though.
-
dCorePlus-focal64.iso and dCore-focal64.iso are now bootable with both BIOS and UEFI systems. My current machine has an option to boot with either BIOS or UEFI, so I was able to test the ISOs. I was able to boot dCore-focal64.iso and dCorePlust-focal64.iso with both BIOS and UEFI, and both with being burned to a CDROM, and also to usb using the dd command. Please test them, and if they are good, I plan to make all the 64 bit dCore ISOs this way. 32 bit PCs are old, and I don't think there is a point to having UEFI with the 32 bit dCores.
-
FOCAL ROCKS on UEFI-ONLY!
Just wow. On my modern uefi-only machines, it was EASY to get the 64 bit dCorePlus up and running on a stick:
1) dd from unix. No problems.
2) Windows: Etcher no problem. Rufus with gpt and dd options. No problem.
3) Chromebook: renaming the dCore iso to a .bin suffix, and using the Chromebook's own restore utility, it burned dCore just fine and booted on my pc of course. Not used for chromebook.
4) Macintosh - I'm sure dd would work. Other common burners would probably work, but since I don't have one, I can't test.
FLUXBOX! I didn't expect that! As much as I like TC, this was a refreshing change, even though all my old familiar utils were there.
Nice work Jason!
This kind of guarantees the future of dCore, where even youngsters with shaky experience of partitioning, formatting, and installing bootloaders, can get up and running fast - and then turning into gray-beards like us on their own time. :)
Just awesome.
-
Addendum: Love the flexibility of this new iso format.
3rd party burners:
Etcher - one handy thing about it is that after a burn, it verifies it, unlike most other utils that merely write. This can catch flaky / counterfeit drives at times. So even if you don't plan to use it regularly, it can be a diagnostic tool.
Rufus - (always use the latest) - has the option of putting a persistence partition on the same stick. Works fine with dCore. But to do so, make sure you use gpt and not mbr. And of course the dd method when prompted. The partition is even labeled "persistence" and shows up nicely when you hover with the mount tool. Oh, calculates md5's or sha's too on your iso file. Handy.
I suppose more advanced users could always shrink the existing dCore partition with say gparted, and create another one for persistence of their own choosing later if they want if they don't want to use Rufus' persistence partitioner. Whatever, do your own thing.
I'm old-school, and use dCore / TC on it's own physical device, and my tce directory on another physically different filesystem, but thought I'd bring that Rufus thing up.
I moved my boot and data sticks from machine to machine (Intel NUC's, inexpensive hockey-puck mini-pc's, my Acer laptop, and dCore never had a problem finding the data device holding tce. Well, it did once, but all I had to do was use the standard dCore util, like tce-setdrive, or bang it out manually with UUID's, or simply just specifying the LABEL of my drive. Usual stuff - not a problem.
So I'm pretty stoked at the flexibility that focal iso brings to the table.
-
Focal (cli only) - what a blast.
dd'ed the simple dCore focal, and like Plus, I had a blast and no problem booting in on any eufi-only box.
Within minutes I was doing my usual schtick - downloading the latest busybox from project site, stealing terminus console fonts from other distros, (using busybox's setfont to bring them up) links, joe, sc, all the usual suspects.
Other than custom creating my own stick with a writable filesystem to make grub.cfg editable, any change of making "multivt" a standard, rather than the exception? No biggie.
Fun - love this stuff! Again, nice job.
-
Hi PDP-8. Thanks for testing across the methods you did, I only can test presently with dd and burning to cdrom. dCore-usbinstall does install a UEFI bootable USB when the UEFI option is chosen, but if you are booting with a dCore-focal UEFI USB key that was created with the dd command, right now dCore-usbinstall will not be able to use that same USB key to install to. I will see what I can do about that.
As for the multivt option being standard, I aim to keep things the same as regular Core when I can. That fluxbox is being used for dCorePlus is because there was an issue with FLWM, and I have not found what it is yet.
Thanks again for testing.
-
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
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.
-
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.
-
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.
-
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:
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.
-
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! :)
-
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..
-
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. :)
-
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..
-
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.
-
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.
$ 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!
-
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.
-
Right on Jason - I thought I was going absolutely insane since I couldn't find any gparted process running!
no rush...
-
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:
# 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.
-
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....
-
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.
-
Heh, whatever you deem best.
As an example:
"Jason, I can't get the luakit-browser to work. I can sce-import and load it, but it's just dead."
Which is true, but I didn't want to mention it. See where this is headed? :)
I just worry you might go off the deep end and collect stamps. (apologies to stamp-collectors) :)
-
Getting waay OT, so I apologize but this being RC territory ..
I love TC. I also really dig dCore obviously. Not looking to change things.
However, as TC relies upon BB with the option of adding classic gnu file/text/shells, maybe dCore would be easier dev wise to rely primarily on classic gnu file/text/shells, and add BB funtionality as the user sees fit?
<thunderclap>
Hmm.. what about making TinyCore itself an SCE ?!?!
That way a user can drop into the TC environment, do dev work and so forth, yet the underlying dCore could be classic gnu environment to reduce the pita some 'isms may present?
Please feel free to disregard and no comment necessary. Not being a developer myself, maybe this suggestion should go straight to /dev/null and not pass /go
-
dCore is built on Busybox, with the option of importing GNU and other stuff, just like Core. It is not based on GNU utilities, nor depends on them. Though some added extensions may need them. The gparted issue we just saw, was the same issue seen in Core earlier, the /usr/sbin/gparted script. It is a gparted thing, not a dCore thing. Link is below.
http://forum.tinycorelinux.net/index.php/topic,20277.msg126196.html#msg126196
One can either adjust the /usr/sbin/gparted script, or add the procps package. And gparted and it's deps are pretty large itself. For now at least, I added the procps package. The gparted script has it's last copyright in 2015, so it probably does not change much and would work across all versions of gparted. In that case, I could add an adjusted gparted script in a gparted-data.tar.gz extra files package instead of the procps dependency. The deb2sce startup scripts and the -data.tar.gz extra files are used across all versions of dCore, all architectures, so I only replace files in a package when it makes sense and will work across all versions of a package.
Don't worry about me. :-) If you look at past issues in imported packages or base dCore and my solutions for them, you will see I aim to solve the problem while doing only what I have to in terms of adding size or dependencies. I don't 'throw in the kitchen sink' to solve something. Except for dCorePlus images, which has every possible firmware, everything one needs to get an internet connection to get online and then start setting up a TCE directory. Hundreds of megabytes in size, yes, it is the kitchen sink and for a reason. Give one all they might need to get up and going, then they can download the ~20 MB dCore*gz file in its place to use from then on once the TCE directory is set up.