Puppy Linux Discussion Forum

This is a regular repo2sfs third-party build like other Chromium-based browsers.

Run: repo2sfs Yandex.deb
At Pause B, run the script: yandex-guest-setup
Remember to make a "guest" user.

Youtube video/audio works fine.

Hint: Here is a way to make the Yandex desktop shortcut always show its logo:
Load the module.
Run: touch /opt/yandex/browser-beta/product_logo_48.png
Restart X.

This is a regular repo2sfs third-party build like other Chromium-based browsers.

Vivaldi needs the Widevine content decryption module (CDM) to view protected DRM content. I have packaged it here as a tarball, taken directly from the Google Chrome browser. Download and extract the file - it contains a folder named "google".

Get more info about Vivaldi and DRM here.

Run: repo2sfs vivaldi-stable_3.4.2066.106-1_amd64.deb

At Pause B, there are two steps:
a. Run the script: vivaldi-guest-setup
b. Go to /tmp/repo2sfs. Drop the "google" folder from above into the "opt" folder.

Remember to make a "guest" user.

On the first run of Vivaldi, you will get a message about playing H.264 content. The issue will be fixed on the next start.

To make the Vivaldi desktop shortcut always show its logo:
Load the module.
Run: touch /opt/vivaldi/product_logo_48.png
Restart X.

For testing purposes, run: vivaldi-guest

A note about downloading: because you are running Vivaldi as user "guest", downloaded files will go into /home/guest/Downloads. If this folder does not already exist, you must create it. The "Save file" dialog screen has a "Create folder" button for this purpose.

Or you could make the folder in advance with:

su guest -c "mkdir /home/guest/Downloads"

--------------

This is a Lenovo ThinkCentre M90p desktop box. It has a Core i3-530 chipset and 3GB RAM. Video is through standard VGA or optional DisplayPort (plus audio) to an HDMI monitor.

People started junking these big power-hungry Win7-era boxes years ago, but a few units are still around. This model can easily run Google Earth out of the Chrome browser.

As a test, I dropped the RAM down to 1GB. It could still play Youtube clips in Palemoon.

The boot process is through Legacy GRUB to a GPT hard drive. GPT is easy to set up on old machines because traditional BIOS doesn't care about the hard drive structure. With GPT, you can split off all the partitions you want to test other Linuxes.

-------------------

Update: I switched this system from Legacy GRUB to GRUB2 (see below). Now I can launch various BigBoy Linuxes directly out their ISO files as described in a previous post.

--------------------

I have posted here a new Buster Starter Kit ISO. It contains the latest Buster package updates combined with the k5.8.0-1 kernel from Sid. As with other recent Starter Kits, it can Porteus-boot off an emmc drive.

575c8697d8f3813b9e8dcb48ecad0121  DebLive_Buster-amd64-k5.8.0-1.iso

I have also built the matching combo WiFi pack which includes the always-troublesome Broadcom wl driver. If anyone wants it, please make a request.

This procedure can protect your Intel system against vulnerabilities like Spectre and Meltdown.

Note: These instructions are designed for systems with the GRUB2 bootloader. It does NOT work with Legacy GRUB. Based on limited testing, it appears to work with Grub4Dos.

1. Run: apt install intel-microcode

2. Run: iucode-tool -S --write-earlyfw=/tmp/intel-ucode.img /lib/firmware/intel-ucode

If your CPU is compatible, this will create the file /tmp/intel-ucode.img

3. Move the file to the "live" folder of your Buster install.

4. Open your GRUB menu and change the "initrd" line to load the file at bootup. For example:

initrd /buster64/live/intel-ucode.img /buster64/live/initrd1.xz

5. Reboot.

6. Check by running: dmesg | grep microcode

There should be a "microcode updated early" message.

7a. You can also download a Spectre-Meltdown-Checker tool:

wget --no-check-cert https://raw.githubusercontent.com/speed47/spectre-meltdown-checker/master/spectre-meltdown-checker.sh

7b. Run it with: sh spectre-meltdown-checker.sh

8. For more info, run: cat /sys/devices/system/cpu/vulnerabilities/*

=================

If you have an existing Legacy GRUB setup and want to use the above microcode procedure, converting to GRUB2 is easy.

1. Load your GRUB2 squashfs module.
2. Mount Partition sda1.
3. Run: grub-install --force --boot-directory=/mnt/sda1/boot /dev/sda
4. Using the Deblive Multi Installer's GRUB2 section, convert your Legacy GRUB menu.lst file to grub2.txt.
5. Rename grub2.txt as grub.cfg (it should be in the folder /boot/grub)
6. Reboot.

Great info, thanks!

This is a regular third-party build with a setup script and guest user.

Run: repo2sfs freetube_0.9.2_amd64.deb
Include the extra package: libnss3
At Pause B, run the script: freetube-guest-setup
Remember to make a "guest" user.

To make the FreeTube desktop shortcut always show its logo:
Load the module.
Run: touch /usr/share/pixmaps/freetube.png
Restart X.

For testing purposes, run: freetube-guest

-----------------

The instructions here still apply, but the latest v5.4.3 requires a change.

You must now include TWO extra packages: libxkbcommon-x11-0 libnss3

Remember to create the "guest" user.

For testing purposes, run: zoom-guest

I have only run v5.4.3 as far as the login screen.

While Pup/Dog people continue to use Grub4Dos and MBR drives, the mainstream Linux world has moved ahead with GPT partitioning and GRUB2.

The following instructions describe a system where your hard drive is structured as GPT. You can have many "primary" partitions without resorting to an extended partition. The bootloader is GRUB2, which gives you the most flexibility.

Note: This discussion only applies to regular BIOS-based machines. It does NOT apply to Win8+ UEFI-based machines. Linux on UEFI uses the GRUB2 bootloader as part of its EFI package and the hard drive will probably be GPT. See the discussion below.

1. Because the Starter Kit ISO does not contain GRUB2, you will need to get it separately. You can download a squashfs module from here or build your own module from the Debian package "grub2" using apt2sfs.

2. Since you are building the target hard drive from scratch (and erasing all old content), you will need a bootable flash drive. Copy the GRUB2 module and the Deblive Multi Installer onto the drive.

3. Boot the target system off the flash drive.

4a. Run Gparted and select the hard drive.
4b. Open the Device tab and create a new partition table. Select GPT.
4c. If necessary, reboot now off the flash drive so your system is aware of the changes to the hard drive.

5a. Create your new partition structure. Partition #1 should be a small (2GB) ext3 "boot" partition. It will have the GRUB Stage1 boot code on the MBR (GPT systems allow this because they don't use the first sector of the drive) and a /boot/grub folder with the Stage2 content. Your grub.cfg file will eventually go here.
5b. Create more partitions to hold your OS installs and other data. You don't need to completely partition the drive now - you can leave empty space on the drive and partition it in the future as needed.

6a. Right-click on the GRUB2 squashfs module and activate it.
6b. Run the Multi Installer and open the GRUB2 section. Select the Stage1 target as "sda" and the Stage2 partition as "sda1".
6c. Click Install.

7. Install some Dogs/Pups into other partitions - the Installer works for both. Paste the grubmenu.txt boot code it into the grub.cfg file in /boot/grub.

8. Reboot off the hard drive.

9. Here is a variation. Assign a partition to hold a collection of Pup/Dog installs. Collect the individual GRUB2 menu entries into one "combo" file and put it at the root of the partition. Boot it from sda1 using the "configfile" command. Note that in GRUB2, partitions are numbered starting at 1. For example:

menuentry "Various installs on sda5" {
	set root=(hd0,5)
	configfile /combo-grub.cfg
}

Now your Pup/Dog partition is self-contained.

10. But what about the big-boy Linuxes like Ubuntu? Their installers should let you put their GRUB2 bootloader on the installation's partition boot sector, where it won't interfere with your own GRUB. Format the target partition as ext3 to avoid the potential "64bit ext4" issue. Set the mount point as "/". Then boot it from your primary GRUB menu by chainloading.

menuentry "Ubuntu on sda7" {
	set root=(hd0,7)
	chainloader +1
}

11. If a big-boy Linux insists on booting off the MBR, you can use its 40_custom GRUB2 setup file to run your own Pup/Dogs using the method from Step 9 above. Read here for details.

Update: Instead of using the internal 40_custom GRUB file, you may be able to use the external file /boot/grub/custom.cfg

12. If a big-boy Linux blows away your own GRUB, you can sometimes take back control by booting off a flash drive and reinstalling GRUB. Then boot the big-boy Linux with a menu entry like:

menuentry "Mint 19 on sda3" {
  set root=(hd0,3)
  linux /vmlinuz root=/dev/sda3
  initrd /initrd.img
}

or

menuentry "MX on sda6" {
  set root=(hd0,6)
  configfile /boot/grub/grub.cfg
}

or the "traditional" full-install syntax:

menuentry "Salix on sda5" {
  set root=(hd0,5)
  linux /boot/vmlinuz root=/dev/sda5 ro vga=normal
}

13. Regarding Windows: If you have a pre-Win8 machine or a Win8+ machine in legacy mode, you can probably multi-boot it with GRUB2. The safest way is to leave the DOS/Win MBR in place, flag a Linux partition as bootable in Gparted and put GRUB2 on that partition's PBS. Make the Stage1 target "sdax" and the Stage2 partition "sdax". Then boot Windows from the GRUB2 menu by chainloading. Adjust the partition number as required:

menuentry "Windows" {
	set root=(hd0,1)
	chainloader +1
}

Hint: If necessary, you can restore a Windows MBR with:

apt-get install ms-sys
ms-sys -7 -w /dev/sda

---------------

The original instructions 1-4 here (post #108) for putting Linux on a Windows/UEFI system still apply, particularly about disabling hibernation. We will assume for the moment that you have turned Secure Boot OFF.

Hint: If you plan to dual-boot with Windows, you will need to split off a new partition for Linux. Recent versions of Windows can do this using their own Disk Management tools.

You should start with a general-purpose UEFI-bootable flash drive like ISObooter. It will contain an EFI folder that has bootloader code based on GRUB2. It uses a grub.cfg menu file instead of the Grub4Dos menu.lst.

Once you have the flash drive working, you can transfer the setup to your hard drive. You simply need a FAT32 partition on the hard drive with the same EFI folder as your flash drive. This is your "EFI System Partition" or ESP. There is no need to write anything onto the Master Boot Record of the drive.

Run the Deblive Multi Installer and install the Starter Kit (or other compatible OS's) onto other partitions of the hard drive. Add the GRUB2 boot code to your grub.cfg file in /EFI/grub.

Reboot off the hard drive.

If you want to keep Windows and dual-boot, see the instructions here (post #281). The quick and dirty way is to rename the original EFI folder in the ESP so your own EFI folder gets used at bootup instead of the Windows version. Notice that in this situation, the "chainloader" command references a ".efi" file, not a target partition.

Update: See the discussion here about using the efibootmgr tool to dual-boot with Windows. This is the preferred method in a UEFI setup.

------------------------------

But what if you want to leave Secure Boot turned ON? On an old BIOS system, the boot process starts when the BIOS executes some code located in the Master Boot Record in the first sector of the hard drive. Any malware that replaces that code has taken control of your system. BTW, that's EXACTLY what the various forms of GRUB do! They replace the standard DOS/WIN code in the MBR with their own Stage1 code.

The problem with a BIOS system is that it lacks tools for protecting its own MBR. This is the idea behind UEFI and Secure Boot. A UEFI system ignores the MBR, jumps directly to the ESP and runs the code in the EFI folder. This eliminates the traditional point of attack. To secure a UEFI system even further, you can "password-protect" those EFI files. The passwords or "keys" are stored inside the UEFI firmware on the computer. Only someone with physical access to the computer can boot into "UEFI firmware mode" and modify keys. This means that malware could try to drop new EFI content into your hard drive, but it would never boot without the required keys. Moreover, Windows password-protects (digitally signs) various critical system files to protect them from attack.

To make the Starter Kit work on a Secure Boot computer, you need a custom set of EFI files and a matching "certificate" file that contains a key. Your ISObooter3 flash drive already has these files, based on this project.

1. Boot the target computer off the flash drive. It will detect a verification error and stop.
2. You will then get some key management screens with an option to "Enroll key from disk".
3. This will display a list of available drives - pick the one identified as USB.
4. Select the file ENROLL_THIS_KEY_IN_MOKMANAGER.cer from the USB drive.
5. Enroll the key and reboot

Once you can successfully boot off the flash drive, transfer its EFI folder to the hard drive and boot off it.

Notes:
1. If you turn Secure Boot OFF, this EFI setup will still work.
2. On some machines, it may be easier to use this system than trying to disable Secure Boot.
3. Your UEFI flash drive can simultaneously be Grub4Dos-bootable, since UEFI doesn't care that G4D put its own bootloader on the MBR.
4. See the next post for more info about Secure Boot.

----------------------

For people who want to dive deeper into the mysteries of Secure Boot, here are more details.

Secure Boot is based on a "chain of trust". Before one module in the boot sequence can trust the next module to run safely, it must ensure that the second module has a verifiable signature. If not, the boot sequence halts.

When that happens, you may be allowed to provide a Machine Owner Key that verifies the second module. If the key works, it will be registered in the UEFI firmware, so bootup can proceed smoothly the next time.

The EFI folder discussed above contains a chain of several modules:

bootx64.efi: This module is a "shim". It is the first link in the chain because its code is signed by Microsoft. Since Secure Boot is a Microsoft product, the first module that the UEFI firmware runs must have the Microsoft signature in order to be trusted. Without it, UEFI will report that the system is unbootable.

grubx64.efi: This is not actually GRUB - it is a GRUB "preloader". Its job is to break this "chain of paranoia" and allow subsequent modules to run without verification, like GRUB.

grubx64_real.efi: This is the GRUB2 bootloader. It can now ignore the state of Secure Boot and load a Linux kernel, signed or not.

To make all this work, an extra key is needed. The MOK Manager will jump in and let you select the certificate file that contains the key.

Note: The Starter Kit uses a signed kernel. Even though it bypasses some Secure Boot controls to get started, it expects that all its drivers will be signed too. So it will refuse to load the third-party drivers from the combo-wifi-driver-pack. To run them, you must turn Secure Boot OFF.

.

Hi @rcrsn51

Question

• Could Peasy LAN scanner be upgraded to show the hostnames with the IPs if finds?

Thanks for consideration(s)

Clarity wrote: Mon Dec 07, 2020 4:42 pm

Could Peasy LAN scanner be upgraded to show the hostnames with the IPs if finds?

Under what conditions does a machine broadcast its hostname across the network?

LAN registration is one example.

But, if I interpret your response looking at it one way, it could mean that the Peasy LAN Scanner cannot be made to do such.

I was just looking for a way to associate a resource's hostname with its IP-MAC when doing a scan on the LAN.
Thanks

This is an old Acer Aspire AX1800E SFF desktop box. The original configuration was Vista with a Pentium E2210 CPU. After being upgraded to a Core2Duo and 4GB RAM, it became a decent everyday machine.

But there's a problem with the integrated NVIDIA GeForce 7100 graphics - Debian has been gradually dropping support for many old video cards. With the Buster Starter kit and k4.19.0, the nouveau driver was flaky. Under k5.8.0, it was completely broken and there was no way to install the Xorg nvidia driver. So some alternative was needed to make the machine functional.

1. Fall back to VESA. This is always a last-ditch solution because VESA lacks a resolution for wide-screen monitors.

2. Use the Xorg framebuffer driver. This is an OK solution - I have framebuffer packaged as a squashfs module that I can drop into the "live" folder of the install. But it occasionally had problems.

3. Install a PCI-e Radeon graphics card, provided that you can shoe-horn the card into the SFF box without breaking anything. This is also an OK solution, except that my old Radeon card sometimes misbehaves.

4. Switch to the Stretch Starter Kit.

This ended up being the stable solution. The nouveau driver in Stretch still fully supports this NVIDIA card. There is lots of software available for Stretch, like the latest Firefox installed from the vendor package. To view DRM content in Firefox, you need libavcodec57, but you can get it from the Stretch repo.

The Acer boots up via GRUB2 installed on the PBS of the Linux partition.

For test purposes, I am handling squashfs modules with my custom version of loadmodule that uses symlinks instead of aufs layers. It is working fine, albeit a bit slower than with aufs.

Update: The final solution is Buster k5.8.0 with framebuffer. This is completely stable.

-----------------

Hi @rcrsn51

Question:
Where can I find the kernel headers for 5.8.0-1-amd64?
I need them to build the Virtualbox module.

Thanks.

galbi wrote: Sat Dec 12, 2020 3:29 pm

Where can I find the kernel headers for 5.8.0-1-amd64?

This was tricky because my 5.8.0 kernel setup originally came from fred's build out of Debian Sid, and Sid doesn't keep old kernels around.

I eventually found the kernel header stuff here. You will also need the "common" package and a "kbuild" package. But when you try to load these packages, they will want gcc-10, so you will need to get it out of Sid.

rcrsn51 wrote: Sat Dec 12, 2020 3:44 pm

galbi wrote: Sat Dec 12, 2020 3:29 pm

Where can I find the kernel headers for 5.8.0-1-amd64?

This was tricky because my 5.8.0 kernel setup originally came from fred's build out of Debian Sid, and Sid doesn't keep old kernels around.

I eventually found the kernel header stuff here. You will also need the "common" package and a "kbuild" package. But when you try to load these packages, they will want gcc-10, so you will need to get it out of Sid.

Tricky, to say the least, all together, I think it's close to impossible to get things right with the Sid kernel, that's why using a newer kernel from buster-backports is better (it does keep older kernels and linux-headers packages in repo), here's 5.8 backports kernel for 64-bit (5.8 is the last for now that I could use dkms to build aufs kernel module, not possible for 5.9, aufs development is on hold):
https://github.com/DebianDog/BusterDog/ ... d64.tar.gz
Enable the buster-backports repo to be able to install the corresponding linux-headers, kbuild etc.. versions:

echo -e "deb http://deb.debian.org/debian/ buster-backports main contrib non-free" > /etc/apt/sources.list.d/bports.list

EDIT: Or (may be better, reading below post from rcrsn51) add buster-backports repo line to /etc/apt/sources.list:

echo -e "deb http://deb.debian.org/debian/ buster-backports main contrib non-free" >> /etc/apt/sources.list

Fred

Thanks Fred - that's a lot easier than my way! Here are two thoughts.

I like to build a "mini-devx" squashfs module using apt2sfs from the packages linux-headers-xxxxx and make. That's enough to compile most WiFi kernel modules. But when I used "sources.list.d/bports.list", apt2sfs couldn't find the linux-headers package. So I used the regular "sources.list" instead and that worked.

I want to build drivers for Sid k5.8.0-1 but this kernel headers package is for k5.8.0-0. Luckily, you can go into /lib/modules, get the "build" and "source" links from 5.8.0-0.bpo.2-amd64 and copy them into 5.8.0-1-amd64. Now you can compile for the desired target.

This is v2.1 of My Squash Loader from here. Most of the original details still apply.

V2.1 contains its own copy of the loadmodule tool which is based on symlinking. Note the special instructions for installing new packages into your system (via apt/synaptic) while squashfs modules are currently loaded.

This version also has a command-line mode. Run it in the folder where a module is located. Hint: use Tab completion.

loadmodule -a module_name.squashfs: load (activate) a module.

loadmodule -d module_name.squashfs: unload (deactivate) a module.

loadmodule -s module_name.squashfs: shrink the file module_name.txt in /etc/SQUASHFS. The initial module_name.txt contains a complete list of every file/folder in the squashfs module. The "shrunk" version lists just the key files that are required to link the module into your filesystem. This speeds up activation.

loadmodule -r module_name.squashfs: restore the original module_name.txt. Use this if you install new files into your system that duplicate those in a module. Then run "loadmodule -s" to generate a new .txt file.

Hint: Some of your squashfs modules may have overlapping content. For example, my Vivaldi and Google Earth Pro modules both use the folder /opt/google. This can cause problems if you try to load them together.

The easy solution is to create the duplicated folder as part of your filesystem (mkdir /opt/google). Then the modules can co-exist when loaded. Run "-r" and "-s" to configure the modules against the updated filesystem.

Hint: A module may contain a bunch of optional content, like locale files. You can delete them from the .txt file in /etc/SQUASHFS to speed up activation. Note: ONLY do this while the module is UNloaded.

-------------------

rcrsn51 wrote: Wed Dec 23, 2020 3:22 pm

This is v2.1 of My Squash Loader from here. Most of the original details still apply.

/snip
-------------------

I installed this on Debian Dog Stretch and used it tonight. It seems to perform correctly in all respects.

This is PeasyPort v3.2 with a new Names tool. It identifies all machines on the subnet that are broadcasting a NETBIOS name, like Samba servers.

@dancytron: Thanks for testing.

I threw together a system that combines an 01-filesystem.squashfs from Buster with Fred's experimental k5.10.0-rc6 (non-aufs) kernel.

It works fine. It can auto-load squashfs modules at bootup from the "live" folder and load-on-the-fly with my-squash-loader.

Once you "shrink" a module, activation is quite fast.

Bill

rcrsn51 wrote: Thu Dec 24, 2020 5:44 pm

@dancytron: Thanks for testing.

I threw together a system that combines an 01-filesystem.squashfs from Buster with Fred's experimental k5.10.0-rc6 (non-aufs) kernel.

It works fine. It can auto-load squashfs modules at bootup from the "live" folder and load-on-the-fly with my-squash-loader.

Once you "small-ify" a module, activation is quite fast.

Bill

It seems to have broken the old "right click" method of loading sfs's, but that's okay. When I get a chance to figure out what to delete to clean it up so the non-working right click choices aren't there anymore, I'll add it to this post.

Right-clicking to load a module still works.

Right-clicking sends a squashfs module to the loadmodule command using "loadmodule -a".

This invokes the new version of loadmodule provided by my-squash-loader.

My bad.

It is the "Load Module (Safe Mode)" that doesn't work.

This is the /root/.local/share/file-manager/actions/activate-safe.desktop file:

[Desktop Entry]
Type=Action
Tooltip=Activate module (safe mode)
Name=Activate module (safe mode)
Profiles=profile-zero;
Icon=application-x-xzm

[X-Action-Profile profile-zero]
MimeTypes=application/x-squashfs;
Exec=loadmodule -ano %f
Name=Default profile

I don't have a Buster version to look at right now.

I tested both with right click and running from the console.

root@ChromeDog64:~# loadmodule -ano /live/image/StretchSquashFS/AlmostEmptyTest.squashfs

Does safe mode make sense anymore with links and needing to unload to update? Seems it's really a feature rather than a bug.

[/quote]

dancytron wrote: Fri Dec 25, 2020 9:12 pm

It is the "Load Module (Safe Mode)" that doesn't work.

Correct. My loadmodule does not recognize "-ano" as an option. I never fully understood this option, but I think that it determines whether a new aufs layer can take precedence over existing layers.

That no longer applies here. The rule for symlinking is that a new symlink will not replace an existing one.

rcrsn51 wrote: Sat Dec 26, 2020 12:56 am

dancytron wrote: Fri Dec 25, 2020 9:12 pm

It is the "Load Module (Safe Mode)" that doesn't work.

Correct. My loadmodule does not recognize "-ano" as an option. I never fully understood this option, but I think that it determines whether a new aufs layer can take precedence over existing layers.

That no longer applies here. The rule for symlinking is that a new symlink will not replace an existing one.

That makes sense since it is symlinking.

I've always thought the difference with "safe mode" was where the layer was mounted in the "stack", either above or below main 01-filesystem file.

I'll continue to use this on my day to day DD stretch to give it a good testing.

This is a recycled Actineon 8LP industrial box. It has a Celeron J1900 SoC, 4GB RAM, a 32GB mSATA drive and ZERO fans.

The firmware is UEFI and can boot two ways - in Legacy Mode with GRUB2 on the MBR or with UEFI from an ESP. I also enabled Secure Boot just to confirm that it is easy to do.

The OS is Buster64 Starter Kit combined with the 5.10.0-trunk-amd64 kernel from Debian Experimental. This is a non-aufs setup and uses my-squash-loader for on-the-fly module activation.

Audio is through the analog LineOut port or digital HDMI. As a 100% silent unit, it produces the best quality sound I have ever pushed out of a computer.

Like many UEFI systems, this one has a quirk - Legacy Mode won't recognize a GPT drive. Traditional BIOS sytems definitely work with GPT, so this must be a design decision by the firmware vendor.