NoblePup64 iso to download?

[Jasper]

Hi there

Can someone provide me with a link to the above?

TIA

[tosim]

I know you want 64b, but here is the 32b version:
viewtopic.php?t=11371

[rockedge]

@Jasper
Direct download of 1.47 G ZIP file -> https://github.com/puppylinux-woof-CE/w ... 1818328324
Contains:

Screenshot(2).jpg (17.72 KiB) Viewed 2631 times

All artifacts generated by woof-CE distro build runs -> https://github.com/puppylinux-woof-CE/woof-CE/actions

[bigphil]

@rockedge

I followed the link to the 'Direct download of 1.47 G ZIP file' and github reports 'page not found'.

Any suggestions?

Regards
Phil.

[rockedge]

@rockedge

I followed the link to the 'Direct download of 1.47 G ZIP file' and github reports 'page not found'.

Any suggestions?

Regards
Phil.

Seems to work for me.......but I am uploading to a better position to retrieve! I have to go to lunch and I'll be right back to give the link!

[Marv]

Log in to github and then go here:https://github.com/puppylinux-woof-CE/w ... 0412611068. Downloads have been working for me pretty regularly. @rockedge set up a thread for NoblePup64 here viewforum.php?f=216 so it might be best to move this there?

I've been running NP64 since 8 or so and the current version, 11, is pretty solid IMO. I'm working with a very preliminary LXDE adrive from @peebee with it with good success. Nits:

There is no clipboard as yet. I use Parcellite from a pet in my JWM install and so far clipit is running in the LXDE install but not reliably in the JWM one.

libdvdcss needs to be added to play some DVDs and MPV needs Celluloid added from the repo (for me) to play DVDs.

I disable Xlock in /etc/acpi/acpi.conf, It is enabled by default and IMO the default should be disabled.

The usual caveat using the Synaptic package manager. Reload needs to be run to update the package lists before using it. The lists are huge and stored at /var/lib/apt/lists. I scrub them on shutdown if using a savefile, not necessary for my usual non-savefile installs (y or a drive driven).

All my current portables (Brave, Slimjet, Ungoogled-Chromium, Sylpheed, MasterPDFEditor, LibreOffice) are running OK. The inbuilt Palemoon seems serviceable as a starter browser.

@ozsouth 6.10.4 kernel runs well in it if usrmerge adjusted.

All I can think of at the moment, give it a whirl.

[peebee]

The periodic build will next be updated on 2 September

There is a later testing build at: link expired (you do need to login to Github to download)

libdvdcss is not provided as a binary by Ubuntu - only as compileable source .... there is a Debian version: https://debian.pkgs.org/12/multimedia-m ... 4.deb.html

[rockedge]

Back from lunch on the river....

woof-CE built on 15 August 2024
Download -> ubuntu-noble64-11.zip 1.47 G

zip contains: iso + devx +docx + nlsx + kernel_sources

[Chelsea80]

@rockedge

Back from lunch on the river....

woof-CE built on 15 August 2024
Download -> ubuntu-noble64-11.zip 1.47 G

Please confirm the build date as above.

My diary says today is the 20 August 2024.

Am I missing something?

Thanks

[Marv]

Release version (built 08/20/24) downloaded from github and installed. Clipit confirmed as starting and working both in my JWM and my LXDE flavors. Parcellite removed from my JWM ydrive.

Thanks,

[rockedge]

Please confirm the build date as above.

My diary says today is the 20 August 2024.

Am I missing something?

Thanks

There was a typing error! should be 15 not 25.

[Chelsea80]

@rockedge

Thanks.

Must have been a good lunch

[ally]

https://archive.org/details/Puppy_Linux_NoblePup32

[Clarity]

Hello @ally Your post is about 32bit which is posted elsewhere on the forum.

This thread is for 64bit version and related issues.

Hope this is helpful

[Jasper]

@rockedge

Sorry for the delay in posting back!!

Thanks for the link

Created a GitHub account and am downloading this presently.

[gychang]

Back from lunch on the river....

woof-CE built on 15 August 2024
Download -> ubuntu-noble64-11.zip 1.47 G

zip contains: iso + devx +docx + nlsx + kernel_sources

downloading but will take 4hrs...

[rockedge]

@gychang

I just downloaded the zip file from the link in under 3 minutes. Let me put it on mega cloud location. Fiber optic connection.

here is one to try: https://mega.nz/file/K1YRia5R#xnTZWu3N9 ... Npi1NvGv1o

[Jasper]

.

[Jasper]

.

[Jasper]

.

[peebee]

https://github.com/peabee/woof-CE/relea ... .09-241004

Built to test new FrugalPup-43

[gyrog]

Built to test new FrugalPup-43

Sorry, unfortunately not a complete test.

Yes, 'mk_iso.sh' worked fine, but this Puppy does not contain the grub2.06 binaries from FrugalPup.
This Puppy contains 'usr/lib/grub/x86_64-efi-signed/gcdx64.efi.signed' et al..., in it's 'devx' so the 'mk_iso.sh' script used 'usr/lib/grub/x86_64-efi-signed/gcdx64.efi.signed' as it's 'grubx64.efi'.
It did the first part of the "if" statement, not the "elif" second "FrugalPup" part.

[peebee]

Built to test new FrugalPup-43

Sorry, unfortunately not a complete test.

Yes, 'mk_iso.sh' worked fine, but this Puppy does not contain the grub2.06 binaries from FrugalPup.
This Puppy contains 'usr/lib/grub/x86_64-efi-signed/gcdx64.efi.signed' et al..., in it's 'devx' so the 'mk_iso.sh' script used 'usr/lib/grub/x86_64-efi-signed/gcdx64.efi.signed' as it's 'grubx64.efi'.
It did the first part of the "if" statement, not the "elif" second "FrugalPup" part.

https://github.com/puppylinux-woof-CE/w ... noble#L302

yes|shim-signed|shim-signed,grub-efi-amd64-signed,grub-common|exe>dev,dev,doc,nls

ls shim-signed_DEV/usr/lib/grub/x86_64-efi-signed
gcdx64.efi.signed grubnetx64-installer.efi.signed
grubnetx64.efi.signed grubx64.efi.signed

Same for all Debian / Ubuntu Woof-CE builds:
https://github.com/search?q=repo%3Apupp ... &type=code

[gyrog]

Unfortunately "borrowing" a signed 'grub...efi' file doesn't help us.

If "Secure Boot" is not enabled, then it doesn't matter.

If "Secure Boot" is enabled then the Puppy boot will fail when it tries to load the kernel, i.e. on selecting a grub menu entry.
With no option available to enroll the required MOK for the kernel and modules.
You can get past the issue by booting something else and enrolling the required MOK.
And then reboot into the desired Puppy.

The alterrnative is to use only kernels signed by the up-stream that signed the "borrowed" 'grub...efi' file.

If an unsigned 'grub...efi' file is borrowed, and "Secure Boot" is enabled.
Booting fails when the 'shim' tries to load 'grub...efi' with an option to enroll the appropriate MOK.
If we have signed the 'grub...efi' and the kernel with the same MOK, this will work.

It's all about when the absence of an enrolled MOK for the kernel is detected.

Note1: The 'devx...sfs' does not include any unsigned grub2 ".efi" files.

Note2: In a Puppy environment, it's quite usual to have many Puppies on an internal drive, but only ONE grub.
Major distributions, assume their grub is just for their OS.

[dimkr]

It's all about when the absence of an enrolled MOK for the kernel is detected.

A kernel signed with a MOK won't work, AFAIK there's no automated mechanism to enroll a MOK that doesn't require user intervention (and root privileges or the UEFI password). Such a mechanism would defeat the security advantage of having Secure Boot - if you can enroll a MOK automatically, then userspace malware can easily replace the kernel with a malicious kernel (and hide the existence of the MOK from you). In addition, MOK enrollment requires reboot, so it's a chicken-and-egg situation: you need to enroll the MOK to boot Puppy, but you need Puppy to go through the enrollment procedure.

AFAIK the only way to achieve Secure Boot that works out-of-the-box in a portable distro like Puppy is either getting the kernel signed by Microsoft and boot it directly through EFI stub, or building a shim that verifies the kernel/GRUB against a Puppy CA, but getting the shim signed by Microsoft. (What other OSs do)

[gyrog]

A kernel signed with a MOK won't work,

I've done it with a number of different Puppies.

AFAIK there's no automated mechanism to enroll a MOK that doesn't require user intervention (and root privileges or the UEFI password). Such a mechanism would defeat the security advantage of having Secure Boot - if you can enroll a MOK automatically, then userspace malware can easily replace the kernel with a malicious kernel (and hide the existence of the MOK from you). In addition, MOK enrollment requires reboot, so it's a chicken-and-egg situation: you need to enroll the MOK to boot Puppy, but you need Puppy to go through the enrollment procedure.

Correct.
If you have a signed Grub, and a signed kernel and you have access to a file containing the public key for the MOK that signed these, e.g. 'puppyMOK.cer';
on boot, the "shim" will detect that the grub is not verified, and run "mok manager" to provide you with an opportunity to enroll a MOK from a file on disk.
Only if the user trusts the provider of the MOK and enrolls it via the keyboard, does the boot proceed.
Once the MOK is enrolled, any futue boots of things signed with the same MOK, will proceed without interruption.
This proceedure was documented for Puppy when grub2.03 was released for Puppy serveral years ago.

If we have the same situation, but we have "borrowed" a signed grub...efi, then the "shim" will verify the grub, and boot it.
But when grub comes to load the kernel, it will fiail to verify the kernel, and at this point there is no option to enroll the MOK.
My point being that it is best to sign the kernel and the grub...efi files, with the same MOK, so any key problem can be detected by "shim".

It is possible to use the 'mokutil' utility to initiate the enrolling of a MOK, but it does not do it in the running system.
Nothing happens until the next time you boot, the "shim" will run "mok manager" and you will be given an opportunity to enroll the MOK.
Again the user has to approve this via the keyboard.

AFAIK the only way to achieve Secure Boot that works out-of-the-box in a portable distro like Puppy is either getting the kernel signed by Microsoft and boot it directly through EFI stub, or building a shim that verifies the kernel/GRUB against a Puppy CA, but getting the shim signed by Microsoft. (What other OSs do)

To get Puppy to boot smoothly under "Secure Boot", we need to start by,
compiling and getting Microsoft to sign a "shim", that includes the public key of a Puppy key. (Not likely to happen.)
Then we could use the corresponding Puppy private key to sign the rest.

So we either use a MOK, or don't support "Secure Boot" at all.

[wiak]

I have a feeling the day is coming closer when computers will be released that do not allow secure boot to be disabled, and perhaps not so long later it will not be 'allowed' to enrol any MOK the way described. That day may result in the only way to boot Linux being to use mainstream kernels and modules and so on as part of our systems. i.e. the end of huge kernel style flexibility and the need to include official modules in our initramfs component - of course we can already do that.

[dimkr]

So we either use a MOK, or don't support "Secure Boot" at all.

MOK doesn't give all the security guarantees of a proper certificate issued by a CA, and Microsoft can decide it's no longer signing shims that bypass it by doing the verification themselves (using a distro-owned or user-owned keypair). Supporting Secure Boot through shim and MOKs isn't guaranteed to be 'future-proof', especially when the shim comes from another distro.

I think it's misleading to label this as proper Secure Boot support, and it's definitely inconvenient to enroll a MOK per distro or per kernel. Plus, each time you enroll a MOK, you increase the risk of running a malicious kernel if the person who generated this MOK didn't protect it well.

Without secure, heavily audited, automated infrastructure for signing kernels and boot loaders, plus a shim signed directly by Microsoft that can verify against the Puppy CA, I prefer to just disable Secure Boot.

[gyrog]

@wiak and @dimkr,
I have replied here, viewtopic.php?p=132410#p132410

This is getting rather off-topic.