Puppy Linux Discussion Forum

I do not have a file/directory named ucode.cpio in my Voidpup64 22.02.-20241009 (kernel 6.6.53)

N97 wrote: Mon Jan 06, 2025 10:15 pm

I do not have a file/directory named ucode.cpio in my Voidpup64 22.02.-20241009 (kernel 6.6.53)

viewtopic.php?p=9658#p9658

N97 wrote: Mon Jan 06, 2025 5:46 pm

Voidpup64-22.02 has some bugs and omissions that need fixing...

1.) the grub cfg file needs 'insmod fat32'

N97

Thinking about this more - I am wondering why you are the first user to discover this "omission" given that people must have been booting woof-ce pups with grub successfully???

How did you discover this was needed? how were you booting VoidPup64?

I might be wrong about fat32 inclusion... i was booting using boot flash --> Grub/GPT UEFI. The os did not run at all. Thats when I noticed that grub.cfg and the boot folder were not transferred to target usb drive from the iso. the insmod fat32 was insurance that the transfer was successful... to no avail apparantly. I left it in my build JIC.

FWIW the computer is x86_64.

Given the rolling release, it would be helpful if the 'packages-void-current' file is made available as a separate download. This helps end-users with an older version update to the 'correct' available app version. Its not necessary to D/L the iso and burn/boot it to get this info. Right now... it is.

Thanx
N97

N97 wrote: Tue Jan 28, 2025 2:43 pm

Given the rolling release, it would be helpful if the 'packages-void-current' file is made available as a separate download. This helps end-users with an older version update to the 'correct' available app version. Its not necessary to D/L the iso and burn/boot it to get this info. Right now... it is.

Thanx
N97

Not sure this is a good idea - much better to update all system components to be consistent..... and this would make PPM inconsistent with VPM....

If you do want to do it - download the iso and open it - then open the puppy.sfs and copy from /var/packages - but then why not update all the .sfs??

Going back to the bootflash --> GPT/GRUB install bug...
I also tried the Frugal Pup installer e3stickpup. It makes a boot partition, then an ext drive. But wait, there's more...
THEY'RE LOCKED !!! Puppy Jail.

So, theres two BAD options, Broken, or Jail.

NONE suits me. So I did it the old-fashioned way, and now i have a boot partition, an os partition, and a storage partition.
They work great, with usual caveat that its wise to keep a copy of the storage partition on another drive JIC chip fail.
Also periodically update the save file in any/all copies.

To top it off, thrown for a loop when the fiberoptic system went down locally... high wind culprit. A call to ISP revealed snafu. whew... thought i failed.

As far as the vpm current file... because not broken, no update. But if an app fails, update the app/dependencies. If theres a security snafu, update the app/dependencies. Further infestation warrants new os version.
It reminds me of diabetics, when the toe gets gangrene, we cut off the foot, not the whole leg.

Updated my frugal VoidPup64 install to SSD on one my all intel Fujitsu U747 (6nd gen i5, Sandylake) (pretty hooked on these now, count up to 4 monday ) from the 250101 version to the 250201 version.

Using my @peebee derived LXDE ydrive plus customizations so no JWM checks unless requested. Adrive not used as usual. Running overlayfs at the moment. ydrives (adrive in NoblePup64) now 'universalized' so that for a given pup 4 flavours of touchpad and 3 display resolutions & dpi are set up correctly by machine type in a model customization script in /root/Startup.

Booted both with the supplied 6.6.71 kernel and with the 6.12.3. Currently running with that though the 6th gen i5 (skylake) laptops seem to have no lidsuspend bugs. A little more time with the new intel_pstate suspend paradigm. Subjectively, it's much more power conserving than the old S3 was. The Lenovo X1 carbon in particular can sit with a suspended pup for days with a very few % of battery charge loss.

microcode updates early from a shared ucode with the following in the initrd line in the menu.lst entry: /microcode/ucode.cpio. I use the most recent ucode I have and the U747s update, The X1 carbon does not as I updated its' UEFI and that is current re mitigation or at least the kernels accept it as so.

Clean dmesg with NO fails or warnings. Excellent idle resource use, all portables and lidsuspend continue to work normally., Just checked, 'intel' display driver in use by default, performance 'feels' snappy.

Posting in that install from the portable Brave, updated to the current version, now.

Thanks & Cheers,