<ppetrov^>
I'd appreciate your feedback. If there's something to be corrected, added or (?) removed, let me know. I am open to suggestions and criticism.
<SiFuh>
CRUX is a stone?
<ppetrov^>
:D
<SiFuh>
I only quickly skimmed it, but so far looks good
<ppetrov^>
thanks!
<SiFuh>
The text is always to the point <-- This is true for sure
<ppetrov^>
yes. Also first impression matter and I did get a great first impression from the handbook, already some 10 years ago when I tried CRUX
<SiFuh>
I find it nice that the command names are short and roll smoothly on the keyboard <-- I agree but I do find it conflicts with OpenBSD pkgadd and pkg_add :-)
<ppetrov^>
heh, well i never used openBSD
<ppetrov^>
but, seriously, typing "pkgmk" feels so natural. the keys being quite close to each other
<SiFuh>
You have mplayer in your repo
<ppetrov^>
yes, adapted from your port
<SiFuh>
I don't use it anymore but kept it for others
<SiFuh>
I also don't use shotcut or vlc or pretty much most of everything. :-P I am currently working on shotcut update. Probably won't be ready for 1 or 2 days. Thanks to gcc-fortran and the slow machine I am compiling on
<ppetrov^>
i need it for electricsheep
<SiFuh>
Is your repo available on portdb?
<ppetrov^>
no
<SiFuh>
You suck
<ppetrov^>
jaeger said to just contact him when i think it's ready
<ppetrov^>
i do
<SiFuh>
Hahahahaha, I just want to offload my ports :-P
<ppetrov^>
prtverify and fixed a few ports
<SiFuh>
I like jaeger's version of the portdb
<ppetrov^>
i have been pretty busy lately, i am even surprised i felt like writing a review
<SiFuh>
I forwarded it already to a friend in Colombia
<ppetrov^>
i decided not to compare wth other distros, but to me it seems impossible to read Debian's handbook in a short period of time
<SiFuh>
I found the same with Arch Linux's SYSLINUX section and their full disk encryption.
<ppetrov^>
i hope someone will find it useful. Whatever i have read was either too old or really not extensive enough. Even DistroWatch did a review which is, let's say incomplete
<SiFuh>
jdk8-sym
<SiFuh>
prtverify mass cleanup
<SiFuh>
I see
<ppetrov^>
ah this
<ppetrov^>
i use the adoptium flavour
<ppetrov^>
jdk8-sym is a dirty trick to fool ports i have something i dont
<SiFuh>
I was perusing the commit messages mostly
<ppetrov^>
ah
<ppetrov^>
well yes, removed a bunch of READMEs, fixed my name in a few ports
<SiFuh>
All good
<SiFuh>
What is the reason for Open Office?
<ppetrov^>
i cannot stand gtk3
<ppetrov^>
i have issues, i know
<SiFuh>
I actually about about the GTK3 part
<ppetrov^>
also i normally use WPS office, a chinese clone of MS office. OOo I use rarely with Zotero when I need to deal with references
<ppetrov^>
you what? about about?
<SiFuh>
I actually agree about the GTK3 part
<ppetrov^>
well...
<ppetrov^>
at some point i will probably switch to lxqt, i am already using some stuff from them
<ppetrov^>
pavucontrol-qt looks better than pavucontrol in a GTK2 desktop
<ppetrov^>
(still using Xfce 4.12)
<SiFuh>
Telegram, shotcut, firefox, thunderbird, qbittorrent are all I have left that are not console/terminal/curses base
<SiFuh>
On CRUX I have only Virtualbox that is not console/terminal/curses base.
<SiFuh>
Oh and I have libreoffice, but rarely use it at all
<ppetrov^>
WPS office all the way, man...
<ppetrov^>
I had used OOo LibreOffice for nearly 15 years, and I hated it. then I discovered WPS.
<ppetrov^>
i have done countless of presentations in Impress, which is a piece of sh*t
<SiFuh>
One of the things that shits me about Libreoffice is I can set up a page to print a form, but if it gets printed on Windows it comes out different
<ppetrov^>
heh
<ppetrov^>
so SiFuh, any other comments? Something you don't agree with?
<SiFuh>
I didn't agree with grub...
<SiFuh>
Hahaha all good here. I didn't find anything major
<ppetrov^>
what about it?
<ppetrov^>
that I chose grub?
<SiFuh>
:-P
<ppetrov^>
heh
<ppetrov^>
i tried syslinux on my work pc and it just did not work
<ppetrov^>
grub worked like a charm
<ppetrov^>
believe me i followed the instructions
<ppetrov^>
for the record slackware's elilo did not work either
<SiFuh>
The instructions are not to my liking, but they do work. There was an issue with the lack of efi stub being mentioned that needed to be in the kernel
<ppetrov^>
i had this
<ppetrov^>
otherwise i do like syslinux's syntax more than grub's
<SiFuh>
You can practice in a VM
<ppetrov^>
heh
<SiFuh>
I did notice your configuration in that page you wrote was using BIOS MBR loading
<ppetrov^>
trust me on this one: sometimes it just does not work
<farkuhar>
But a VM might not faithfully reproduce the differences in video card support, between grub and syslinux. On bare metal I haven't gotten syslinux to show a prompt, but grub will happily display a menu. Both of them end up booting the kernel, though.
<ppetrov^>
thisch led to this ^
<SiFuh>
farkuhar: CONFIG_EFI_STUB
<farkuhar>
SiFuh: all my kernels are built that way. Not sure what that has to do with syslinux being unable to show a prompt *before* a kernel is selected.
<ppetrov^>
SiFuh, for this "CRUX is a stone?", i shoukd've answered the obligatory "it's a mineral"
<SiFuh>
Heh
<SiFuh>
Isn't the ISO/CD bootloader (SYS)ISOLINUX?
<farkuhar>
For the record, the firmware in question is from a 2015 HP laptop. While it would have been nice for syslinux to support such an old video card, I don't mind not seeing a prompt, as long as the bootloader respects my config file and passes the requested kernel parameters.
<SiFuh>
farkuhar: so it does boot but you are blind?
<farkuhar>
SiFuh: essentially yes.
<SiFuh>
Maybe you can pinch an idea or two from the install ISO configuration
<SiFuh>
But I am kind of your side though. I actually don't want to see my bootloader. Just boot. But it comes in handy being able to access it though when a new kernel fails
<farkuhar>
SiFuh: the only directives in the install ISO config but not in my syslinux.cfg are SERIAL and DISPLAY. As you said, I could pinch one of those ideas to see if it makes a difference.
<jaeger>
The install ISO uses syslinux (BIOS) and grub (UEFI)
<SiFuh>
I had SYSLINUX on two HP's one was the HP Pavillion D5. The other I can't remember. I will need to search the photos of HP laptops to find it. But I do know that laptop was before MH370
<SiFuh>
thanks jaeger
<jaeger>
np
<farkuhar>
jaeger: if the install ISO uses grub during UEFI booting, then I'm not surprised at seeing a menu even with older video cards. I can live with no menu after installing syslinux as the bootloader, except when a new kernel fails, and then it becomes annoying to have no interactivity.
<jaeger>
Entirely up to you, of course syslinux CAN be made to show a menu if you want it to, but obviously not required
<SiFuh>
HP ProBook 4420S <-- farkuhar was the other
<jaeger>
For a bit of anecdata, the reason the ISO uses both is because at the time that the current style of boot was created, syslinux "just did not work" no matter what I tried. It's possible that it could be used now, I have not gone back to investigate that possibility
<jaeger>
Specifically UEFI, it worked fine for BIOS
<SiFuh>
jaeger: I seem to remember looking into that not long ago and isolinux didn't boot UEFI
<jaeger>
I think that's still true, but it would be the efi syslinux executable in this case, presumably
<jaeger>
In other words, I don't think isolinux would NEED any UEFI support
<SiFuh>
I also remember checking that syslinux won't boot ISO's
<SiFuh>
Pretty sure hybrid USB iso's could though.
jue has joined #crux
<farkuhar>
even if the install ISO can be made to use syslinux with UEFI, I still think the current configuration should be kept. My experience with ancient hardware indicates that syslinux is less aggressive than grub (less "hostile" to use H. Peter Anvin's phrase) in resetting the video mode, and you definitely want a menu to appear when booting from the install ISO.
<SiFuh>
Agreed, as much as I dislike grub
<SiFuh>
I was back during 3.6 working on an ISO that booted from ISOLINUX only and only the install CD was musl to make it much more compact. But I lost that by accident
<SiFuh>
But I do remember that I was stuck with UEFI with ISOLINUX
<SiFuh>
Someone also recommended using busy box instead of musl/CRUX but that also vanished like a ninja fart in an hurricane
<SiFuh>
ppetrov^: Where does
<SiFuh>
grub-install /boot/efi install too?
<SiFuh>
Because the SYSLINUX in the handbook is horribly in /boot/efi/efi/boot :-P
<SiFuh>
So the mount point is /boot/efi/ and the subdirectory is then efi/boot
<SiFuh>
farkuhar: Do you think it is possible that a previous install of grub in UEFI could conflict with the boot process if you are using SYUSLINUX without using efibootmgr to configure EFI?
<SiFuh>
Usually when I get a new machine, I use efibootmgr to erase all EFI entries
<ppetrov^>
SiFuh, grub installs to /boot/efi7EFI
<ppetrov^>
SiFuh, grub installs to /boot/efi/EFI
<SiFuh>
Is there a directory named 'boot' under '/boot/efi/EFI' ?
<ppetrov^>
yes
<ppetrov^>
I have BOOT, grub and Microsoft
<ppetrov^>
the latter is from the windows installation that I ditched
<ppetrov^>
simply have not cleaned it yet
<SiFuh>
So I wonder what EFI grub is pointing too actually
<SiFuh>
SYSLINUX points to /boot/efi/EFI/BOOT/BOOTX64.efi
<SiFuh>
From UEFI point of view since mount points are useless. It will see it as from the efi partition EFI/BOOT/BOOTX64.efi
<SiFuh>
EFI being a folder on the efi partition that is.
<jaeger>
You can put your ESP wherever you want
<jaeger>
/boot/efi is convention, not requirement
<SiFuh>
Try sane ;-)
<jaeger>
It could be /opt/sifuh/was/here/efi/grub/grubx64.efi for example
<ppetrov^>
aiiiiii
<SiFuh>
I don't think I want it there
<jaeger>
My point stands, though, it CAN be there
<SiFuh>
ANyways the point is the mount point doesn't exist from the view of UEFI
<jaeger>
`grub-install <ESP mount point>` works either way
<jaeger>
yep
<jaeger>
You can see the actual EFI entry's path with efibootmgr
<SiFuh>
WHich brings me to my point
<SiFuh>
Could the EFI entry from a previous grub install stop SYSLINUX from being detected?
<jaeger>
No
<ppetrov^>
SiFuh, I did not have a previous grub install
<jaeger>
Though many EFI implementations do different things
<jaeger>
So it's possible the implementation on a particular board could be dumb
<jaeger>
But it's not grub or syslinux's fault when that happens, it's the manufacturer, heh
<SiFuh>
This is quite a common problem.
<jaeger>
Most of the hardware I've used can run multiple EFI boot loaders and entries just fine... HP ones I've used in the past were finicky as well as the first gen of apple's weird 32-bit EFI on 64-bit systems
<jaeger>
I have a system right now with both grub and syslinux installed for testing, for example
<SiFuh>
Myself I have never had an issue except once with a Digital TV Input Box back in the very early EFI days.
<SiFuh>
jaeger: did you write the SYSLINUX into EFI with efibootmgr?
<jaeger>
yes
<SiFuh>
I am not using efibootmgr and I think farkuhar only lightly touched it in the handbooks since it isn't essential
<jaeger>
If you don't use efibootmgr or for some reason don't want EFI boot entries at all, it SHOULD work using the default path of <ESP>\EFI\bootx64.efi but whether or not the manufacturer decided to comply with that is a question
<jaeger>
In that case you cannot have multiple boot loaders without trickery such as chainloading, but most users probably don't care about that
<SiFuh>
So my question is if you wrote grub into the EFI and decided no longer to use grub but never removed the entry would UEFI still find <ESP>\EFI\bootx64.efi?
<jaeger>
You would need to change the boot order
<jaeger>
Because the grubx64.efi entry would still be first without some intervention
<SiFuh>
See this is something I never tested. I just erased everything.
<jaeger>
Unless you installed both bootloaders to \EFI\bootx64.efi without using efibootmgr at all
<jaeger>
In that case whichever one you did last is the only one that exists.
<SiFuh>
So it is possible this could cause issues for people migrating from other distros to CRUX?
<jaeger>
Not if they follow instructions, I think
<jaeger>
If they don't, sure :)
<SiFuh>
I never saw erasing EFI in the handbook
<jaeger>
You don't need to erase an old entry to create a new one
<SiFuh>
But ther new entry was lightly touched since it wasn't essential
<jaeger>
A new entry would be essential for a new install, I'd say
<jaeger>
Unless I'm misunderstanding what you mean by essential
<SiFuh>
CRUX handbook 3.2.1.3. SYSLINUX, in UEFI boot mode
<SiFuh>
'Saving a copy of syslinux.efi to the more generic name BOOTX64.EFI helps avoid the extra step of customizing boot entries with efibootmgr.'
<jaeger>
Ah, ok, I see what you mean now. This section of the handbook should be updated
<farkuhar>
If I recall correctly, the recommendation was to overwrite \EFI\BOOT\bootx64.efi rather than mess with efibootmgr -o (explicitly setting the BootOrder). If someone wants to chain-load or dual-boot, then further reading of the efibootmgr documentation is required.
<SiFuh>
If you follow the generic path you do not need to bother with efibootmgr or UEFI entries at all. It will be found automatically. However, if you have an old DISTRO install pointing to a non-existant grub*.efi you may need to erase that possibly?
<jaeger>
If you were to install something else which has an EFI boot entry, then install crux and NOT use an EFI boot entry, you could run into problems. At that point MAYBE the manufacturer of your board is nice and their EFI implementation tries the default if the first entry fails or something... maybe not
<jaeger>
I would recommend always using an explicit efibootmgr entry to avoid this issue
<SiFuh>
farkuhar: Yours is correct. Nothing wrong with it. Just trying to figure out if an old entry may effect a fresh install with a different bootloader and the UEFI wasn't modified.
<SiFuh>
I reckon we need to test this before jumping to conclusions though.
<jaeger>
Would depend on what the previous install used... if every distribution/OS uses the default bootx64.efi, great... but I would be surprised if that's the case
jue has quit [Ping timeout: 272 seconds]
<SiFuh>
If I installed debian and it wrote a grub entry, then I killed debian and installed CRUX, I always used efibootmgr to remove the debian grub entry. I never bothered though writing a CRUX entry, as it wasn't important or needed.
<jaeger>
I would have to have a boot entry for mine because I don't rename the efi executables
<jaeger>
Which is fine for me since I prefer to be explicit
<SiFuh>
Techincally, no entry is needed if you follow the default layout.
<SiFuh>
Understood
<SiFuh>
So you'd be using syslinux.efi
<jaeger>
That assumes the manufacturer did the right thing... which hopefully all modern ones do
<farkuhar>
A number of distros these days are running grub-install --target=x86_64 --removable, which writes to the default path \EFI\BOOT\bootx64.efi rather than a distro-specific filename. I'm sure there are some distros that prefer to go their own way, and then SiFuh's concern about previous installs of other distros is valid.
<SiFuh>
To be honest, I don't have the time to look into or test this for a while.
<SiFuh>
farkuhar: If they did \EFI\BOOT\bootx64.efi then that's fantastic
<SiFuh>
For what it is worth farkuhar I think your additions to the handbooks are awesome
<farkuhar>
I suppose it wouldn't hurt to add a sentence in the handbook reminding users to run efibootmgr before rebooting, to ensure that the BootOrder doesn't have invalid entries from a previous install.
<jaeger>
agreed
<SiFuh>
How about a note rather than a reminder as in you may need to .....
<SiFuh>
Some users may need to remove previously configured entries with efibootmgr if another distro was installed blah blah blah
deercoder has joined #crux
<farkuhar>
ppetrov^: you mention openbox+tint2 as a popular combination in your CRUX review ... that reminds me, there's an openbox-inspired Wayland compositor called labwc, whose recent release I would like to try. The pre-release version was running quite well when I tried it back in August.
<ppetrov^>
farkuhar, I have never heard of it. Also, openbox + tint2 i have never used myself. really, I have only *heard* it's a popular combination
<SiFuh>
fluxbox forever
<farkuhar>
ppetrov^: although you might "prefer if CRUX moved at a slower pace with the updates", the practice of following every minor upstream release ensures that no matter when a new user installs CRUX and syncs their ports tree, they needn't worry about hitting "404 not found" errors from the upstream hosts.
<ppetrov^>
yep
<farkuhar>
it's been known to happen that the upstream project quickly makes out-of-date tarballs unavailable. Like you, I often get lazy and only update my repo "when I feel like it", but if core/opt/xorg/contrib maintainers all did the same, we'd hear a lot more complaints on this channel about broken URLs.
<ppetrov^>
makes sense. I know that's how CRUX does things and I am fine with it
<SiFuh>
It would grow like a dominoes effect. Suddenly having ports that no longer compile because you have a modern dependency that a dependant can't be built against
<SiFuh>
Which is what is happening now. Trying to get shotcut updated, but on this slow ass pile of crap it will take a while
<farkuhar>
SiFuh, jaeger: i added a bullet point in the handbook section about syslinux in UEFI boot mode, regarding the possibility of lingering boot entries from other distros. Not as prominent as a Note or Warning, but the surrounding bullet points are no less important and should be given roughly equal attention by a first-time user.