brian|lfs has quit [Remote host closed the connection]
Duck[m]12 has joined #crux
Duck[m]12 has left #crux [#crux]
ppetrov^ has joined #crux
_moth_ has joined #crux
mnkydeth has quit [Remote host closed the connection]
ppetrov^ has quit [Quit: Konversation terminated!]
ppetrov^ has joined #crux
SiFuh_ has joined #crux
SiFuh has quit [Ping timeout: 268 seconds]
ty3r0x_ has joined #crux
farkuhar has left #crux [#crux]
ardo has quit [Read error: Connection reset by peer]
ardo has joined #crux
ppetrov^ has quit [Quit: Leaving]
_moth_ has quit [Quit: _moth_]
SiFuh_ has quit [Remote host closed the connection]
SiFuh has joined #crux
SiFuh has quit [Remote host closed the connection]
SiFuh has joined #crux
SiFuh has quit [Remote host closed the connection]
SiFuh has joined #crux
SiFuh has quit [Remote host closed the connection]
SiFuh has joined #crux
farkuhar has joined #crux
_moth_ has joined #crux
_moth_ has quit [Client Quit]
<SiFuh>
jaeger: just out of curioisty, is there any reason why the ISO is not more generic? As in, does the ISO's operating system need to be exactly the same version as the ports? All it really has to do is boot, find hardware, set up a disk and then chroot over.
jue has joined #crux
reptargvf has joined #crux
reptargvf has left #crux [#crux]
<cruxbot>
[xorg.git/3.6]: mesa: update to 22.1.6
<cruxbot>
[opt.git/3.6]: geeqie: update to 2.0, new deps meson/ninja
<cruxbot>
[opt.git/3.6]: nfs-utils: update to 2.6.2
<cruxbot>
[opt.git/3.6]: gdk-pixbuf: update to 2.42.9
<cruxbot>
[xorg.git/3.6]: xorg-xorgproto: update to 2022.2
<jaeger>
not particularly, other than it's built with existing scaffolding from the CRUX ports system, etc... with that said I'm playing with using a more minimal busybox environment for it
<jaeger>
without any firmware, packages, etc. it's about 7MB in size... but not very functional in that state, obviously
<SiFuh>
Yeah, I am looking at similar. But what I am thinking is to make one away from an ISO
<SiFuh>
Something that could be easily made and put on a USB. I already have a fully functioning one mostly based on the ISO but it needs a bit of a clean.
<SiFuh>
But with the option that a user can mount it with rw and modify it easily for themselves.
<SiFuh>
Another option is maybe using overlayfs or even a persistant partition
<SiFuh>
One of the nicer things but you will use up a lot of space, is you can have a fully functioning kernel and modules
<SiFuh>
And use next to nothing RAM
<SiFuh>
I also had one booting 100% on syslinux/isolinux and no grub but when I did rm -f tmp/fake_root I lost it all
<SiFuh>
farkuhar: Your handbook mods* are getting super awesome
<SiFuh>
Kind of cool to be here today watching it in real time slowly change ;-)
braewoods has quit [Quit: WeeChat 3.5]
braewoods has joined #crux
<farkuhar>
SiFuh: thanks. Get ready for some more changes soon. I managed to shorten the appendix by 69 lines, at the expense of adding 117 lines to the main text.
<SiFuh>
All good, everyone trust you
<farkuhar>
not that line counts are particularly meaningful, since they break pmwiki formatting ... but I now have all four combinations {grub,syslinux}x{uefi,non-uefi} documented succinctly in the main text.
<SiFuh>
Don't worry, you will do it good
<SiFuh>
We all threw our ideas and opinions at you. You will make do and you will succeed
<SiFuh>
Betting it will be the best handbook ever
<stenur>
refind is also a good thing. it has a documentation that helped me once i needed it.
<SiFuh>
Isn't refind a bootloader that doesn't support legacy ?
<stenur>
it supports EFI very well
<jaeger>
It's designed specifically for EFI
<jaeger>
even spelled rEFInd, technically
<SiFuh>
stenur: did you avoid my question?
<stenur>
what did you mean with "legacy"?
<SiFuh>
Imagine calling your grandparents 'legacy' hahaha
<SiFuh>
stenur: legacy is legacy MBR
<SiFuh>
Non-UEFI systems
<stenur>
with syslinux i always had to search the web in order to find out which MBR i had to put where and how before doing extlinux -i or what it was
<stenur>
then not.
<SiFuh>
stenur: Could have asked me.
<stenur>
i think it can secure boot, which is missing here.
<stenur>
SiFuh: what are you talking about??
<SiFuh>
Syslinux can be done super easy with UEFI, without any modifications to boot or UEFI but mbr you need to write it.
<jaeger>
This is true for all bootloaders
<SiFuh>
Secure boot is a scam, but I do it on my laptop with OpenBSD
<jaeger>
Well, almost. There IS a modification for UEFI to the boot entries list, unless you always use the standard bootx64.efi name and path
<stenur>
note i have forgotten all about it. i now use EFI_STUB and efibootmgr, and have a static stage1 kernel on EFI, and busybox and cryptsetup, and then i use kexec to go stage2. that is all i know
<SiFuh>
jaeger: Yeah 100% agree. As I mentioned in the other channel. Can do an EFI_STUB and copy to bootx64.efi
<SiFuh>
jaeger: No
<SiFuh>
You don't need to modify anything if you know the default *.efi location for the UEFI
<jaeger>
I just mentioned that
<jaeger>
"unless you always use the standard bootx64.efi name and path
<jaeger>
"
<SiFuh>
And I mentioned "if you know the default *.efi location"
<SiFuh>
:-P
<jaeger>
Yes, but the "no" response to factual information could be confusing :P
<SiFuh>
stenur: how do you send the command line options?
<SiFuh>
I am teasing you jaeger
<jaeger>
efibootmgr, probably
<SiFuh>
On the Beelink I do it through efibootmgr writing the UEFI
<SiFuh>
On an older system which is not here I use to run it directly through the kernel using that CMD BOOLEAN line
<stenur>
some via efibootmgr, the rest sourced from shell script
<SiFuh>
stenur: I rephrase for you. If you want to load an initrd image you do it with efibootmgr or with kernel directly?
<SiFuh>
I am not good with English so I must apologize
<stenur>
i do not have an initrd image. o wait, yes i have one, i generate it on the fly for the second stage. i had posted these scripts in the past i think.
<SiFuh>
You generate the initrd on boot?
<SiFuh>
Because that makes no sense
<stenur>
i do, for the second stage.
<stenur>
of course it makes sense, it contains the password to unlock the encrypted partition for the second stage, for example.
<SiFuh>
So you are not generating an initrd
<SiFuh>
You are accessing?
<stenur>
no, i create it unless it is already there
<SiFuh>
My right eyebrow just raised so high it smashed the ceiling
<stenur>
it is really easy stuff, but it could surely be extended to also include modules and such.
<SiFuh>
Yeah I was looking at the previous links
jue has quit [Ping timeout: 252 seconds]
<stenur>
But i like it. Of course names of kernels and such have to follow a pattern and such, but it had to be done somehow; and the rest of my admin scripts work hand in hand, so now that the scripts exist it all is a no-brainer
<cruxbot>
[opt.git/3.6]: rust: 1.62.1 -> 1.63.0
<cruxbot>
[opt.git/3.6]: rust-bin: dropped
nthwyatt has quit [Quit: Leaving]
darfo has joined #crux
<cruxbot>
[opt.git/3.6]: thunderbird-bin: updated to version 102.1.2
<cruxbot>
[opt.git/3.6]: rsyslog: updated to version 8.2208.0