From: apple.universe@posteo.net
with Eric Pozharski
wrote:
> with Henrik Carlqvist wrote:
>> On Fri, 28 Mar 2025 18:29:04 +0000, Eric Pozharski wrote:
*SKIP* [ 9 lines 3 levels deep]
> That being said, I'm about to FAFO anyway and in short time (by my
> scale) I'll build syslinux6. I leave _this_ message as a bookmark and
> will report here.
Not even close yet. Anyway...
What is achieved so far: Slackware (15, unsupported, x86_64) is
installed on the usb-stick (256GB); this stick bios-boots. However,
that tiny leap went through quite dangerous terrain. Here goes...
* Little bit of terminology hassle.
The usb-stick isn't exactly stick. It's more like usb-bob. Anyway,
it's hostname is 'zeppelin'. Because reasons (yes, hostnames are
weird). For clarity, I call this thing "usb-bob" when referring
hardware itself _before_ install (packages and boot sector) or when
content is irrelevant; and "zeppelin" when install is complete (even
if unrolled out Slackware is mostly dysfunctional). For no reasons
whatsoever.
* _Two_ competing distinctions.
Through out this tldr I will consider bios-boot vs efi-boot and MBR vs
GPT. Thing is, it's routine to associate MBR disklabel with not
secure boot and GPT disklabel with The Secure Boot (even if in DGAF
mode). Otoh, either partition table is just registry of how whole
block special is split (granted: GPT is required by efi-boot).
For brief moment of time (16h), I'd mused about availability of
. Now I understand it's not possible.
* What bootloader for the bios-boot?
Now, first strategic (iow: blind) decision -- two distinct bootloaders
or two distinct configurations of universal bootloader. Decision has
been made: lilo for bios-boot and extlinux for efi-boot. Idea is
that lilo knows nothing about efi-boot and, hopefully, extlinux will
ignore bios-boot.
* MBR or GPT?
There's no choice here. The efi-boot requires GPT. And lilo doesn't
care.
* Well, how to proceed?
Basically, that was first dead end.
So, I've got two distinct goals: observing efi-boot in action and
having something off Slackware Proper to install from. Obvious single
solution is something live (my understanding is every live in
existence now is hybrid iso).
Further research selected two potential candidates: Porteus and
LiveSlak (everything else is dead or current). Actually, there is yet
another installer but it failed me anyway; will talk about it later.
* Porteus, what's the deal?
Shortly: a disaster. Porteus provides some kind of utility ("some
kind" means, aiui, this utility is two component shell script, second
stage is compressed; definitely there are reasons for this). That
utility installs somewhere. I'd failed to target it at the usb-bob;
then I've realised that I need to find a way make it behave and *then*
somehow push it onto iso-hybrid. Kind of show stopper.
Much much later I've realized -- I'd failed to do research properly.
Turns out Porteus installs Porteus. Good thing I've aborted early and
thus avoided certain amount of screaming.
One more thing though. This wasn't meant to be mean about Porteus.
However, for the purpose of building zeppelin it's useless.
* LiveSlak, what's the deal?
Again, LiveSlak comes with installation script. And it is unfit for
purpose.
Can't say anything about how 'setup2hd' does partitions because
usb-bob had been setup during wrestling with Porteus (in fact,
'setup2hd' delegates setting up disklabel to 'fdisk' (for MBR) and
'cfdisk' (for GPT); while 'fdisk' is totally capable to setup GPT).
This seems cosmetic. But who knows, it might be not.
Because appropriating partitions seems to be extremely deficient --
'setup2hd' lets to pick one partition for '/' and that's all (granted,
one partition of hard disk is present too). All my careful selection
of UUIDs and labels had been ignored. I feel useless and unfulfilled.
Because 'setup2hd' didn't let me through without picking single
partition for root I just gave up. Deep inside
there are two scripts and . In
theory if environment and files in are setup
properly then it's possible to use what backend of 'setup2hd' has to
offer. I went with what works.
* , what's the deal?
Honestly, that's what I had ended up with anyway -- prepare list of
packages to download, download one, 'pkginstall' it, remove just
downloaded, repeat. Except LiveSlak is more comfortable.
* Here comes juicy part
Now three things are left to make: , , and boot
sector. is trivial.
*
This is less than non-trivial.
For of to reach its counterpart
of zeppelin two things must plug in: and whatever
<[eoux]hci-hcd.ko>.
It's not that simple; loading them preemtively doesn't work at all.
What are needed instead are <[eox]hci-pci.ko>.
It's not that simple; now <[^e]hci-hcd.ko> (watch how it's not
<*-pci.ko> anymore) complain that absolutely must be
preloaded. Turns out, it's known issue; however, instead of
<[^e]hci-hcd.ko> depend on (by kernel) it's done with
something associated with "softdep" (by udev) (see for yourself
). 'makeinitrd' needs to be told
that 'MODCONF" is set (yes, load of modprobe staff will be installed;
that's how 'mkinitrd' rolls).
It's not that simple; turns out, USB is dead slow (that's why host's
disk will always be ), 'modprobe' doesn't block, then
(of ) blasts ahead and immediately fails because 'ROOTDEV'
is nowhere to be found. There are two solutions.
Trivial scripting would help. And, surprise, there's
(of ) that is promptly called by
. Unfortunately, there's no way to install anything that
'mkinitrd' provides. Except forking whole (I'm
not that desperate yet).
The only other option is 'WAIT'. 5sec isn't enough. 10sec, while
being miserably sub-optimal, is mostly enough. Except that one case
where it fails ~25% runs.
It is my understanding that forking 'mkinitrd' is inevitable.
However, I will explore what other options I have. And promptly
report it, like, right here.
is trivial. must be installed instead.
* And how lilo fits in all this mess?
As a glove. As much as dead 'lilo' can. For instance,..
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
