From Newsgroup: alt.os.linux.slackware
with <
slrnvvhplu.rkm.apple.universe@freight.zombinet> Eric Pozharski
wrote:
with <vs8j3k$14jrn$1@dont-email.me> 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
<mbr.efi>. 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 </usr/share/Liveslak>
there are two scripts <setup.liveslak> and <setup.slackware>. In
theory if environment and files in </var/log/setup/tmp> are setup
properly then it's possible to use what backend of 'setup2hd' has to
offer. I went with what works.
* <usbboot.img>, 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: <fstab>, <initrd.img>, and boot
sector. <fstab> is trivial.
* <initrd.img>
This is less than non-trivial.
For </bin/init> of <initrd.img> to reach its counterpart </bin/init>
of zeppelin two things must plug in: <usb-storage.ko> 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 <ehci-hcd.ko> absolutely must be
preloaded. Turns out, it's known issue; however, instead of
<[^e]hci-hcd.ko> depend on <ehci-hcd.ko> (by kernel) it's done with
something associated with "softdep" (by udev) (see for yourself
</lib/modprobe.d/usb-controller.conf>). '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 </dev/sda>), 'modprobe' doesn't block, then <init>
(of <initrd.img>) blasts ahead and immediately fails because 'ROOTDEV'
is nowhere to be found. There are two solutions.
Trivial scripting would help. And, surprise, there's
</load_kernel_modules> (of <initrd.img>) that is promptly called by
<init>. Unfortunately, there's no way to install anything that
'mkinitrd' provides. Except forking whole <initrd-tree.tar.gz> (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.
<usb-storage.ko> is trivial. <ucs.ko> must be installed instead.
* And how lilo fits in all this mess?
As a glove. As much as dead 'lilo' can. For instance,..
Indeed, 'lilo' complains about zeppelin being non-first but proceeds
nevertheless even without forcing. What is kind of sad: it's 2025,
what is "first disk" anyway. Good thing, 'lilo' is dead and can't get
any worse (except, one day, it won't build; I prefer not to think
about it).
Then, storing boot sector in MBR works and is effective. *Aiming*
'lilo' at MBR of zeppelin has its issues. What is needed is *stable*
pointer to usb-bob. And udev is of no help. <sd[a-z]> isn't even
joke; <disk/by-path/> is <sd[a-z]> level unstable; <disk/by-label/>
and <disk/by-partuuid/> are about partitions (neither even features
links to whole disk); <disk/by-diskseq> is another joke, I guess, and
is missing from Slackware proper. <disk/by-id> _pretends_ to be solid
candidate, but there is a catch -- I see naming conventions are
version (of udev) dependent; otoh, udev absolutely insists on
exposing manufacturer and that's unstable -- usb-bob will die any
moment and I don't feel like hunting for another, so it's going to be
microSD. And then udev will expose manufacturer of cardreader. I'm
certain udev people have reasons to be this difficult.
For now I've set "boot=" of <lilo.conf> to "/dev/sdz" and this is
reasonably safe for now. Then each time I need to update boot sector
I tell 'lilo' what to look for. And rest assured, it's "rm -rf *"
scary. This will be fixed someday.
* Short comment on "this usb-stick boots"
Each and every box (six so far) I've tried has its The Secure Boot
present and disabled (I've access to some boxes that have The Secure
Boot enabled, haven't even tried). My understanding is, that bios is,
in fact, a wrapper about underlying efi and then lilo uses that bios
but it's efi that enables booting. It remains mystery if zeppelin
would boot without lurking in shadows efi (and such box must be
x86_64).
And that would be everything for report 0x0. Should have taken notes on
the way, my bad.
--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom
--- Synchronet 3.21a-Linux NewsLink 1.2