Language:

en_US

switch to room list switch to menu My folders
Go to page: First ... 46 47 48 49 [50] 51 52 53 54 ... Last
[#] Sat Mar 25 2023 18:03:40 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

syslinux is built for booting with legacy BIOS. It looks like there are some tweaks that make it run on UEFI but it's basically chain loading -- which offers no advantages over GRUB. That description of LOADER running on UEFI sounds like a step in the right direction -- actually making use of the UEFI preboot environment instead of just shimming into a legacy-style boot.

And that's really what I'm looking for: getting rid of the legacy cruft.
It sounds like LOADER does all of the kernel/driver integration during preboot.
On a Linux kernel that would be done by placing both the kernel and the initrd on the EFI partition, and the modules load when the kernel starts up.

I have my root partition on a multi-disk btrfs volume, so that takes the entire syslinux family off the table for me.

It isn't just my system, though. I want to see all of the Linux installers go "oh, this is an EFI system, let's install EFIstub instead of GRUB"

[#] Sat Mar 25 2023 18:34:50 UTC from LadySerenaKitty

[Reply] [ReplyQuoted] [Headers] [Print]

FreeBSD's LOADER has always been a thing.  It's always had the job of loading the kernel and modules.  Some kernel settings can only be applied before the kernel boots, LOADER sets those options, too.  Yes, the BIOS/MBR build of LOADER is still present on meowdern FreeBSD.



[#] Sat Mar 25 2023 21:03:24 UTC from zelgomer

[Reply] [ReplyQuoted] [Headers] [Print]

It isn't just my system, though. I want to see all of the Linux
installers go "oh, this is an EFI system, let's install EFIstub instead

of GRUB"


Now you've lost me. Who uses the installers? :)

Anyway, the problem is that there are a lot of half-assed UEFI implementations out there. I tried to get on the EFIstub train once and discovered that one of my machines won't pass arguments to the kernel. So I have to chain load with a boot loader for anything to work like telling Linux where and how to mount root and what initramfs to use, or which device to send console output to, or anything else you normally put there.

As long as getting a fully functional firmware is a coin toss, no OS maintainer is going to count on that. They're going to continue to install what they know has the highest chance of working.

[#] Sat Mar 25 2023 22:00:38 UTC from Nurb432

[Reply] [ReplyQuoted] [Headers] [Print]

A lot people, its 'easier' than dealing with things by hand.

Sat Mar 25 2023 05:03:24 PM EDT from zelgomer
Now you've lost me. Who uses the installers? :)


 



[#] Tue Mar 28 2023 03:57:41 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]


I did it!

Loosely following the instructions at https://wiki.debian.org/EFIStub , basically just substituting Ubuntu for Debian, and going for my actual kernel args from the running system instead of guessing new ones, I got it to boot. The kernel is kind enough to announce as soon as it starts loading, that it's using the EFISTUB boot method.

There are also some hooks you need to put into place to make it copy the kernel and/or initrd into the EFI system partition again whenever one of them is updated. Obviously if you have some other boot loader, that's already been done for you.

Now I just have to figure out how to convince `apt` that yes, I really do want to delete GRUB off my system. I know it's "dangerous" and I want to do it anyway. I don't like GRUB, I don't want GRUB, and I want to find the person who wrote "GRUB loads the kernel Linux, which in turn loads the operating system GNU" and run them over with my truck.

[#] Tue Mar 28 2023 04:05:39 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]


HAHAHAHAHA I DID IT

The `--allow-remove-essential` option forced it to do my bidding.

I am a happy IG. I've got a GRUB-free system, a stripy tabby cat sleeping on the desk next to me, and plans to attack my work laptop next now that I know the proper incantations to mess with the EFI boot manager.

There are a couple of files that "apt purge" didn't remove, but I think I'll wait until after my next kernel update to mess with it any more. Yaaaaaaaaay!!!
*kermit flails*

[#] Wed Mar 29 2023 17:12:56 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]


I'm going to continue blathering endlessly about this because I like it.

After reading [ https://klarasystems.com/articles/the-freebsd-boot-process/ ] I have a better understanding what Kitty was talking about with regard to FreeBSD, and yes it makes sense. It looks like FreeBSD's "shim" was `boot1.efi` which then chain-loaded to `loader.efi` which in turn links up and starts the kernel. Then they were able to get rid of the extra stage and run `loader.efi` directly as a UEFI executable.

So it was mentioned earlier that LOADER has the ability to bring in kernel modules required at boot time, right? If so then I see why the kernel can't be made a UEFI executable unless you compiled in all the drivers, which is of course a bad idea.

That means you need two pieces, and how those two pieces are built is different between FreeBSD and Linux:

* On a FreeBSD system, the UEFI ROM runs LOADER, which puts together the kernel and modules and loads them together

* On a Linux system, the UEFI ROM runs the kernel, which mounts an initramfs (which also has to be in the EFI partition) containing drivers needed for boot.

Does it seem like I've got that right? I need to build a machine that has both operating systems (and maybe even 'doze to round it out) and fully wrap my head around everything UEFI can do.

[#] Wed Mar 29 2023 17:16:20 UTC from Nurb432

[Reply] [ReplyQuoted] [Headers] [Print]

vms might be a safe way to play...

Wed Mar 29 2023 01:12:56 PM EDT from IGnatius T Foobar

Does it seem like I've got that right? I need to build a machine that has both operating systems (and maybe even 'doze to round it out) and fully wrap my head around everything UEFI can do.

 



[#] Thu Mar 30 2023 18:13:49 UTC from LadySerenaKitty

[Reply] [ReplyQuoted] [Headers] [Print]

FreeBSD: Correct!

Linux: that sounds like a security hole!  Better make sure nobody mounts that!  Additionally, I would advise against running Windows on this machine, if a core component of linux is on such a vulnerable filesystem, some Windows malware might decide to place its own linux kernel on your machine, one made to do some nasty spying.

On FreeBSD, the only binary in the UEFI's msdosfs is loader.efi.  Keeps the kernel and modules in the main filesystem, making it both moar secure AND easier to update.  Nothing specific to UEFI was added to freebsd-update or "make installkernel" or "make installworld", keeping both update processes completely agnostic to the method used to boot.

Wed Mar 29 2023 13:12:56 EDT from IGnatius T Foobar
* On a FreeBSD system, the UEFI ROM runs LOADER, which puts together the kernel and modules and loads them together

* On a Linux system, the UEFI ROM runs the kernel, which mounts an initramfs (which also has to be in the EFI partition) containing drivers needed for boot.

 



[#] Thu Mar 30 2023 18:15:09 UTC from Nurb432

[Reply] [ReplyQuoted] [Headers] [Print]

Or just bad code might eat  your Linux partition.

Thu Mar 30 2023 02:13:49 PM EDT from LadySerenaKitty

 Additionally, I would advise against running Windows on this machine, if a core component of linux is on such a vulnerable filesystem, some Windows malware might decide to place its own linux kernel on your machine, one made to do some nasty spying.

 



 



[#] Thu Mar 30 2023 23:12:49 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

On FreeBSD, the only binary in the UEFI's msdosfs is loader.efi. 

So I guess that means LOADER has knowledge of how to mount whatever filesystem has the kernel on it. Is it smart enough to mount, for example, a multi-disk ZFS volume? How does it handle weird storage drivers that might only be present after the kernel has initialized?

Agreed that a Windoze installation on the same multiboot disk could be problematic.
Windoze doesn't mount the EFI system partition by default, but I think it *can* if the user really wants to do that. Linux does mount it, at /boot/efi but it's root/0700 to keep nonprivileged users away from it. Anyway, if I did such an experiment it would be on a test machine, or as Nurb suggested, on a virtual machine. Quite simply, I wouldn't run Windows at all on a machine I cared about.

(I also need to freshen up my FreeBSD-fu, but that's another story)

[#] Fri Mar 31 2023 02:19:27 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

Anyway, the problem is that there are a lot of half-assed UEFI
implementations out there. I tried to get on the EFIstub train once and

discovered that one of my machines won't pass arguments to the kernel.


Looks like you're right about that, zel.

UEFI booting directly into the kernel works flawlessly on my three year old ASrock motherboard.

But on my eleven year old Dell laptop, I get exactly the behavior you described: no amount of fiddling will coerce the firmware to send the kernel its command line arguments. root= and initrd= aren't passed, and the kernel panics on boot. Thanks for posting that, because you probably saved me hours of trying in vain to figure out what I did wrong.

[#] Fri Mar 31 2023 02:27:45 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]


Yes I'm still carrying on about this... :)

Not passing the kernel parameters is a known problem on some Dell laptops.

[ https://github.com/RobertCsordas/arch-efiboot ]

This guy actually wrote a script to rebuild the kernel and initramfs as a single EFI binary as a workaround. This seems like more trouble than it's worth, even for someone like me who has a strong distaste for GRUB.

If I were an OS vendor I'd write some code to detect the wonky firmware and go with legacy boot if found.

[#] Fri Mar 31 2023 16:26:32 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]


HI, IT'S ME AGAIN!

As it turns out, a fix for the wonky firmware bug is present as of Linux kernel 5.10 and newer. My old Dell laptop was running Linux Mint, which still has an older kernel. Kubuntu 22.10 has kernel 5.19 and this laptop had nothing important on it (not much point in anything other than a terminal and a browser on a machine this old) so I wiped it and reinstalled, did the EFI setup, et voila, my eleven year old laptop is now EFI booting directly to the kernel!

NEVER PICK A FIGHT WITH ME. I AM CALABRESE AND WILL OUT-STUBBORN ANY CHALLENGE!

[#] Fri Mar 31 2023 16:54:04 UTC from Nurb432

[Reply] [ReplyQuoted] [Headers] [Print]

Well. a man has to have goals..

Fri Mar 31 2023 12:26:32 PM EDT from IGnatius T Foobar

HI, IT'S ME AGAIN!

As it turns out, a fix for the wonky firmware bug is present as of Linux kernel 5.10 and newer. My old Dell laptop was running Linux Mint, which still has an older kernel. Kubuntu 22.10 has kernel 5.19 and this laptop had nothing important on it (not much point in anything other than a terminal and a browser on a machine this old) so I wiped it and reinstalled, did the EFI setup, et voila, my eleven year old laptop is now EFI booting directly to the kernel!

NEVER PICK A FIGHT WITH ME. I AM CALABRESE AND WILL OUT-STUBBORN ANY CHALLENGE!

 



[#] Fri Mar 31 2023 20:15:43 UTC from zelgomer

[Reply] [ReplyQuoted] [Headers] [Print]

As it turns out, a fix for the wonky firmware bug is present as of
Linux kernel 5.10 and newer. My old Dell laptop was running Linux

How? Was it actually a kernel bug all along, or did they implement some clever workaround? I can't imagine how you could work around it from the kernel except to build arguments into the kernel like you posted earlier.

[#] Fri Mar 31 2023 23:43:52 UTC from LadySerenaKitty

[Reply] [ReplyQuoted] [Headers] [Print]

LOADER is capable of booting multi-disk ZFS roots.  If you have some funky disk configuration that is outside the standard, you can always use UFS2 for /boot.  Currently, LOADER only knows how to read from 2 filesystems - UFS2 and ZFS.  Hilariously, this means LOADER is capable of reading 100% of the supported rootable filesystems.

If your FreeBSD installation is rooted on some non-standard filesystem, you need to tell LOADER to load the driver for that filesystem and stick /boot into a UFS2 partition.  The ZFS driver is not compiled in as part of the GENERIC kernel, it's always loaded with the kernel by LOADER.

LOADER does not mount anything.  All it does is load what's needed then kicks off the kernel.  The kernel is responsible for doing its initial mounting.

Thu Mar 30 2023 19:12:49 EDT from IGnatius T Foobar
On FreeBSD, the only binary in the UEFI's msdosfs is loader.efi. 

So I guess that means LOADER has knowledge of how to mount whatever filesystem has the kernel on it. Is it smart enough to mount, for example, a multi-disk ZFS volume? How does it handle weird storage drivers that might only be present after the kernel has initialized?

Agreed that a Windoze installation on the same multiboot disk could be problematic.
Windoze doesn't mount the EFI system partition by default, but I think it *can* if the user really wants to do that. Linux does mount it, at /boot/efi but it's root/0700 to keep nonprivileged users away from it. Anyway, if I did such an experiment it would be on a test machine, or as Nurb suggested, on a virtual machine. Quite simply, I wouldn't run Windows at all on a machine I cared about.

(I also need to freshen up my FreeBSD-fu, but that's another story)

 



[#] Sat Apr 01 2023 16:03:21 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

How? Was it actually a kernel bug all along, or did they implement
some clever workaround? I can't imagine how you could work around it

From a read of the patch [ https://tinyurl.com/2juyfrmg ] my understanding is that the buggy Dell firmware is actually sending *more* data to the kernel instead of just the command line. "At least some versions of Dell EFI firmware pass the entire EFI_LOAD_OPTION descriptor, rather than just the OptionalData part, to the loaded image."

So the patch looks for this, and if it sees the extra vomit from the Dell firmware it knows how to filter out just the command line arguments.

Basically the command line arguments were there all along, but the buggy firmware encased them in a bunch of other crap, the patch recognizes this and strips out the crap, the kernel boots and gets its command line arguments, problem solved. So now is the time to get back on the EFISTUB train! :)

By the way ... I had a peek at the partition manager on my work machine ... Windoze doesn't let you mount the EFI system partition, even if you're an administrator. I'm sure you could find a way to write to it, but it isn't as simple as assigning a drive letter in Disk Mangler.

[#] Sun Apr 02 2023 02:22:55 UTC from zelgomer

[Reply] [ReplyQuoted] [Headers] [Print]

command line arguments, problem solved. So now is the time to get back

on the EFISTUB train! :)

Tempting. May have to spend some time on this at some point. Thanks for the update!

[#] Sun Apr 16 2023 10:43:36 UTC from papa

Subject: Getting into game programming

[Reply] [ReplyQuoted] [Headers] [Print]

If a moderately-experienced programmer wants to learn how to program games (platform-agnostic) as a hobby, what language and graphics framework would you suggest?



Go to page: First ... 46 47 48 49 [50] 51 52 53 54 ... Last