(old)Puppy Linux Discussion Forum

gcav wrote:I am also seeing the errors.
Does anyone know if netstat changed? or the kernel changed?

it's not errors, "netstat -c" doesn't exist in busybox. And ip-v6 can be added easily. So not a bug.

There is a bug in JWM snapshot 976

It affects mtpaint and mypaint. Settings toolbar window opens
behind the main window. I've sent a bug report to Joe.

_______________________________________________________

The latest HP mini PC is more linux friendly
https://www.youtube.com/watch?v=Ro4VWSBPJ00

_______________________________________________

When I downloaded and installed stable version 2.2.2 of jwm,
the problems with mtpaint and mypaint disappeared.
http://www.joewing.net/projects/jwm/
______________________________________

don570 wrote:There is a bug in JWM snapshot 976

It affects mtpaint and mypaint. Settings toolbar window opens
behind the main window. I've sent a bug report to Joe.

_______________________________________________________

The latest HP mini PC is more linux friendly
https://www.youtube.com/watch?v=Ro4VWSBPJ00

_______________________________________________

I compile 1040, it still has the bug that you found.

Unfortunately, it has a lot more bugs, breaks our themes.
I posted a bug report:

https://github.com/joewing/jwm/issues/166

I have a flash stick that boots on both BIOS and UEFI computers, the latter without needing "legacy boot".

I am using syslinux.

Trying to figure out some peculiarities with the UEFI boot, hope to upload 7.0.3 soon.

Nice, are you using syslinux for both? That was something I wanted to try. Secure boot and Refint are a bear if that is holding you from releasing just give us it with out secure efi for now. Hopefully you would bless an official secureboot shim for all of puppylinux spins ( like I reuse Fatdog64 ) in the future.

The stable version of JWM ---> 2.2.2
works well with mypaint and mtpaint.
If that is important to anyone,
it can be installed easily.

Ted Dog wrote:Nice, are you using syslinux for both? That was something I wanted to try. Secure boot and Refint are a bear if that is holding you from releasing just give us it with out secure efi for now. Hopefully you would bless an official secureboot shim for all of puppylinux spins ( like I reuse Fatdog64 ) in the future.

Yes, syslinux for both.

It requires secure boot to be turned off. I intend to post instructions to do that, it is pretty straightforward.

BarryK wrote:... It requires secure boot to be turned off. I intend to post instructions to do that ...

Don't know if this has been seen, but @Jamesbond makes a response over last day or so, instructing how to UEFI and BIOS boot. See his very last sentence, intended for anyone wanting UEFI, in his post, here.

Hope this helps

Formal BIOS or not isn't there some kind of pre-boot, BasicInput code always required in FW whether it's burnt into RAM/ROM/ or even embedded in cpu? Is this a proposal to undertake a 'rooting' type of process beloved of mobile-geeks? Or is it something like the (hidden) BIOS type of juggling we used to do a couple of decades ago with a DOS floppy? Not my main interest, but have undertaken the latter many times to recover functionality of HW that board manufacturers at the behest of the OS-beast would've preferred to remain inaccessible. How is SB 'turned off'? Where does it reside? What are the consequences, including the unintended ones?!

RE: Secure Boot
---
In theory, all you need to do to make Secure Boot works is:
1. Get mjg59's shim http://mjg59.dreamwidth.org/20303.html
2. Rename shim as /EFI/Boot/bootx64.efi. Put MokUtil in /EFI/Boot too.
3. Create a new self-signed cert with openssl. Use rsa as the cipher.
4. use sbsign to sign syslinux.efi. Put the signed syslinux.efi in /EFI/Boot/grubx64.efi.
5. Convert the cert to DER format and put this somewhere in the flash drive (/EFI/boot is a good location) so that later you can find it at boot time.

That's it!

Except that it does not work. Something is funny in the way that syslinux 6.03 build its EFI binaries, and shim refuses to load syslinux.efi at boot time.

If you replace step 4) with rEFInd instead, it will work. If you replace step 4) with grub2-efi, it will work too. I don't know whether this is shim's bug or syslinux bug, probably a bit of both.

I am using mjg59 shim (the original). Since then, there have been other signed-shims (e.g. Ubuntu, opensuse, redhat, etc) that may correct the problem - I haven't tested yet.

If you don't mind using rEFInd, the above steps will work. Tell rEFInd to load syslinux.efi instead (warning: both rEFInd and syslinux.efi must be signed as per step 4), or, better yet, just drop syslinux altogether and use rEFInd to load vmlinuz (vmlinuz must be signed too, and the kernel must be configured with CONFIG_EFI_STUB).

All these hoop-jumpings work in standard non-Secure Boot too (you can forego the signing if you don't use SB).

Fatdog64 uses this boot chain:
shim (renamed to bootx64.efi) --> rEFInd (renamed to grubx64.efi) --> grub2-efi (grub2.efi) --> vmlinuz. There are reasons why we use both rEFInd and grub2, but that's a story for another time.

@Sage - the SB setting is in the BIOS settings. If you can get into the UEFI BIOS settings, and that UEFI BIOS is not crappy enough, you will find some settings to disable SB. Just like you can change the computer time in BIOS and/or configure the boot order, etc. Having this switch in BIOS is actually a requirement of Windows 8 certification (vendors can drop other important and really useful parts of UEFI, but they cannot drop this switch. Mind you they are not helping us, they are doing that to avoid lawsuit). In Windows 10 machines, however, this may change as MS no longer insist that SB can be disabled.

Thanks for that, jb. Yes, I've been switching off SB and/or activating legacy boot functions in BIOS for a few years now. It's the W10 machines that trouble me. Are you saying there will still be a battery-backed BIOS ROM (or even non-battery ditto)? If there is a BIOS somewhere, it should be possible to intercept it, replace it and/or modify it? If there's no hidden function or any legacy function, it'll just be a matter of time before third party files will start appearing. However, if there's no BIOS, recognisable or not, then other strategies may be needed. Which?

Sage wrote:Are you saying there will still be a battery-backed BIOS ROM (or even non-battery ditto)? If there is a BIOS somewhere, it should be possible to intercept it, replace it and/or modify it? If there's no hidden function or any legacy function, it'll just be a matter of time before third party files will start appearing. However, if there's no BIOS, recognisable or not, then other strategies may be needed. Which?

Yes, there will always be. UEFI is *BIOS*, regardless of how others may explain that it is not. This UEFI BIOS stores its setting in an "NVRAM" (non-volatile RAM) - but the spec does not specify how this is to be implemented (or better wording: I don't read the spec so I wouldn't know, and even if I do read it, most manufacturers only implement the spec as far as it is convenient for them, cost-wise). This NVRAM could be battery-backed CMOS RAM like from the legacy BIOS days, or it could be a flash-memory. Either way, the UEFI BIOS itself is most likely stored in a flash memory too like modern-day BIOS and it is upgradeable (=read: replaceable) by flashing it with a special flash tool.

Whether it will be physically replaceable like the legacy BIOS chips however depends on the motherboard manufacturer - the flash memory that keeps the UEFI BIOS may be a separate socketed chip, or it could be an embedded flash in soldered motherboard support chip (probably the latter nowadays). But if you really want to push it, there must always be a JTAG connection somewhere to program these chips, if need be. You just need to figure out where is the (usually hidden) connector

..soldered motherboard support chip (probably the latter nowadays).

That is wonderful news. I've perfected a somewhat brutal method for removing smc ROM chips and replacing them with a socket. As for 'special tools' they usually appear on eBay websites sooner or later, often an entrepreneurial young person operating from HK, (possibly with a cross-border partner?!), often accompanied by a d/l file service for a few A$. Long may they prosper.

gcmartin wrote:

BarryK wrote:... It requires secure boot to be turned off. I intend to post instructions to do that ...

Don't know if this has been seen, but @Jamesbond makes a response over last day or so, instructing how to UEFI and BIOS boot. See his very last sentence, intended for anyone wanting UEFI, in his post, here.

Hope this helps

Just in case, for anyone reading this thread who is unsure about UEFI terminology, a clarification is that UEFI and Secure Boot are two different things.

I am supporting UEFI booting, but with Secure Boot turned off.
Taking baby steps!

There is something very odd about crontab in April64

Setting the minute DOES work but setting the hour of the job DOESN'T.
That is why pschedule only works sometimes.

When I compared with fatdog 630 I noticed that the version of crontab
is different and the file sizes are MUCH bigger in fatdog.

don570 wrote:There is something very odd about crontab in April64

Setting the minute DOES work but setting the hour of the job DOESN'T.
That is why pschedule only works sometimes.

When I compared with fatdog 630 I noticed that the version of crontab
is different and the file sizes are MUCH bigger in fatdog.

In April, and all of the pups I built, crontab is a symlink to busybox, so is a busybox applet.

So, I think that zigbert has developed Pschedule to work with the busybox crontab.

I see some issues already reported in the Pschedule thread:
http://murga-linux.com/puppy/viewtopic. ... &start=120

Note that April (and April64) does not save /var/spool/cron over reboots.
Only /var/local is saved.

If cron could be changed to use /var/local, if anything needs to persist over reboots, that would be best.
Otherwise, I would have to create a special condition to save /var/spool/cron

Anyway, we need to ask zigbert about this. Maybe he can bootup April or April64 and figure out what is wrong. I will send him a p.m.

greetings from illinois-land.
running Quirky April 7.0.2
am I the only one having problem with Gparted? tried two USB memory sticks to format as FAT32 appears to run process but failed with warning info {i didn't copy down, sorry..i will try it again}
however Ubuntu Trusty had no problem formatting both sticks..anyone else notice a problem?

Gparted..more info.error message:

"mlabel: error while loading shared libraries: libbsd.so.0: cannot open shared object file: No such file or directory"

bobtron wrote:greetings from illinois-land.
running Quirky April 7.0.2
am I the only one having problem with Gparted? tried two USB memory sticks to format as FAT32 appears to run process but failed with warning info {i didn't copy down, sorry..i will try it again}
however Ubuntu Trusty had no problem formatting both sticks..anyone else notice a problem?

I had no problem at all with USB sticks. They're all perfect. It's the hard drive install I'm stuck with. Things are missing and things don't work (hard drive only), and can't figure out where to get a LibreOffice that works with Quirky.

Coincidentally, I zapped the Quirky partition in favor of LxPupTahr 15.03.01, which is my second favorite OS, Quirky being #1! The LXPupTahr has the handy-dandy little "Get LibreOffice" thingy, so I could install immediately and get all my work done. I am running Quirky 6.1.4 on the other partitions still. Works like a million dollars. It is exciting reading the posts every day and watching Quirky develop. HOORAY!