S15Pup - Discussion

[wizard]

@peebee

Hi peebee,
Thought you might find this info useful. When testing and debuging boot errors for F96-CE, Rufus (MS Windows) and Unetbootin were chosen as the USB installers we wanted to validate and recommend.

Two of the issues we found:
1. Unetbootin could not make a UEFI USB
2. Both Rufus & Unetbootin USB's generated a "Pausing for 60 seconds" error when booted on UEFI systems.

Comparison test with S15 were the same.

Issue 1
Different installers use different techniques. When Rufus, Frugalpup, Stickpup and Grub2config make a UEFI USB they install their own copies of the EFI files, Unetbootin does not. Unetbootin can only make a UEFI USB when the EFI files are already in the ISO.
Fix: include the EFI directory & files in / of the ISO.

Issue 2
This was caused by the default grub menu specifying pmedia=cd.
Fix: change default to pmedia=usbflash and supply a sub-menu for cd/dvd booting that specifies pmedia=cd

usbmenu.jpg (12.23 KiB) Viewed 4327 times

When the two fixes were implmented, both Rufus and Unetbootin could produce a UEFI/MBR hybrid USB that booted without errors. Also, a UEFI/MBR hybrid CD/DVD could be burned that booted and ran correctly.

I've attached the grub menu files that were used, should be placed in /boot/grub and copy of grub.cfg put in /

Thanks
wizard

[peebee]

Hi @wizard

If there is something needs changing to the .iso format this would need to be raised with a clear explanation as an issue on GitHub - WoofCE - I just take what Woof-CE provides....

Thanks
PeeBee

[yolhurt]

Whenever I open Sylpheed in S15Pup, this "app innit done" box pops up in the bottom right hand corner of the screen and displays for a few seconds. This is slightly annoying as it covers my taskbar icon showing whether I have any new mail. There doesn't seem to be any way to stop this box appearing, short of installing a different version of Sylpheed.

[Marv]

@yolhurt , Try the following:

Navigate to /usr/lib/sylpheed/plugins/. Rename test.so there (I use test.so_hide) to 'hide' it. Save (we'll assume you're using a savefile or folder) and reboot. That popup should be gone.

[yolhurt]

@yolhurt , Try the following:

Navigate to /usr/lib/sylpheed/plugins/. Rename test.so there (I use test.so_hide) to 'hide' it. Save (we'll assume you're using a savefile or folder) and reboot. That popup should be gone.

That has worked, thanks!

[gyrog]

I hope this issue has not been addressed already.

In rc.sysinit, 2 containers get mounted when pupmode != 2.
When I boot an s15pup using aufs, these containers get umounted before rc.shutdown.
When I boot an s15pup using overlayfs, these containers get umounted by rc.shutdown as strays.
When I boot upupjj32 using overlayfs, these containers get umounted before rc.shutdown.

Why is it so?

Note1: It does not matter if it's s15pup32 or s15pup64.
Note2: rc.shutdown still works fine in either situation.

[peebee]

in /root/Startup/1-s15pup-startup.sh :

fstype=`df -T | grep aufs`
if [ ! "$fstype" = "" ]; then
umount /var/lib/containers
umount /home/spot/.local/share/containers
fi

however in /root/Startup/1-upup-startup.sh unconditional :

umount /var/lib/containers
umount /home/spot/.local/share/containers

Which is "correct" - only AUFS or unconditional?

[gyrog]

Which is "correct" - only AUFS or unconditional?

I prefer the upup version, i.e. unconditional, but then I don't know what these containers are for.

Thanks for the explanation, I could "fix" the s15pup's now.

So, can anyone enlighten us as to what these containers are used for?
And when are they needed?

[peebee]

Which is "correct" - only AUFS or unconditional?

I prefer the upup version, i.e. unconditional, but then I don't know what these containers are for.

Thanks for the explanation, I could "fix" the s15pup's now.

So, can anyone enlighten us as to what these containers are used for?
And when are they needed?

@dimkr is the "author"
https://github.com/puppylinux-woof-CE/w ... ssues/3084
https://github.com/puppylinux-woof-CE/woof-CE/pull/3044

[dimkr]

So, can anyone enlighten us as to what these containers are used for?
And when are they needed?

These two bind mounts are needed to make podman, buildah and other container-related tools work. They use overlay and don't work if the container's upper layer is also overlay (feel free to try this or come up with a different solution).

I think that supporting containers in Puppy is important for 4 reasons:
1. Tools like distrobox use containers
2. Containers are a common development tool - if Puppy is not a good OS to develop or learn programming on, it's a less versatile distro and a distro many user's don't need
3. If developers can't use Puppy, it will be much harder to get more skilled contributors
4. Containers are useful for Puppy development - when I need to test something on another distro or run woof-CE securely, I just podman run --rm -it distro

Do you see any problem with having those two bind mounts?

@dimkr is the "author"

What do the quotes mean? Did I steal this code from somebody else?

https://github.com/puppylinux-woof-CE/w ... ssues/3084
https://github.com/puppylinux-woof-CE/woof-CE/pull/3044

+ https://github.com/puppylinux-woof-CE/w ... ssues/3042
+ https://github.com/puppylinux-woof-CE/w ... ssues/3043

[gyrog]

Do you see any problem with having those two bind mounts?

Yes, there's code to mount them, why is there no code to umount them?
Should they be mounted and umounted in an 'init.d' script?

And just to be clear; do they work well when overlayfs is used for the frugal Puppy stack?

[dimkr]

These are bind mounts, pup_rw can still be changed to ro without unmounting them. And umount -a in rc.shutdown unmounts them, no?

[ozsouth]

@dimkr - they are unmounted at exit as "stray filesystems" - if using overlayfs. Is untidy, but works.
Script @peebee mentioned probably should be unconditional, not aufs only.

[gyrog]

These are bind mounts, pup_rw can still be changed to ro without unmounting them.

Not the issue.

And umount -a in rc.shutdown unmounts them, no?

No, as stated by @ozsouth, they are umounted as "stray's".
I see this code as a last ditch cleanup for things I have mounted but forgotten to umount.
Things that are deliberately mounted, should be deliberately umounted.

[dimkr]

But these are bind mounts to pup_rw (which isn't unmounted anyway, because it's busy, since it's a layer of /). I don't see how bind mounts to pup_rw make any difference.

Are you sure that explicitly unmounting these bind mounts makes any difference at all?

[ozsouth]

umount -a in rc.shutdown unmounts them, no?

@dimkr - I am using s15pup64-22.12+3. umount -a refs in rc.shutdown explicitly exclude overlayfs.
Hence the stray umounts are actioned in the last few lines of rc.shutdown , via umount-FULL command.
Doesn't seem to affect operation of savefolder & change (unconditional umount in Startup) I suggested
earlier may cause other issues (other process termination), so I'll just accept it as is.

[gyrog]

I find these messages distracting and annoying.
Since I intend to use the s15pup's frequently. I will edit '/root/Startup/1-s15pup-startup.sh' so it works like upupjj32.

[dimkr]

Which messages? Those in rc.shutdown?

[gyrog]

Which messages? Those in rc.shutdown?

The ones produced by rc.shutdown for umounting stray filesystems, which the "containers" are not.

I have finally silenced the s15pup shutdown.
In the end I did not edit the '/root/Startup/1-s15pup-startup.sh' file.
Nor did I use a script in '/etc/init.d', although I tried that.

I have attached a patched version of 'rc.shutdown', a replacement for '/etc/rc.d/rc.shutdown'.
With this in place, my s15pup's do not show any problem messages on shutdown, nor does my upupjj32.

The patch involves added code to manually umount the "containers" mounts, before stray filesystem processing.
And a fix to the search for an 'sh' process.

This 'rc.shutdown' also includes an overlayfs patch to improve the chance of a sucessful shutdown, this patch is already in woof-ce.

Note: Your original 'rc.shutdown' is still available in your 'puppy...sfs'.

EDIT: I've removed the attachment, it seems to have contained a rubbish rc.shutdown
I'm workinng on a replacement.

[dimkr]

What's the purpose of these warnings?

Maybe the proper fix is not to write those warnings when the "stray file system" is a bind mount and not a real mount (i.e. a partition), because these leftover bind mounts are harmless. The user has nothing to do with these warnings.

[gyrog]

Maybe the proper fix is not to write those warnings when the "stray file system" is a bind mount and not a real mount (i.e. a partition), because these leftover bind mounts are harmless. The user has nothing to do with these warnings.

My rc.shutdown uses the crude method of umounting them to avoid the "stray file system" warning messages.
Omitting them from the list would be more elegant, since they are harmless.

[gyrog]

@dimkr,
How would I detect that it's a bind mount?
The only evidence I see in /proc/mounts is the presence of a real mount earlier in the file.

[dimkr]

@gyrog /proc/self/mountinfo shows which mounts are bind mounts, and bind mounts of which path

[gyrog]

@dimkr,
I will look at that, but I also found a utility 'findmnt'.

Code: Select all

# findmnt -n /initrd/mnt/sdc2 | grep "\["
# findmnt -n /var/lib/containers | grep "\["
/var/lib/containers /dev/sdc2[/psaves/s15pup64/s15pup64save/var/lib/containers] ext4   rw,noatime
#

Running on s15pup64.

[gyrog]

@dimkr,
The followinng also works.

Code: Select all

# grep '/initrd/mnt/sdc2' /proc/self/mountinfo | grep 'shared'
# grep '/var/lib/containers' /proc/self/mountinfo | grep 'shared'
45 40 8:34 /psaves/s15pup64/s15pup64save/var/lib/containers /var/lib/containers rw,noatime shared:2 - ext4 /dev/sdc2 rw
# 

[dimkr]

@gyrog I don't think it's so important to check if the bind mounts exist before you unmount them. The computer won't explode if you try to unmount a non-existing bind mount, and checking if they exist is just a waste of time.

The easiest (and most efficient) fix is just adding these two lines to rc.shutdown, without any cat or grep:

Code: Select all

umount -l /var/lib/containers 2>/dev/null
umount -l /home/spot/.local/share/containers 2>/dev/null

[gyrog]

I expect to have a new rc.shutdown available tomorrow. It will implement @dimkr's suggestion.

[gyrog]

This is significant for both the s15pup's, and upupjj32, and their misleading warning messages during shutdown.

I've attached 'ydrv_rc_shutdown.sfs' that contains an 'rc.shutdown' that removes some misleading warning messages on during shutdown.

Use:
Download both 'ydrv_rc_shutdown.sfs' and 'ydrv_rc_shutdown.sfs.md5.gz'.
Rename 'ydrv_rc_shutdown.sfs.md5.gz' to 'ydrv_rc_shutdown.sfs.md5', and run

Code: Select all

md5sum -c ydrv_rc_shutdown.sfs.md5

To install in s15pup54:
Move 'ydrv_rc_shutdown.sfs' to the install directory.
If the install directory is on a Linux partition, you can:

Code: Select all

ls -sf ydrv_rc_shutdown.sfs ydrv_s15pup64_22.12.sfs

otherwise

Code: Select all

mv ydrv_rc_shutdown.sfs ydrv_s15pup64_22.12.sfs

There are 2 parts to the fix:
1) Unmount the "containers" directories that were mounted in 'rc.sysinit',
(removes the "Unmounting stray filesystems:" messages).
2) Fix a bug in the "Killing process" code where it failed to ommit a "sh" process because it was looking for a "-sh" process.
(removes a "Killing process 9999... " message.

Note1: Applying only part 1) results in the "Killing process" message because the relevant process was quietly killed by the "Unmounting stray filesystems:" code.
It does not matter if the relevant process gets killed or not.

Note 2: None of this makes any difference to the reliability of the shutdown.
It's all about Puppy not producing misleading warning messages during a normal working situation.

Note3: I've uploaded the actual ".sfs" file that I am using in my desktop computer.

ydrv_rc_shutdown.sfs

(8 KiB) Downloaded 69 times

ydrv_rc_shutdown.sfs.md5.gz

rename without fake ".gz"

(55 Bytes) Downloaded 80 times

[8Geee]

I tried the +1 version on my Atom N270 2Gb. The CD loaded and ran properly altho with painfully slow touchpad defaults. Of course I can't tweak the OS as a one-burn session. I could go multi-burn to fix what I want.

However, when using Puppy installer (for non-PAE, which the N270 is) the bootup broke, generally with errors pointing to "the kernel must have a path". Chainloader, and kernel options failed. Grub is presumed to be 046 or 046a. Is it possible that some files DID NOT transfer using burniso2cd? The USB stick is a Sandisk 8Gb USB2.0. These have never been a problem booting puppy for several years. Is the distro PAE ONLY?

Thanks and regards
8Geee

PS: BTW... this might be good for ARM MPU's (esp RK3599 64-bit for Orange Pi 4 LTS)

Well, not having any success, I tossed it in favor of 7.0-32bit. That is until today... Today I tried again, and I found the culprit behind the new 22.12 version. Yes, it boots to CD and runs just fine. Yes, puppy installer works just fine and the OS gets copied over to the USB-stubby. But NOOOOOO, it wouldn't boot from the stubby. How can that be??? Well it turns out that its quite possible BECAUSE the Kernel GOT PUT INTO THE Z-DRIVE.SFS. And the light browser is in the A-DRIVE. So... toss the adrv.sfs and rename the zdrv to adrv, and bligh me its limey and loads. I tthen put FF78.15esr into root and Bob's my uncle.

So, maybe a careful reordering of things sfs is "in order" so to speak.

Regards
8Geee

[peebee]

BECAUSE the Kernel GOT PUT INTO THE Z-DRIVE.SFS. And the light browser is in the A-DRIVE. So... toss the adrv.sfs and rename the zdrv to adrv, and bligh me its limey and loads.
8Geee

Sorry - don't understand - that's exactly how it is supposed to be be - zdrv is the kernel; adrv is for other apps.....