Custom grub efi package for puppy

[rizalmart]

I wonder if someone in puppy developer will provide a custom grub efi packages. Which contains a custom grub efi files with embedded grub.cfg which set to read grub.cfg file beside the grub efi file. So that installing puppy on uefi gpt will be much easier. Just placing custom efi file on efi partition and write grub.cfg file on the same location of grub efi file

[jamesbond3142]

As far as i know, unlike rEFInd, grub2 efi does not have the concept of "booted from" directory. Please correct me if I'm wrong.

To know the boot directory one has to "search", but we need to know what exactly it to search. In Fatdog we look for grub.cfg in root directory of all drives, as well as /boot/grub.cfg.

Of course, we can also search for grub2.efi and then load grub.cfg from thr path found. But then we have to make sure grub2.efi is actually called grub2.efi and not any other name. If you are forced to rename it to bootx64.efi then the logic wont work.

I can help to create a grub2 efi with the embedded grub.cfg that does one of the above. Let me know what you have in mind.

On Thu., 17 Oct. 2019, 00:43 rizalmart, notifications@github.com wrote:

I wonder if someone in puppy developer will provide a custom grub efi packages. Which contains a custom grub efi files with embedded grub.cfg which set to read grub.cfg file beside the grub efi file. So that installing puppy on uefi gpt will be much easier. Just placing custom gpt file on efi partition and write grub.cfg file on the same location of grub efi file

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/puppylinux-woof-CE/woof-CE/issues/1618?email_source=notifications&email_token=AAP7NPR7LOAVK2YY2AYB36DQO4SA3A5CNFSM4JBMSURKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HSF5QWQ, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAP7NPRN7MU5PVY5GRUYWWDQO4SA3ANCNFSM4JBMSURA .

[gyrog]

When I setup a 'uefi' boot partition in 'FrugalPup' (a puppy installer), I ensure that the significant 'grub.cfg' is always the one in the root of the partition, i.e. '/grub.cfg'. To keep '/EFI/boot/bootx64.efi' happy, I place 'grub.cfg' files elsewhere which simply specify that the real one is '/grub.cfg'. I use grub4dos for non-uefi booting, and it's 'menu.lst' is in the root of the partition, so having both config files in the same location makes it easy to check that both configs are correct. I currrently use '/usr/lib/grub/x86_64-efi/monolithic/grubx64.efi' from 'grub-efi-amd64-bin.....deb'

[f0xpup]

You can use a placeholder. SlackwareLive uses an empty file SLACKWARELIVE to search for. Sparky searches for sparky.cfg in /boot/grub/

[f0xpup]

An important question about secure boot: What files have to be signed with the key if you want to boot with secure boot on? Certainly the bootloader (grub2 efi). What else? kernel? init? main sfs?

[gyrog]

Just to be clear, I don't thing we need a special grub2 efi package to use a particular grub.cfg. If you are installing grub2 to do uefi booting, you probably need to create the whole '/EFI' directory anyway.

My biggest gripe with grub2 efi is the small font in the selection screen. I haven't yet found a way to produce a different font file.

But my biggest boot frustration is, how to easily install grub2 for non-uefi booting? I like to store all the appropriate files in a tar file, which I just have to extract into the boot partition, and then generate a grub.cfg. Of course with a non-uefi boot I also have to install an mbr, (all quite easy with grub4dos).

[f0xpup]

My biggest gripe with grub2 efi is the small font in the selection screen. I haven't yet found a way to produce a different font file. .pf2 is the font format in grub2 You can make that from a .ttf with grub-mkfont. Put it in /boot/grub on the boot partition (fat32, esp). In grub.cfg you have to add some lines. Maybe this: _loadfont /boot/grub/fontname.pf2 set gfxmode=auto export gfxmode insmod gfxterm terminaloutput gfxterm maybe this is needed before the last line: _set gfxtermfont=fontname There is also the possibility of using themes. In grub2 you can make it all quite complicated. But my biggest boot frustration is, how to easily install grub2 for non-uefi booting? You need a legacy bootloader anyway, so I prefer to just use good old grub4dos for legacy boot. Install from a running Puppy. Disadvantage is you need 2 configfiles: menu.lst and grub.cfg. That is the case if you do this for a pendrive (boot from usb). But for a normal home PC/laptop you have either msdos/MBR/legacy boot or gpt/EFI, not both.

[bigpup1]

I have used 'FrugalPup' (a puppy installer) to install a working uefi boot loader on a computer with secure boot enabled and legacy boot disabled. So, it is booting with a normal uefi setup. What is needed is already in FrugalPup.

Maybe just add FrugalPup to all Puppy versions.

Or take the boot loader install out of FrugalPup and add it to the Puppy Universal Installer.

Or when the Puppy Universal Installer gets to the point of wanting to install a boot loader. Have it start the boot loader install process in FrugalPup.

You people really need to look at what is offered in FrugalPup when you select to install a boot loader.

[gyrog]

1. I have been trying to use grub2 as a non-uefi boot loader, because I finally sorted out how to get grub2 v2.04 to "search" and load 'vmlinuz' on an f2fs partition. And I have now done that. So I could produce a FrugalPup that fully supports normal frugal installs on f2fs partitions. The hassel is that grub2 takes a lot more to install as a non-uefi boot loader than does grub4dos.

2. I assume that bigpup1 is not lying. However it's not down to my amazing coding. I think that the 'bootx64.efi' I "borrowed" for use in earlier versions of FrugalPup, may have been signed. I suspect if he upgraded to the latest, that uses a debian 'bootx64.efi' it will not work with secure boot enabled, (or his machine has a strange uefi implementation).

3. I think that we have enough instances of Puppy installers that create a uefi bootable usb device by simply copying the appropriate files into an ordinary vfat partition; that we can finally accept that a usb stick is really more like a HD than a CD, and stop dd'ing images to them.

4. I underatand that the Puppy Universal Installer is rather out of date. But I don't think FrugalPup is a replacement. As it's name suggests, it's very focused on "normal" frugal installs only, (and lot's of them). Even it's "ISO" facility doesn't install any Puppies on a CD, rather it creats an ISO that can boot Puppy frugal installs that exist on the HD (or similar device).

[CollaboratorGCM]

I agree with those who are "trying to envision the 'very' mature GRUB2" going forward. This consideration is overdue, IMHO, but necessary as filesystem changes and SSD technology moves forward, as well.

GRUB2 benefits all of us as it is internationally supported by both developers and SSD/HDD/etc vendors, alike. It also has GIT consistency.

If we can wrap our heads around this, taking advantage of its universal use, we benefit as well...Godspeed.

[gyrog]

1. The location of /tmp is more an "init" issue rather than an install issue. But for the record, I use a directory in zram0 as my /tmp.

2. The downside of grub4dos is that it's mbr/bios dependent, so need a different boot loader for uefi.

3. I'm comming to grips with installing grub2 as a non-uefi boot loader, finally worked out how to run "grub-bios-setup" (a kind of equivalent to grub4dos's "bootlace.com").

4. It's slightly ironic; not so long ago setting up a device to do uefi boot seemed difficult, now it seems much easier to setup a usb stick to do uefi boot rather than non-uefi.

[rizalmart]

Regarding the universal installer. The only issue here is the bootloader to start the puppy. Puppy must able to deal with BIOS and UEFI

[CollaboratorGCM]

For those who are working on reviewing GRUB2 for incorporation into the Puppy Linux mix, have JamesBond show his example of booting Fatdog ISO.

@JAMESBOND, look at this ===> https://www.supergrubdisk.org/wiki/Loopback.cfg I know you'll know where this helps in all Future FATDOG's and how applicably useful this single file is. It appears one-single file in the distro's filesystem is all that is needed no matter what the future holds.

Puppy Linux is on the verge of having a bootmanager that keeps up with the times with little to no effort in community development for BIOS & UEFI future distribution boots. This means the world insuring compatibility with future filesystems and future hardware boot management. It reduces the thought, support and future development loads on Puppy developers because GRUB2 is now ubiquitous! (remember the MS boot manager (BM) has kept up with the times over 3 decades. expect this BM to endure, as well, as it now has worldwide developers contributing.)

[gyrog]

1. I think the future belongs to usb sticks rather than CD's. So, I think the future belongs to distriuting Puppy in an archive file suitable for extraction directly to a usb stick, and then boot in uefi, rather than an ISO file. So, I don't see a loopback.cfg that does direct booting of ISO files as a big step forward.

2. FrugalPup's immediate future does not include support for "SecureBoot", I'm still working on function. i.e. using grub2 for both uefi and non-uefi booting and so supporting booting "ordinary", (vmlinuz and puppy...sfs files in the same sub-directory), frugal installs on f2fs partitions. It's still not clear why v11 works with "SecureBoot" for some but v13 doesn't for others (both these use the same uefi code), but I'm pretty sure v15 doesn't and I'm absolutely sure that v16 won't. For me, "SecureBoot" support will have to wait. And my unanswered questions are: Exactly which binaries need to be signed? What is the process for getting them signed? Are there any critera for acceptable binaries?

3. I'll look at putting FrugalPup on git-hub, after the release of v16.

[CollaboratorGCM]

@wdlkmpx, Agreed. ISO presents a universally understandable packaging with years of background familiar use across a whole range of devices and installation understandings.

IFF possible, ISOs should NOT be abandoned. Even the USB storage market could change in the next couple of years and even if so, GRUB2 with its worldwide assistance, like MS's bootmanager, will adapt and stay current.

Here is a 15MB GRUB2 distro https://www.supergrubdisk.org/category/download/supergrub2diskdownload/super-grub2-disk-beta/ that is dedicated to booting ISOs, systems, and the like. GRUB2 Booting is its ONLY primary mission. It will generate all that is necessary to boot an ISO in a traditional ISO manner OR boot an ISO by chainloading. It intends to make it easy to boot ISOs without the hassles in spending time to tailor boot methods. Further the author encourages chat for support. He might save this community hours of trying to get it right. He can be found on GITHUB here ===> https://github.com/supergrub/supergrub

Further, there is a wiki here ===> https://www.supergrubdisk.org/wiki/SuperGRUB2Disk Notice its boot screen on that 1st page. If 15MB is all that it encompasses, PUPs may want to consider a potential embrace to reduce our efforts while gaining a solution in a short period of time.

This is merely presented for ideas to be used by this development community. Hopefully, it could/should lead to a quicker path to a solution that meet PUP's current and future needs. And, its author may choose to join this community if he is aware of the constructive approaches being looked at here.

Each of us knows that nothing is foolproof but with some simple couple steps it takes your ISO to desktop on either BIOS/UEFI FYI

[gyrog]

Yes, we must keep on doing what we've always been doing.

If you already have a working Puppy, then it doesn't matter much what type of container is used for a release, as long as it contains the actual Puppy files, and Puppy can extract the files from it. But if you have only a Windows box, then being able to look inside an .iso doesn't really get you anywhere, since it doesn't contain the files necessary to setup booting from an ordinary vfat partition, like a new usb stick. Whereas it is possible to create an archive file, (preferably one that windows users are familiar with) that can simply be extracted to a usb stick, and then it can be booted with uefi. The efficency of compression of the archive is not important, since the vast bulk of the contents are heavily compressed .sfs files.

[gyrog]

My priority for the moment is to sortout uefi and non-uefi booting using only grub2 compiled from source, that therefore can be updated. And put this into FrugalPup. (Actually I think I have grub2 pretty much sorted, now I have significant mods to make to FrugalPup.)

Only then would I look at the question of a grub2 that supports "SecureBoot".

[gyrog]

@f0xpup , thanks for the tips on grub2 fonts.

[rizalmart]

@gyrog if you want to support booting from secure boot. Investigating how refind works is the key

[CollaboratorGCM]

@gyrog, thanks for your leadership. Once satisfied, after completion; this may be of help ===> https://ruderich.org/simon/notes/secure-boot-with-grub-and-signed-linux-and-initrd

One idea I had several years ago when WOOFCE started: "What if all 'announced' WOOFCE PUPs use a single standard key". Then would it meet requirements to Secure Boots?

This was derived from @TaZoC who used FATDOG's key for his releases of LightHouse64 when he was alive.

So, this is NOT my idea, but could prove useful in this case.

[f0xpup]

I make grub2 bootloaders in SlackwareLive. I do this because it has grub2 installed properly and it is much like Puppy (no secure boot, no systemd, live/frugal) and well documented. And don not want to install grub2 in Puppy, I am lazy.

For an efi bootloader I use this from console (as root): _grub-mkstandalone -o bootx64.efi -O x86_64-efi "boot/grub/grub.cfg=embedded.cfg" -v -d /usr/lib64/grub/x8664-efi/ --compress xz --locales="en@quot" --themes=""

For mbr grub2 is annoying. The size of core.img is limited and it has to be installed on the second sector of the device (?). Easier is to use syslinux or grub4dos to chainload core.img! There is still a size restriction on core.img though. So you cannot embed/include all modules with grub-makestandalone (try it). I use this, inspired by Patrick (Slackware): _grub-mkimage -o core.img -O i386-pc -c embedded.cfg -v -d /usr/lib64/grub/i386-pc/ --compress xz -p '(hd0,msdos1)/boot/grub' biosdisk part_msdos fat part_gpt ext2 normal memdisk nativedisk ntfs iso9660 gzio tar loadenv boot configfile linux chain loopback reboot halt search search_fs_file search_label search_fs_uuid eval test true regexp minicmd extcmd file png jpeg gfxterm gfxterm_background gfxmenu gfxterm_menu font ata at_keyboard usb_keyboard terminal terminfo bitmap_scale play allvideo probe backtrace cat ls help read echo sleep For a minimal core.img you may need just the first 3 or 5 modules. It may also be possible to use a memdisk, so you do not have to preload all the modules you want to use, but load them in the embedded.cfg with insmod. Good instructions http://lukeluo.blogspot.com/2013/06/grub-how-to-4-memdisk-and-loopback.html

I hope this helps.

[CollaboratorGCM]

I think I get what you are saying ... excepting the Red Hat part. As I understand since its inception, GRUB2 is universally worldwide developed with an intent to remain current with all hardware and firmware moving forward in time. ... Much like Linux.

Hope PUPs can get it right as there seems to be a current effort to do so.

In no way should there be steps to disparage any products investigated for PUP use and benefit. But, I acknowledge that we are human and we, all, have preferences. No offense to GRUB2, but mine was syslinux. But watching all the advancements over the past 5 years, I see benefit as hardware changes are on the horizon.

Getting it right now, means we never look back as it will remain current.

[CollaboratorGCM]

Secure boot should be attributed to Intel, seagate, Western digital, Toshiba, IBM, & AMD and their hardware engineers for security protections at the boot level of system starts. It was their proposal to and including OS manufacturers that landed into today's EFI/UEFI dimension.

Some of us dont see the mass need, but, we aren't always listened to. Yet I do acknowledge this benefit in data center environments. It is now the marching facility that we all have to now march to or circumvent as needed.

Make the best decision that can be made for PUPs long term benefit...if possible such that a good decision could reduce the need for developer revisits.

[gyrog]

The problem with the debian bootx64.efi is that it doesn't include the f2fs module. So to provide f2fs support it would be necesary to supply the debian f2fs.mod file along with the debian consolidated debian bootx64.efi, rather subverting the idea of a single large file. And that is an issue with using grub2 for both uefi and non-uefi booting with the same grub.cfg. In non-uefi mode, you need to produce a small core.img so that you can be sure it will fit on the space available in the first sector of the drive. The easy way to do this is to make it as dumb as possible, and provide all the module files to support all the grub2 facilities. In uefi mode, it looks like the popular thing to do is to produce a large consolidated bootx64.efi, and not provide any module files. I suspect this might make "signing" easier. But creates a problem if a needed module has been omitted. For now, I will most likely go with the small core + all module files for both. This means that the grub.cfg file will need to insmod for any filesystem other than fat32, so FrugalPup will produce grub.cfg files that always insmod the module needed for the filesystem of the partition containing the Puppy frugal install.

One of the issues with using other folks grub2 binaries is that they don't all expect fo find the grub.cfg in the same place, so I tend to have a few grub.cfg files in different places that simply say, "configfile /grub.cfg".

FYI. Using the source in grub-2.04.tar.gz, I have:

1. Created an eltorito.img, created a non-uefi iso file with a test FrugalPup->ISO. This booted successfully with isobooter. (So grub2 probably can boot a CD in bios mode.)
2. Created a core.img, and used it to boot Puppy on a fat32 usb stick, in non-uefi mode. i.e. replacing grub4dos.
3. Created a bootx64.efi, and used it to uefi boot the same Puppy on the fat32 usb stick.
4. Generated a 24pt DejaVuSansMono24.pf2 and used it to make the uefi selection screen look "better". Using these I produce 3 files, grub2-efi.tar.xz, grub2-mbr.tar.xz, and grub2-iso.tar.xz. To produce a bootable disk FrugalPup extracts 1 or more of these to the root of the disk, and then adds an appropriate grub.cfg to the root of the disk. (Of course if it's a non-ueif boot of a HD, usb stick etc..., then you also need to run grub-bios-setup to install the mbr and core.img to the first sector of the disk.

Since I now have grub2 setups that work for each of the situations needed by FrugalPup, I will now concetrate on updating the FrugalPup code.

[gyrog]

Does anyone know how the SecureBoot shim thingy works? I'm rather hoping that it might just chainload to the real grub2.

[f0xpup]

Does anyone know how the SecureBoot shim thingy works? I'm rather hoping that it might just chainload to the real grub2.

I think the shim and grub2 efi have to match (at least when you use them with secure boot on). They have to be made at the same time, but I don't know how. In Fedora shim is called bootx64.efi and this looks for grubx64.efi. There is also a separate MokManager efi. In clonezilla it is the same, except I don't find a separate MokManager, maybe it is in shim.

[f0xpup]

   (Of course if it's a non-ueif boot of a HD, usb stick etc..., then you also need to run grub-bios-setup to install the mbr and core.img to the first sector of the disk.

Since I now have grub2 setups that work for each of the situations needed by FrugalPup, I will now concetrate on updating the FrugalPup code.

Another possibility, to avoid grub-bios-setup, is to keep using grub4dos for mbr and chainload from grldr to the core.img from grub2. You see this often, except with syslinux instead of grub legacy or grub4dos. This has the advantage that we still can have grub4dos, Puppy's favorite I would say, if we want. I think it also less sensitive to problems than installing grub2 to mbr.

You have been doing great work with frugalpup, @gyro!!! I look forward to try it out.

[f0xpup]

It looks like the efi files from debian require a special path that is not /EFI/boot. Not usable. Not a priority,

It looks for a grub.cfg in /EFI/debian (that should refer to the real configfile).

[f0xpup]

But when it comes to secure boot, the word Microsoft comes to mind

I don't know if you mean this, @wdlkmpx, but my idea about secure boot (SB) is this: DON'T USE IT. I consider it a case of lock-in/out by DRM or defective by design. It does not give any protection or security. It is really asking MS a permission to use your computer.

Btw, I am surprised that the shim and signed grub2 efi (from clonezilla or debian) are enough to boot Puppy with SB on, because I expect grub2+kernel+kernel modules have to signed. Look in the wiki from Ubuntu about UEFI/SecureBoot. https://wiki.ubuntu.com/UEFI/SecureBoot#How_UEFI_Secure_Boot_works_on_Ubuntu If that is true, I consider impossible in Puppy to support SB properly. Or maybe it is not necessary to have kernel and modules signed, but what is SB good for then?!

It looks like the only disadvantage of grub2 is that is a mini distro

My idea: this makes it extremely INSECURE. It is impossible to know/find out what a grub2 bootloader made by someone else is really doing. So best to make your own grub2.

[CollaboratorGCM]

@gyro, SEND a PM/chat/gmail to @JamesBond to look at this item. He may not have seen this. AND, he has working code for GRUB2, too. Then we will get an implementation that will be consistent across all of the 2019-2020 PUPs.

Expect that he may consult privately, too.

It seems he may not have seen this thread.

[gyrog]

@f0xpup, to setup a non-uefi boot you need to install an "mbr", if you replace grub2 with grub4dos, then you also need to replace grub-bios-setup with bootlace.com.

In FrugalPup, it's not difficult to replace 1 implementation of grub2 with another. This is my 3rd, so changing to a 4th would not be a biggie.

[CollaboratorGCM]

Let's remember that because Microsoft make use of it, the hardware engineers who designed to the spec for booting did NOT make it for just MS. It is in use in data centers and other places where X86 implementations are needed to insure boot security.

Secure boot is not MS. They are merely one OS manufacturer who uses it.

I am not a proponent one-way or another: But, making a good decision is best for PUPs. Not using something because MS uses the hardware feature should not be our thoughts. So if avoiding is best it should be decided because it is the BEST option; with no regard for MS.

[f0xpup]

I know Secure Boot (SB) is used by others than MS. But also for them it is to make sure that boot tools come from a certain source.

This may be relevant to this data centers and other places, but not to a home computer! Home users have other ways to make sure they use trusted sources. They use other trusted sources as well. It is not relevant to them that their sources have SB. So home computers should always be able to turn SB off. There are plans to make home computers that will not have this possibility, maybe they are here already. Forcing SB upon home computers is not meant for security. It is meant to take away ownership of your computer.

In conclusion: I do not consider Secure Boot a best option. I would not support it in an official Puppy. We could give some unofficial support, but that should not encourage the use of it.

[f0xpup]

@f0xpup, to setup a non-uefi boot you need to install an "mbr", if you replace grub2 with grub4dos, then you also need to replace grub-bios-setup with bootlace.com.

Of course. Or use grub4dos installer in frugalpup... if that is possible. Maybe like you enable the use of gParted. Or since grub4dos is in every Puppy, use something like

cat /usr/lib/grub4dos/wee_mbr > /dev/sdX
cp /usr/lib/grub4dos/grldr /mnt/sdX1/

(sdX1 is the boot partition) and then cp path/to/core.img /mnt/sdX1/

menu.lst should contain the entry to search grub2 and have it as default.

[CollaboratorGCM]

Hope the mention of mbr the disk setup used for booting does not mean that the boot disk MUST be a MSDOS disk. Reason: For OVER a decade, GPT and its advantages have been commonplace. All of the mainstream Linux/MacOS/etc recognize this for booting. GRUB2 was built with this knowledge too.

GRUB2 handles (installs too) both GPT/MSDOS disks without issue. This means that developers/users need not know or care which layout a drive has currently. That was a GRUB2 build intent.

@f0xpup says "We could give some unofficial support, but that should not encourage the use of it." I understand your position and it is plausible.

My mere comments are that if PUPs are to venture into modernizing its bootmanager because of its larger community of developers and users, we should look to a presentation that removes (where possible) the users concern of UEFI settings changes so that whatever boot OS he choose at PC turn-on it does not need their halting the PC start to make changes for an OS boot....if possible. I am hopeful this in one of the objectives for taking the modernization step. This is in my knowledge that over 97% of ALL laptops/PCs over the past decade had/has Windows or Mac OSes. From one point of view, we should be thinking about Secure Boot options to make it simple for EVERYONE (develops. users, nerds, mindless) to get and run a PUP with as little external or pre-use steps as possible to get a boot started.

Just some insights to stay focused on the PUP "booting" prize.

[CollaboratorGCM]

As modernization is moving forward: Does this help for this thread for all PCs (except netbooks) manufactured over the last dozen years ===> https://blog.heckel.io/2017/05/28/creating-a-bios-gpt-and-uefi-gpt-grub-bootable-linux-system/

[CollaboratorGCM]

Then this `set timeout=10 set default=0

menuentry 'Puppy ISO Direct Booting to RAM' { set isofile='/puppy.iso' loopback loop $isofile linux (loop)/vmlinuz pfix=ram fromiso=/dev/sdb1/$isofile initrd (loop)/initrd.q } menuentry 'Puppy ISO Direct Booting 2' { set isofile='/puppy.iso' loopback loop $isofile linux (loop)/vmlinuz findiso=$isofile initrd (loop)/initrd.q }`

[f0xpup]

From one point of view, we should be thinking about Secure Boot options to make it simple for EVERYONE (develops. users, nerds, mindless) to get and run a PUP with as little external or pre-use steps as possible to get a boot started.

I understand your position and it is plausible. :-) I have been/will be looking into Secure Boot (SB) from time to time and report. I just do not consider it priority.

I always run my laptop without Secure Boot. And it is really not that big a deal to turn off SB. Anyone booting Puppy from usb or CD/DVD may have to go into BIOS to change boot order anyway. And how about this for simple: This http://helledussen.com/linux/files/UEFI_boot/make_uefi-bootable_usb.html is all you need/need to do!! It works for internal HD as well.

2 additional thoughts around this:

If you have windows on your machine, switching off SB may not be enough to have Puppy booting. You also have to disable fast boot (and maybe something else too, I don't remember exactly) in windows, because it blocks the hdd for other OS. By the way, on SSD fast boot is hardly any convenience.

As I mentionned above and from what I read here https://wiki.ubuntu.com/UEFI/SecureBoot#How_UEFI_Secure_Boot_works_on_Ubuntu and elsewhere, I am surprised that we can boot Puppy with SB on (with shim) while kernel and kernel modules are not signed. It is possible that this SB requirement is turned off by shim (that would undermine the supposed security purpose of SB considerably?!). But I wonder if it could be that my EFI implements SB incompletely, so that on other machines, with other EFI, it will not work. This https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#Secure_boot_criticism is interesting read. Anyway, if we would have to sign Puppy kernel+modules as well, this would mean additional complication with no gain that I can see.

[gyrog]

To do non-uefi booting on a uefi machine you need to disable "SecureBoot" and enable "CSM". To do easy uefi booting you need to diable "SecureBoot". Installing and setting-up a uefi boot with grub2 and "SecureBoot" disabled, is easier than a non-uefi boot with either grub2 or grub4dos. The only reason I can see for doing non-uefi boots is if the machine simply does not support it, i.e. ancient machine.

I don't see any advantage in using grub4dos, going forward. We need grub2 for uefi support, and we can use grub2 for non-uef booting if required.

My current attitude to "SecureBoot" is:

1. Complete Puppy installer that uses only grub2 for uefi and non-uefi booting, that puts us in a position where we can choose to use or not use "SecureBoot" (implementation well under way).
2. If we can get grub2 to work with "SecureBoot" enabled, but with the kernel etc... not signed, so that user still has the freedom to 'change_kernel' to an unsigned kernel, then we should go for it, because that makes things simpler for first boot on a "windows machine".
3. If booting with "SecureBoot" enabled involves singning 'vmlinuz' and 'initrd.gz' etc..., then that is a loss of freedom that is too much for me.

As to windows "fastboot": I don't think that's an issue if Puppy does not use any of the windows partitions. It's not difficult to setup Puppy that way.

[CollaboratorGCM]

OK, SB is a known issue, but we should NOT allow it to stop the upcoming PUPPIES progress. So, maybe the developers can adopt/support an initial release that allows GRUB2 to be its boot-manager.

To support the user community, 2 forum pages can be simultaneously started: GRUB2 in Puppy on BIOS PCs GRUB2 in Puppy on UEFI PCs These 2 pages will probably go a long way to meeting member objectives as they adopt the upcoming PUPs. And it will within its first few weeks quiet in users adoption. Other users as well will contribute such that its understanding becomes widespread quickly.

Other items beyond the initial release in the upcoming PUPs would be addressed over the coming years. This would include SB, new hardware, new partition formats, new ...

This will draw develops into a something consistent very similar to what has happened with other PUP modernizations in our past. We all understand how consistency in our approaches has benefited getting PUPs to what the structures it has today.

Looking forward to the upcoming PUPs with this built-in

[CollaboratorGCM]

In our distant past, Puppy has had a habit of placing files/folders for packages in "odd" places that many true developers consider not as the authors envisoned. Most recent years, some members have placed file-folders in the traditional places to match the author's. We have seen "standard" file-folder placement, recently with SAMBA, JAVA, browser ... just to name a few.

Should GRUB2 land in upcoming PUPs, it is hope that PUP developers take a standard file-folder approach,too; namely GRUB.CFG will be found in /boot/grub/grub.cfg. This makes it simple for any new Linux users who venture into upcoming PUPs way to find consistency for this bootmanager. As well, any current GRUB2 open-source utilities will work OOTB.

FYI

[f0xpup]

I know it boots without secure boot, but I've no idea whether it works with secure boot enabled. bootx64.efi (shim) -> grubx64.efi -> kernel (this is where the boot process may stop in secure boot mode)

I have checked this for Buster on my laptop. This is exact.

[CollaboratorGCM]

Also, we should not overlook the additional GRUB.CFG in /boot/grub/x86_64-efi/grub.cfg which can or should contain explicit insmods. Example:

insmod part_amiga
insmod part_apple
insmod part_bsd
insmod part_dfly
insmod part_dvh
insmod part_gpt
insmod part_msdos
insmod part_plan
insmod part_sun
insmod part_sunpc
configfile /boot/grub/grub.cfg```

[CollaboratorGCM]

Request to Evaluate for PUPPY's bootmanager GRUB2 folder structure

This PUPPY Linux lookalike has a "proper" GRUB2 folder arrangement that other non-PUP users would find consistent when coming to PUPPY Linux.

I "believe" the author publishes on Distrowatch to avoid those who become outraged when a PUP exceeds a certain size or departs from their norms. He/she avoids those complaints. Further, he produces a plethora of distros including one he publishes from time to time, here in Puppyland.

Evaluate it for PUPPY's GRUB2 folder structure

[CollaboratorGCM]

Secure Boot...Click to see, then scroll to the section titled ===> Problem 1 - Finding grub.cfg

Does this view match your view & findings?

[CollaboratorGCM]

This thread was discussing boot manager services upgrades to GRUB2.

I have found a 15MB boot manager distro that boots not only "installed" OSes, such as Windows on system disks, but also will boot ISOs directly!

It works on both BIOS PCs and UEFI PCs and has been around for several years. So, it can be assumed that it has a level of maturity. It, too like WOOFCE, is on GITHUB as well.

Its author is helpful and is responsive. He indicates, here, that he is willing work with PUP distro developers and his knowledge adds a level of GRUB2 use we have never seen in Puppyland.

Is there ANY PUP developer willing to take a stab at spending a few minutes to evaluating his work for PUP's GRUB2 potential? He is appealing to us to overcome the language barrier

IF ANYONE does, please insure we give him the step we took so that PUPPY ISO would boot from his 15MB boot manager. Seems we need a simple (???) file addition to the /boot folder so that your PUP distro would boot directly from the ISO.

EDIT: I may be wrong, but maybe his appeal to us is for someone who will post on the WOOFCE GIT the necessary instructions, requirement, or packaging so that when GRUB2 Boot is in the build, if will be able to not just boot from DVD or Frugal, but also will boot directly from ISO when someone add a PUP ISO to his 15MB boot manager.

[gyrog]

A puppy installer that uses grub2 for uefi and non-uefi boots: http://www.murga-linux.com/puppy/viewtopic.php?p=1041970#1041970

[CollaboratorGCM]

GYROG thanks. This gets the community on its way!

[gyrog]

Using the shim and grub2 from a clonezilla-live usb stick, I can get grub2 to boot with "SecureBoot" enabled (on a HP stream). There's only 2 problems,

1. It's only grub2 2.02, which doesn't have an f2fs support, no f2fs module.
2. Even if it did, modules are not allowed to be loaded under "SecureBoot", so it still wouldn't work unless the f2fs module is included in the consolidated grub2. These are the kinds of problems with "borrowing" grub2 from someone else. We might get lucky and find a later version of clonezilla-live that include f2fs support, but I'm not hanging by my thumbs.

I have one promising lead, https://github.com/ValdikSS/Super-UEFIinSecureBoot-Disk

I started this whole grub2 only thing, so I could provide ordinary f2fs support in FrugalPup.

[gyrog]

I spoke too soon. I got to the grub2 menu and thought that things would work if I fixed the f2fs issue. But when I used an all fat32 usb stick, it did not work, it complained that the vmlinuz had the wrong signature. So using clonezilla-live grub2 is a dead end.

[CollaboratorGCM]

Must thank @wdlkmpx for his pioneering for a loopback.cfg that GRUB2 can use for booting the PUP ISO. His work is reflected here.

His efforts show that a PUP ISO, with its loopback, boots directly from its ISO. Following his instructions, I was able to boot his PUP's ISO in SG2D.

Many thanks for his showing us the path

Looking forward for the upcoming PUPs which could contain this single file to aid booting over the coming years.