Tiny Core Linux
dCore Import Debian Packages to Mountable SCE extensions => General dCore Talk => Topic started by: Jason W on July 12, 2019, 02:02:23 PM
-
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
-
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.
-
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.
-
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.
-
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:
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
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. :)
-
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....
-
Another non-boot issue, but maybe pick off this low hanging fruit ...
Trying to activate uxterm from the menu is unsuccessful because ..
uxterm tried unsuccessfully to use locale en_US.UTF-8 by setting $LANG to "en_US.UTF-8"
Ok, back to just boot issues ...
-
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:
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.
-
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
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. :) :)
-
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:
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:
#!/bin/sh
xrdb -merge ~/.Xresources
And also a file ~/.Xresources:
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.
-
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...
-
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...
.
.
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. :)
-
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
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...
-
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!
-
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.
-
First, dude you did an *awesome* job. I'm like a kid in a candy store seeing dCore booting on my uefi-only boxes.
TinyCore members look away:
I used Rufus - emulating how a new user who only has a windows box would want to explore dCore. I'll try dd'ing it from another unix box later.
BUT, the only two options I used was the GPT format (because I have to on my uefi only boxes), but when prompted I only used the first option of ISO.
I'll try again, with GPT and then opt for DD mode and see how that goes!
Thanks for putting up with my self-created problems....
-
DD mode + GPT results in no detection by the bios at all.
I tried both ways, first with Rufus GPT + DD mode. Nada.
I headed over to my Devuan box, and dd'ed manually. Something from memory like this:
dd < dCoreBionic-uefi-xx.iso > /dev/sdb bs=4M conv=sync,noerror
and it finished with no problems. I used the new uefi iso you provided.
Same result - none of my uefi-only machines recognize it at all as a valid boot device.
I even perused the Rufus FAQ, where sneaky issues with isohybrids / grub / fat32 support, a notice about Manjaro, UEFI and the whole scene:
https://github.com/pbatard/rufus/wiki/FAQ
I couldn't see anything wrong, but that is a bit above me really.
P.S. crossed fingers and tried MBR with either ISO or DD mode, and no detection there either.
So for some reason, only GPT and ISO mode with Rufus, even if not perfect, is the only combo that boots dCore on actual hardware.
-
dCore-usbinstall works fine!
Finally got around to it Jason - nice scripting!
I chose a Bionic UEFI release candidate, and everything works as it should! Partitions of course are now just fine.
Only suggestion would be to put that grub delay countdown in the usbinstall-burned versions too, otherwise a user might freak at the black screen.
And maybe think about changing the wallpaper in the downloaded iso so that the new user knows that this is just an installer, and should run dCore-usbinstall? Or maybe dump a readme file on the background because you KNOW they will try to use the initial burn as a functioning system, and not as an interactive installer.
Nice work bro, I'm pumped!
-
Making a backup / duplicate ..
Now that your awesome scripting has created a nice bootable stick done the way you like it, I decided to back it up as an image so I can create another quickly with dd
dd < /dev/sda > Jasons_Bionic_uefi.img
Now to duplicate I'll turn it around to a new stick (simply because I don't like dd'ing stick to stick and I also have an img file for backup I can send to someone else in the office I use dCore to work with etc etc... dd options excluded from example..
dd < ./Jasons_Bionic_uefi.img > /dev/sdb
And yeah, that stick has to be the same size or larger. And maybe expand the filesystem if I do use a larger stick later ...
Which makes me wonder if the distribution iso could simply already be in this format, rather than go through the dCore-usbinstall routine. As cool as that is.
Just wondering - not complaining.
-
Glad dCore-usbinstall is working as expected on your machines. I will add the grub progress thing into the resulting usb boot as is with the iso. I see that Computesticks are not that expensive at all, getting one would allow me to test uefi on real hardware, at least that one make and model.
-
Ok cool. Just some notes, I'm using real Intel computesticks - there are quite a few off-brand lookalikes.
I don't spend much time trying to get hdmi audio, nor wifi to work natively if they give me problems with alternate operating systems. If they don't work, I just use a working wi-fi dongle, and a usb<>audio dongle if I need sound from headphones. Basically mostly used as classic workstations, not multimedia boxes. :)
A few tips on 3 different versions
- I have NOT tried using *core on the 1st generation stick that came with Ubuntu 14.04 by default. Model STCK1A8LFC. If tempted, do NOT try to update it - not enough room on emmc as many consumers found out! I didn't play with ubuntu on it that much, but some suggest that updating that means you MUST put in the optional micro-sd card to do so. Or spend days in synaptic removing a lot of software first.
Windows 8.1 version STCK1A32WFC
Plenty of room, but I don't mess with the windows install. I don't even try to install *core on the emmc. I only use external sd cards for boot and operation. I can boot Porteus from the micro-sd card should I choose.
Default o/s: Windows 8.1 32-bit
Optional o/s: Ubuntu 14.04 LTS 64 bit. Not on board. Works for using any other 64-bit distro!
Windows 10.1 model CS125 STK1AW32SC
Again, plenty of room, but I leave the os on the emmc alone. Intel wifi works automatically with dCore. Can NOT boot from micro-sd card - this was possibly a security precaution for digital signage - a usb key could easily be seen by employees, but a sneaky micro-sd card, not so easy. Don't waste time trying to boot from the micro-sd. At least I didn't.
Default OS: Windows 10.1 32-bit.
Optional o/s: Windows 64 bit & Android. Neither on board. I use this setting for running 64-bit dCore!
BIOS updates - great support from that from Intel. I normally just use the bin file on a dedicated sda device, reboot and update that way. Operational and security (such as it is) fixes.
Example: the old windows 8.1 stick bios update as of 6/20/2019 can be found here:
https://downloadcenter.intel.com/product/86612/Intel-Compute-Stick-STCK1A32WFC
I don't mess with windows and program updates really, but hey - it will run Rufus offline just fine. :)
Even if set for Windows boot in the bios, one can *try* that with say a 64 bit dCore if the other choices like linux / android / ubuntu etc don't work. But they do seem to be specific to 32 or 64 bit. Try it anyway.
A 4-port passive hub seems to suffice for running dCore with keyboard / mouse / usb boot stick / wifi if needed and or an ethernet <> usb dongle too with the supplied power supplies. But don't push it like a lot of raspberry pi folk do. :)
-
OT: computestick still not recognizing your dCore usb?
Q: I've gone in and changed the bios to recognize some form of 64 bit operating system, be it Windows64, Ubuntu LTS 64, Linux 64 bit, etc etc, rebooted.
Yet my dCore drive does not seem to be in the boot order listing, or not available as a boot option with F10.
A: With power on, remove and reinsert your dCore drive, and restart and get into the bios again. At your option, place the dCore usb first in the list, but that's not mandatory.
It seems that when you change your operating system in the bios, it takes a hot removal and reinsertion for the new os on the usb stick to be recognized. It will stay recognized unless you change your os back to windows, and you change it back to an alternate 64 bit os yet again. Just remove and reinsert the dCore drive.
Unless one is in the habit of switching back and forth between windows and an alternate os in the bios, once set it is not a problem. I suppose one could dual-boot from the windows emmc device, but I'm not touching that and keeping things simple.
Just something to save some headaches. :)
-
PDP-8, I tried the cloning of the usb install, and it seems to work ok. Below is what I did. I used a script to make a 360MB GPT partition and install grub and the dCorePlus-bionic files, script was basically taken from dCore-usbinstall. I did the below command to make a backup that is a little larger than the partition, this creates a 361MB image of the partition. /dev/sdb is my usb device, of course anyone should always be very very sure of your device name whenever using dd:
dd if=/dev/sdb of=dCorePlus-bionic-usbimage.img status=progress bs=1M count=361
Then I can dd it to another usb with the below command:
dd if=dCorePlus-bionic-usbimage.img of=/dev/sdb status=progress bs=1M count=361
This leaves the sdb usb with the rest of it being free space, and any usb drive that is larger than 361MB would work to boot with. Then I created a Linux partition with ext2 on the free space as sdb2. Can be done easily of course with cfdisk or fdisk, then then mke2fs. To use this ext2 partition for the TCE directory, I added a label to it and edited boot/grub/grub.cfg on the GPT partition. Kind of like
tune2fs -L bionic /dev/sdb2
And then change the following beginning of line in boot/grub/grub.cfg:
linux /EFI/dCore/vmlinuz-bionic quiet
to:
linux /EFI/dCore/vmlinuz-bionic quiet tce=LABEL=bionic
Or, just dd the image to usb, and boot and install and run dCore-usbinstall.
The GPT image I created with this is located at the below link. Test it as I am curious if you get the same results. This is a quick trick to get dCore installed to usb from a Linux distro rather than using Rufus, but does work at least here.
http://tinycorelinux.net/dCore/x86/release_candidates/dCore-bionic/testing/dCorePlus-bionic-usbimage.img
http://tinycorelinux.net/dCore/x86/release_candidates/dCore-bionic/testing/dCorePlus-bionic-usbimage.img.md5.txt
-
Jason - that ROCKS!
I had no problems whatsoever using dd on that image and having it boot. I used both your dd options, and my own preferences for that, and bang - no problems either way.
I think I'm starting to get it - one can download the exact image they want, dd it, and take care of their own preferences for onboard / outboard / existing filesytems for the tce directory proper.
OR, they can use it as an installer, and even if they download a version that is not to their taste, they can simply use dCoreusbinstall to set it up the way they like that way too.
NICE JOB!
P.S. I jumped the gun, and tried some 3rd party stuff, even though that isn't part of the plan. Just so lurkers don't get weirded out:
Balena Etcher - no longer complains, and readily accepts the image, burns, and verifies it. But leaves you at the normal grub prompt (not grub rescue)
Rufus - recognizes image, and greys out ALL options for the user (heh, less to go wrong) - all they can do is burn. Leaves you at the normal grub prompt.
Chromebook - renamed the img extension to .bin, and used the recovery utility to burn the dCore image as a "local image". It finished, but I forgot to write down what the result was - I think I messed it up, but at least it finished and didn't complain. Not expecting it to work - just some additional data...
Not expecting these to work - DD was just freaking awesome. But thought it interesting.
Much of the success in either iso or img format I think rests upon the more up to date versions of syslinux and/or grub that you included for uefi-only machines. So thanks again for doing that.
-
Info from Gparted:
Ok, so the dd of the testing image boots fine.
However, I noticed that on Porteus, which tries to automount attached devices it doesn't show up. But I proceeded with Gparted on my only /dev/sda device anyway since I want to use an ext2 filesystem for persistent storage on the rest of it.
From Gparted 1.0.0:
Invalid argument during seek for read on /dev/sda
Retry | Cancel | Ignore
So I chose to ignore it.
Ignore:
The backup GPT table is corrupt, but the primary appears ok, so that will be used.
Trying to make an ext2 filesystem anyway:
No partition table found on device /dev/sda
So that is where I stopped, as trying to create a partition table will wipe out all data on the /dev/sda device.
Strangely, this is a lot of fun and interesting...
-
Corruption? Nope.
Just to be sure, I downloaded the img file, and the md5 and compared. All ok there. But I tried again anyway with the same results of Gparted complaining about the backup GPT table.
Still VERY cool to dd and have it come up graphically like a cd.
It works with tce directories located on another filesystem, just seems that trying to put your own on the /dev/sda device itself is a little cranky - at least with gparted 1.0.0 throwing up warnings.
With all this dd'ing and formatting, I'm always reformatting with tools that totally reset - wipe the device of any lingering partition tables - that even though visually clean with normal tools, can sometimes be left in the *controller* of the devices.
We'll see. STill lovin' it so far...
-
Ah, maybe I'll play with gdisk or current parted...
Here we go - aha!
root@porteus:/home/guest# gdisk /dev/sda
GPT fdisk (gdisk) version 1.0.4
Warning! Disk size is smaller than the main header indicates! Loading
secondary header from the last sector of the disk! You should use 'v' to
verify disk integrity, and perhaps options on the experts' menu to repair
the disk.
Caution: invalid backup GPT header, but valid main header; regenerating
backup header from main header.
Warning! One or more CRCs don't match. You should repair the disk!
Main header: OK
Backup header: ERROR
Main partition table: OK
Backup partition table: ERROR
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: damaged
****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
****************************************************************************
We'll see..
Ok, merely loading my /dev/sda with gdisk and just letting it (w)rite the partition table out seems to have fixed some things...
Command (? for help): w
Caution! Secondary header was placed beyond the disk's limits! Moving the
header, but other problems may occur!
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!
Do you want to proceed? (Y/N): y
OK; writing new GUID partition table (GPT) to /dev/sda.
The operation has completed successfully.
root@porteus:/home/guest# gdisk /dev/sda
GPT fdisk (gdisk) version 1.0.4
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Let's see what happens after reboot .
-
TOTAL SUCCESS!
gdisk cleaned things up a bit to the point where I Gparted would no longer complain and I could create an ext2 filesystem on the remaining space.
Although I did kind of expect this at first from Gparted:
Libparted Warning
Not all of the space available to /dev/sda appears to be used, you can fix the GPT to use all of the space (an extra
2014 blocks) or continue with the current setting.
I allowed gparted to "fix" the gpt table to be able to use the rest of the drive. At first I wanted to ignore it, but Gparted /libparted complained so much that I caved in and let it fix it.
With ext2 created, and once I placed my tce directory there, dCore-Bionic-usb.img works like a champ.
I ran gdisk again on /dev/sda just to make sure with Gparted tickling the gpt, but gdisk came back with a report of good health.
THANKS JASON! Man, that was fun - really. Learned some new stuff too..
-
Resolution notes
Ah, desired to see if I can get my native res, 1920x1080x24 working.
Edited /mnt/sda1/boot/grub/grub.cfg and found that this works to do that
gfxpayload=keep
linux <rest.of.line.....>
initrd= <rest.of.line.....>
gfxpayload=1920x1080
BUT, the interesting thing is that it *doesn't* work if I specify my color-depth of x24. Just 1920x1080 works.
Interesting. I'll look into it.
-
Thanks for testing, I have uploaded a new image below:
http://tinycorelinux.net/dCore/x86/release_candidates/dCore-bionic/testing/dCorePlus-bionic-usbimage.img
http://tinycorelinux.net/dCore/x86/release_candidates/dCore-bionic/testing/dCorePlus-bionic-usbimage.img.md5.txt
The dd command I used create the image and then copy to usb are below. To create image:
dd if=/dev/sdb of=dCorePlus-bionic-usbimage.img status=progress bs=1M count=365
To copy to usb:
dd if=dCorePlus-bionic-usbimage.img of=/dev/sdb status=progress bs=1M count=365
Using the new dCorePlus-bionic-usbimage.img and the second command to copy to usb, I see no partition errors with fdisk or gdisk. I think the first image was not quite large enough for the partition, thus the partition errors in gdisk. But should be fixed now, seems to work here.
I will post the script used to create the dCorePlus-bionic-usbimage.img.
EDIT: Script posted below, see the first of the script to set variables such as the usb device, and distribution files. /dev/sdb is the default entry for the usb device, but a safety check is in there.
#!/bin/sh
USB="sdb" ## The device name of your USB device
GZ="dCorePlus-bionic.gz" ## Your chosen .gz initrd, needs to be in the current directory.
VMLINUZ="vmlinuz-bionic" ## Your chosen kernel file, needs to be in the current directory.
SIZE=360 ## Size in MB of the resulting image.
DCORENAME=`basename "$GZ" .gz`
if [ ! -f "$GZ" ]; then
echo " "
echo ""$GZ" not found, exiting.."
exit 1
fi
if [ ! -f "$VMLINUZ" ]; then
echo " "
echo ""$VMLINUZ" not found, exiting.."
exit 1
fi
if mount | grep "$USB" > /dev/null 2>&1; then
echo "/dev/"$USB" has mounted partitions, exiting.."
exit 1
fi
####### Below is a safety check to make sure your chosen device is a USB one. Delete this section
# that ends in at the next 7 #######'s if you are sure and don't want the check.
> /tmp/usbinstalldev
for I in `ls /dev/disk/by-id/ | grep usb`; do E=`readlink /dev/disk/by-id/"$I" \
| sed 's/[0-9]*//g' | sed "s/[./]//g"`; grep "^$E" /tmp/usbinstalldev > /dev/null 2>&1 \
|| echo ""$E"_"$I"" >> /tmp/usbinstalldev; done
if grep "^$USB" /tmp/usbinstalldev > /dev/null 2>&1; then
:
rm /tmp/usbinstalldev
else
echo " "
echo "Your chosen device /dev/$USB" may not be USB, exiting...
echo " "
rm /tmp/usbinstalldev
exit 0
fi
#######
[ -d /tmp/usbinstall ] || mkdir -p /tmp/usbinstall
partprobe > /dev/null 2>&1
umount /tmp/usbinstall > /dev/null 2>&1
umount /dev/"$USB"1 > /dev/null 2>&1
mount | grep "$USB"1 && echo /dev/"$USB"1 is still mounted, exiting.. && exit 1
dd if=/dev/zero of=/dev/"$USB" bs=512 count=10000 conv=notrunc > /dev/null 2>&1
wipefs -a /dev/"$USB" > /dev/null 2>&1
udevadm trigger
echo "Creating and formatting /dev/"$USB"1 UEFI compatible GPT partition.."
echo "#!/bin/busybox ash" > /tmp/.dCorefdiskusb
echo " " >> /tmp/.dCorefdiskusb
echo 'echo "g' >> /tmp/.dCorefdiskusb
echo "n" >> /tmp/.dCorefdiskusb
echo "1" >> /tmp/.dCorefdiskusb
echo " " >> /tmp/.dCorefdiskusb
echo "+"$SIZE"M" >> /tmp/.dCorefdiskusb
#echo "Yes" >> /tmp/.dCorefdiskusb
echo "t" >> /tmp/.dCorefdiskusb
echo "1" >> /tmp/.dCorefdiskusb
echo "w" >> /tmp/.dCorefdiskusb
echo "\"|fdisk /dev/"$USB" > /dev/null 2>&1" >> /tmp/.dCorefdiskusb
sh /tmp/.dCorefdiskusb
partprobe > /dev/null 2>&1
udevadm trigger
sleep 5
echo " "
echo "Creating fat32 filesystem on /dev/"$USB"1"..
mkfs.vfat /dev/"$USB"1
echo " "
mkdir /tmp/usbinstall > /dev/null 2>&1
mount /dev/"$USB"1 /tmp/usbinstall
echo "Installing GRUB on /dev/"$USB"1.. "
grub-install --target x86_64-efi --efi-directory /tmp/usbinstall/ --removable --boot-directory=/tmp/usbinstall/boot
grub-install --target i386-efi --efi-directory /tmp/usbinstall/ --removable --boot-directory=/tmp/usbinstall/boot
mkdir -p /tmp/usbinstall/EFI/dCore > /dev/null 2>&1
cp "$GZ" "$VMLINUZ" /tmp/usbinstall/EFI/dCore/
echo "set timeout=10" > /tmp/usbinstall/boot/grub/grub.cfg
echo "menuentry "$DCORENAME-UEFI" {" >> /tmp/usbinstall/boot/grub/grub.cfg
echo "insmod part_msdos" >> /tmp/usbinstall/boot/grub/grub.cfg
echo "insmod ext2" >> /tmp/usbinstall/boot/grub/grub.cfg
echo "insmod part_gpt" >> /tmp/usbinstall/boot/grub/grub.cfg
echo "insmod fat" >> /tmp/usbinstall/boot/grub/grub.cfg
echo "insmod gzio" >> /tmp/usbinstall/boot/grub/grub.cfg
echo "insmod efi_gop" >> /tmp/usbinstall/boot/grub/grub.cfg
echo "insmod progress" >> /tmp/usbinstall/boot/grub/grub.cfg
echo "insmod efi_uga" >> /tmp/usbinstall/boot/grub/grub.cfg
echo "linux /EFI/dCore/"$VMLINUZ" quiet waitusb=8 rd.udev.log-priority=0 net.ifnames=0" >> /tmp/usbinstall/boot/grub/grub.cfg
echo "initrd /EFI/dCore/"$GZ"" >> /tmp/usbinstall/boot/grub/grub.cfg
echo "}" >> /tmp/usbinstall/boot/grub/grub.cfg
echo " " >> /tmp/usbinstall/boot/grub/grub.cfg
umount /tmp/usbinstall > /dev/null 2>&1
rmdir /tmp/usbinstall > /dev/null 2>&1
-
That works GREAT!
No problems whatsoever. Gdisk shows a good bill of health, the stick is recognized in the other Linux system, and Gparted easily creates an ext2 filesystem and "fixes" the gpt to fit the size of the stick.
Rebooted and ran the tce-setdrive utility which had no problems showing the two partitions, sda1 and sda2. Naturally I chose sda2 which is the recently created ext2 filesystem.
Thank you Jason for making it just a bit easier for us slackers. :)
-
dCore Bionic test - now Chromebook and Rufus friendly!
Chromebook:
Guess what? With the latest fix, I can make a Google Chromebook burn the dcore image easily using their recovery utility. Merely by changing the file extension from (.img to .bin), and telling the tool not to go online, but use a "local image".
I used a late-model 64 bit Chromebook. HOWEVER, once dCore has been created, it is no longer visible in the chromebooks own file utility.
Basically that means I'm using a chromebook as a dcore usb burner. I'm not attempting to boot dcore on the chromebook - although I'm sure it can be done with developer mode, yadda yadda. I didn't go there.
And since the Chromebook has no built-in way to create filesystems, other than a total reformat, that means that another option, such as fdisk'ing another drive could be done to find a place to put your tce directory. Or have another stick formatted ext2 - etc etc. For sure, young minds won't be stymied!
RUFUS:
Even easier. Pick the dCore img. Burn. There are no other choices to be made since they are all greyed out and dd is in operation behind the gui curtain.
EXT2 notes:
When burned with our commandline dd, when you fire up Gparted to use the rest of the drive as an ext2 filesystem for tce, it notices and pops up the option to "fix" the gpt while laying down the fs. Let it do so.
BUT, when burned with Rufus, and later using Gparted to put down an ext2 filesystem on the stick, this option to "fix" the gpt is not shown. It just immediately lays down the fs.
Make of this what you will - but now with the ability to burn dCore manually for us gray-beards, with a Chromebook, or with Rufus, it opens up a window for a larger audience that may be interested in Linux, dCore in particular.
-
Ops note:
The only problem, if you want to call it that, is if a new user is moving too fast, and runs the tce-setdrive utility before making an ext2 filesystem on the rest of the drive, (or knowledgeable enough about making one elsewhere), is that they may be tempted to put it on the only available option - /dev/sda1
Maybe a first-run "popup" or some other fine notification could be given. :)
Minor. Linux, Windows, or Chromebook to burn now seems to be covering all the bases, even though I was happy to dd manually.