Puppy Linux Discussion Forum

Clarity wrote: ↑Thu Jul 28, 2022 7:44 pm

Thanks @mistfire

Since I've never needed to specify 'ver=' for any PUP to connect to any PUP which is sharing a folder, could this be a new requirement? Or is there something else happening. I tried the other PUPs I have running to the same LAN to FossaPUP which is sharing and no need. So, this could be something else or a specific requirement for this PUP distro....maybe.

Will get back to prescribe how users should use mount from this distro to the PUPs on their LAN which share folders.

It is a new requirement. SMB software was upated to default to protocol version 2.1. If you want to mount a disk from an old Windows PC, old router, basically any disk/server that predates a recent SMB client software (like the one in QuickPup64), you must CHANGE your mount command to include an option to use SMB 1.0 so the remote disk/server will understand that it's being requested for mounting and reply accordingly. An old disk/server can only speak SMB 1.0 because 2.1 didn't exist when the disk/server was deployed, and the old disk/server's SMB was never updated.

step wrote: ↑Thu Jul 28, 2022 8:58 pm

It is a new requirement.

This was first discussed in the YASSM thread in November 2017.

Updated info on QP64's current LAN existence and behavior:
Local SAMBA started

On this local QP64, I've Rechecked local behavior via terminal with text on each command

# echo "This shows attempt to connect to home's NAS from QP64"
This shows attempt to connect to home's NAS from QP64
#
# findsmb # Can you see any local resources?

                                *=DMB
                                +=LMB
IP ADDR         NETBIOS NAME     WORKGROUP/OS/VERSION 
---------------------------------------------------------------------
# smbclient -U% -L 192.168.1.10 # Can you see this local LAN resource

	Sharename       Type      Comment
	---------       ----      -------
	Downloads       Disk      OS ISO files
	Downloads2      Disk      OS IMG files
	Multimedia      Disk      Test1
	Backups         Disk      Test2
	IPC$            IPC       IPC Service (Puppy Samba Server)
SMB1 disabled -- no workgroup available
# findsmb # Can you see any local resources?

                                *=DMB
                                +=LMB
IP ADDR         NETBIOS NAME     WORKGROUP/OS/VERSION 
---------------------------------------------------------------------
# smbclient -U% -L localhost       # Can you see YOUR local LAN resource

	Sharename       Type      Comment
	---------       ----      -------
	puppyshare      Disk      
	IPC$            IPC       IPC Service (Puppy Samba Server)
SMB1 disabled -- no workgroup available
# mkdir /mnt/test # Create a test folder
# mount -o password=woofwoof //localhost/puppyshare /mnt/test # connect to the test folder
# umount /mnt/test # disconnect from the test folder
# mount -o password=woofwoof //192.168.1.10/Downloads /mnt/test # connect to renote PC folder
mount error(22): Invalid argument
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)
# samba --version # what version is THIS SAMBA
Version 4.16.4
# echo "This shows current test to problem"
This shows current test to problem
#

So the terminal account shows local to local things seem OK. But attempts to&from other PUPs-DOGs on the LAN, not so. Further, the 'findsmb' command shown in the terminal account is coming back empty where there are LAN PCs sharing their public folder

Further info:

1. The firewall is turned off

2. I cannot ping this local QP64 PC from other LAN PCs, no response

3. I cannot access the folder being shared from this PC as I am getting timeouts via smbclient nor mount commands from the other PCs

.
Something is amiss

I recognize that past accounts discuss issues, but until now, I haven't experienced those concerns with all the PUPs I have used.

I will recheck the ISO file's checksum to see if there is a mismatch and report back here.
EDIT: Just checked the checksum...it matches "a1a1380ba5e799e3c78adfa4540189a8"

Has anyone else checked this LAN behavior on your LAN? ALL of my PUPs & DOGs are recent with recent OOTB SAMBA implementations.

Check the mount command I submitted and check for yourself the local connects, then try the same using this QP64-b17 version.

Thanks in advance for your personal findings and any subsequent mount command changes you offer.

AGAIN, excepting for 2 LAN resources, ALL of my home LAN connected units are PUPs & DOGs.

This QP64 is running on a HP-G024 AIO. It is wired to the ethernet LAN; as such, WiFi is not in use/needed. I have NOT tried bluetooth.

Although not applicable to the above issues, I share these result

# dmesg | grep -i fail
[   10.292563] exFAT-fs (loop99): failed to read boot sector
[   10.292566] exFAT-fs (loop99): failed to recognize exfat type
[   57.874575] tpm_crb: probe of MSFT0101:00 failed with error -16
[   60.360881] bluetooth hci0: Direct firmware load for rtl_bt/rtl8723b_config.bin failed with error -2

FYI

Request for future: Could the Print-Screen key be enabled to open the enclosed screen-capture?

Clarity wrote: ↑Thu Jul 28, 2022 11:59 pm

This QP64 is running on a HP-G024 AIO. It is wired to the ethernet LAN; as such, WiFi is not in use/needed. I have NOT tried bluetooth.

Although not applicable to the above issues, I share these result

Code: Select all

# dmesg | grep -i fail
[   10.292563] exFAT-fs (loop99): failed to read boot sector
[   10.292566] exFAT-fs (loop99): failed to recognize exfat type
[   57.874575] tpm_crb: probe of MSFT0101:00 failed with error -16
[   60.360881] bluetooth hci0: Direct firmware load for rtl_bt/rtl8723b_config.bin failed with error -2

FYI

Request for future: Could the Print-Screen key be enabled to open the enclosed screen-capture?

You need rtl8723b_config.bin firmware driver and put it to /lib/firmware/rtl_bt

QuickPup64 22.01 BETA 18

Changes:
* Fixed xz utils
* Adjustments on initrd

Download: https://drive.google.com/file/d/1KQybwd ... dVEpmnZk4O
MD5 Checksum: 00178cf8aed8ce851fd7206ff45ab7f7

OK, the 'weird' problem experienced has gotten more off the rails. So I now have 2 new conditions to report.

Firstly, after booting the AIO where the beta 17 file was copied and booted from. That beta 17 was booted via SG2D adding a PSAVE parm pointing to the /Sessions folder on the HDD's partition. beta17 found the past QP64 sessions in the folder and listed them for selection at boot. I opted for a pristine boot. As reported,, beta17 booted and I used it for various tests and tasks which I reported earlier. Upon shutdown, I had the system save the session into the /Sessions folder. Its name of the status screen was correct; ie /Sessions/QPsave...

BUT, instead of creating a new folder, the shutdown processor placed all of the sessions folders in the root of the /Sessions folder rather than in the QPsave it was suppose to create. Weird, again.

Next, in testing, I have now found that the beta17 ISO file on the USB is now booting to desktop with no other changes excepting that beta18 was downloaded to the /boot-isos folder on the SG2D USB??? Now, I am really scratching my head.

This is a mere status as I continue to try to nail down WHY this anomaly is occurring on this AIO, my newest PC (circa 2016).

Next up, I will switch to testing beta 18 starting as a pristing with no PSAVE parm and advancing thru the steps.

P.S. Found this in one of the misplaced files

**** Initial ramdisk stage begin ****
Kernel info: 5.18.12-lxpup64 x86_64
Boot parameters: BOOT_IMAGE=/vmlinuz pfix=fsck pmedia=cd find_iso=/boot-isos/quickpup64_22.01-beta-17.iso psave=sda7:/Sessions/
Setting imaginary GMT setting...
Setting system time (based on hw clock set to local time)...
Checking modules inside initrd...
Checking keymaps inside initrd...
Starting mdev...
Finding kernel modules for disk drives...
Boot mode: UEFI
RAM size: 6867Mb
   o
   o
   o

This shows what was given to INIT at boot. BUt the folder shown above indicates that it DID NOT store the session in a QPsave folder as it should have.

Expected ISO file booting from the USB has occurred in beta18. The booting issue has vanished for a RAM only boot. From bootinit.log we verify Boot parameters: BOOT_IMAGE=/vmlinuz pfix=fsck pmedia=cd find_iso=/boot-isos/quickpup64_22.01-beta-18.iso

Other issues for LAN remain.

SAMBA is started at boot so the puppyshare folder is locally shared. BUT, LAN remotes CANNOT access this share while locally it can be accesses via the mount command.

# mkdir /mnt/Test
# mount //localhost/puppyshare  /mnt/Test

or # mount //192.168.1.15/puppyshare /mnt/Test

What version for the mount command is being used for the current SAMBA? Why the smbclient utility is working where the findsmb utility is not? This is confusing in how the local LAN services on this is working.

You can test, too
For those who want to replicate the mount problem on your network, its easy if you know your beta18's IP address. Test on beta18 in a terminal with this command ... then use the EXACT same command from one of your Linux remotes to see the problem
# mount //beta18's_IPaddress/puppyshare /mnt/Test
This will expose the problem for your review.

Afterwards, you can change the IP address to one of your home PCs and see mount working to them.

My Next report will be showing the results of Session saving when this is Shutdown as well as what happens when PSAVE is added at boot to capture the Saved session.

Rebooted without issues using the PSAVE parm on boot from the USB.

Just noticed that my firewall was active (I mistakenly assumed that removing it via right-click also stopped it. Not so.). So stopping it, the'findsmb' utility is now reporting other LAN shares available.

But, from the remotes, they can now ping this beta18 PC but accessing this beta18 shared resource (namely "puppyshare" problem from the remotes, remain.

And the local&remote mount problem remains.

BTW: The mystery folders have reappeared. I will be trying next to understand the external conditions that causes Shutdown processing to create them

@Clarity

About the mysterious folder, I think this boot parameter was seems the culprit

psave=sda7:/Sessions/

You specify Sessions folder as the save file/folder

QuickPup64 22.01 BETA 18 was reuploaded due to missing xz binary executables which cause trouble on package management

I hope @ally will replace her uploaded copy of QuickPup with this corrected one

Download: https://drive.google.com/file/d/1KQybwd ... dVEpmnZk4O
MD5 Checksum: c808c121369f9509aa169c17240b60ea

done!

thanks for the heads up

mistfire wrote: ↑Fri Jul 29, 2022 1:00 pm

... You specify Sessions folder as the save file/folder

Then there seems to be 2 different meanings around in Puppyland of what the PSAVE pointer means. @gyrog continues to update INIT to accommodate. It was my understanding from @gyrog that it is the "location" (folder-name) to create the persistence within...not the actual filename. Judging from the other PUPs-DOGs I am now curious as to which understanding is correct.

For the past years, I have been using the Session Saving parameters to indicate at boot the location where the Savefile or the Savefolder is to be placed...not the actual name of the dump of the system's save contents in all other PUPs/DOGs.
As such, via the parm,

• each systems knows where it will put or where it will find its persistence

• for example "ThePUPname'save'-..." will be the leading characters for the PUP generating or finding its persistence

• As you can see from the contents, are examples of @01micko's distros, @666philb's distros, @peebee, @dimkr etc. where the PUPs created those persistences files at shutdown and the PUPs finds those persistences on boot while also having the identity of where to place the persistence upon a pristine shutdown.

• This behavior is consistent with the SAVESPEC file contents that @gyrog has built-in to WoofCE's INITs.

So, you are pointing out that any distro builder/developers could mistakenly build, interpreting how the PUP is to create, place, and name 'persistence'.

I dont make these interpretations, but, I do try to work within the design of the framework that is architected. So, now, which of the developers interpretation is correct for user use?

When Slacko boots it finds his and lists all it finds when there are multiples; when Fossas boots it finds his and lists all it finds when there are multiples; when Void boot and lists all it finds when there are multiples;... So the Sessions folder you see (from earlier) shows PUP persistences from the past PUPs booted on this PC (of course this behavior of those mentioned is the same on all PCs).

Hope we can see this dilemma in the differences in PUP SAVESPEC and PSAVE interpretation could happen, mistakenly. It is my understanding that those items identify the folder location PUPs will create or find persistence...not the actual filename of the persistence.

Question: Which is correct for the current PUP-DOG persistence architecture?

Thoughts?

P.S. I will present a pic showing what this PC presents for selection for FossaPUP64 in a moment. To give a pictorial understanding of what I am presenting in this post.

FossaPUP64 booted with PSAVE=sda7:/Sessions/ added to it boot Menu linux line

On my other PCs: Other PUPs, when multiple saves for it are present within the Sessions folder, boot with the same presentation list at boot to the user for selection.

QuickPup64 22.01 BETA 19 released

Changes:
* Fixed desktop environment default settings
* Linux kernel 5.18.15-lxpup64
* Blueman-2.3.1
* Adjustments on initrd psave boot parameter

Download: https://drive.google.com/file/d/1AKGvjl ... QilglzCVL3
MD5 Checksum: 4117e85b8f5f2417a3c3b61eb3c799f7

Video problem since version 15.
Refresh rate 0.0 Hz

@esos

1. May I know the name and model of your computer?
2. May I see the output of lspci?
3. May I see the contents of /etc/X11/xorg.conf file?

Shutdown works as expected.

On boot-processing, each Quickpup session which is saved is listed for user selection when there is more than one, also.

Thx for understanding.

All issues reported in earlier posts, for PRIOR beta versions, on LAN folder sharing and the utilities which support LAN folder access, no longer are present.

This PUP is clean in all aspects currently tested, including all the clever Puppy-Linux innovations provided in this distro.

Users, young and old, will find a friendly experience in this distro's use.

Thanks for all the great work.

Clarity wrote: ↑Mon Aug 01, 2022 6:38 am

All issues reported in earlier posts, for PRIOR beta versions, on LAN folder sharing and the utilities which support LAN folder access, no longer are present.

This PUP is clean in all aspects currently tested, including all the clever Puppy-Linux innovations provided in this distro.

Users, young and old, will find a friendly experience in this distro's use.

Thanks for all the great work.

Thanks @Clarity

That's the main goal of QuickPup, I hope the Quickpup's goal will adapt to main Puppy

@ mistfire

Manufacturer: MSI
Product Name: MS-7693 / 8x AMD FX(tm)-8320

VGA compatible controller: Advanced Micro Devices, Inc.
[AMD/ATI] Curacao PRO [Radeon R7 370 / R9 270/370 OEM]

Host bridge
• Advanced Micro Devices, Inc.
• VendorID=AMD/ATI RD9x0/RX980 Host Bridge
• VendorID=1002 DeviceID=5a14 Rev=02

IOMMU
• Advanced Micro Devices, Inc.
• VendorID=AMD/ATI RD890S/RD990 I/O Memory Management Unit IOMMU
• VendorID=1002 DeviceID=5a23

PCI bridge
• Advanced Micro Devices, Inc.
• VendorID=AMD/ATI RD890/RD9x0 PCI to PCI bridge PCI Express GFX port 1
• VendorID=1002 DeviceID=5a17
• Kernel Driver=pcieport

PCI bridge
• Advanced Micro Devices, Inc.
• VendorID=AMD/ATI RD890/RD9x0/RX980 PCI to PCI bridge PCI Express GPP Port 0
• VendorID=1002 DeviceID=5a18
• Kernel Driver=pcieport

====> /etc/X11/xorg.conf <====

# **********************************************************************
# Server flags section.
# **********************************************************************

Section "ServerFlags"

Option "IgnoreABI" "true"

# Uncomment this to disable the <Crtl><Alt><Fn> VT switch sequence
# (where n is 1 through 12). This allows clients to receive these key
# events.

Option "DontVTSwitch" "true"

# Enables mode switching with xrandr
# There is a report that this can cause Xorg not to work on some
# video hardware, so default is commented-out...
# but i want to use it in xorgwizard so leave on...

Option "RandR" "on"

# With this, Xorg wont talk to HAL to add evdev devices and youll be back
# with the old Xorg behavior (pre-7.4)...

Option "AutoAddDevices" "true"

# For no-Hal, kirk also suggests this...

# Option "AllowMouseOpenFail" "true"

# Xorg 7.4, Ubuntu Jaunty, CTRL-ALT-BACKSPACE is disabled by default...

Option "DontZap" "false"

EndSection

Section "ServerLayout"
Identifier "X.org Configured"
Screen 0 "Screen0" 0 0
# InputDevice "Synaptics Mouse" "AlwaysCore" #serverlayoutsynaptics
# InputDevice "VboxMouse" "CorePointer"
#InputDevice "Mouse0" "CorePointer"
#InputDevice "Keyboard0" "CoreKeyboard"
EndSection

Section "Files"
ModulePath "/usr/lib64/xorg/modules"
FontPath "/usr/share/fonts/local"
FontPath "/usr/share/fonts/TTF"
FontPath "/usr/share/fonts/OTF"
FontPath "/usr/share/fonts/Type1"
FontPath "/usr/share/fonts/misc"
FontPath "/usr/share/fonts/truetype"
FontPath "/usr/share/fonts/opentype"
FontPath "/usr/share/fonts/woff"
FontPath "/usr/share/fonts/CID"
FontPath "/usr/share/fonts/75dpi/:unscaled"
FontPath "/usr/share/fonts/100dpi/:unscaled"
FontPath "/usr/share/fonts/75dpi"
FontPath "/usr/share/fonts/100dpi"
FontPath "/usr/share/fonts/cyrillic"
FontPath "/usr/share/fonts/X11/misc"
FontPath "/usr/share/X11/fonts/misc"
FontPath "/usr/share/fonts/X11/TTF"
FontPath "/usr/share/fonts/X11/OTF"
FontPath "/usr/share/fonts/X11/Type1"
FontPath "/usr/share/fonts/X11/100dpi"
FontPath "/usr/share/fonts/X11/75dpi"
FontPath "/usr/share/X11/fonts"
FontPath "/usr/local/share/fonts"
FontPath "/usr/local/share/X11/fonts"
EndSection

Section "Module"
# Load "synaptics" #loadsynaptics
Load "glx"
EndSection

Section "InputClass"
Identifier "Keyboard Defaults"
MatchIsKeyboard "yes"
Option "XkbModel" "pc104" #xkbmodel0
Option "XkbLayout" "us" #xkeymap0
#Option "XkbVariant" "" #xkbvariant0
Option "XkbOptions" "terminate:ctrl_alt_bksp" #xkboptions0
EndSection

Section "Monitor"
Identifier "Monitor0"
VendorName "Monitor Vendor"
ModelName "Monitor Model"
HorizSync 35-81
VertRefresh 59-76
#UseModes "Modes0" #monitor0usemodes
# Option "PreferredMode" "1024x768" #monitor0prefmode
EndSection

Section "Modes"
Identifier "Modes0"
#modes0modeline0
EndSection

Section "Device"
Identifier "Card0"
Driver "vesa" #card0driver
EndSection

Section "Screen"
Identifier "Screen0"
# Device "Card0"
Monitor "Monitor0"
# DefaultDepth 24
#Option "metamodes" "1280x800_60 +0+0" #METAMODES_0
Subsection "Display"
Depth 24 #screen0depth
# Modes "1024x768" #screen0modes
EndSubsection
EndSection

esos wrote: ↑Mon Aug 01, 2022 9:12 pm

VGA compatible controller: Advanced Micro Devices, Inc.
[AMD/ATI] Curacao PRO [Radeon R7 370 / R9 270/370 OEM]

@esos

What's the vendor id and device id of this video card?

Can you give the terminal output using this command:

busybox lspci

# busybox lspci
00:18.3 Class 0600: 1022:1603
00:15.1 Class 0604: 1002:43a1
00:13.2 Class 0c03: 1002:4396
00:18.1 Class 0600: 1022:1601
02:00.0 Class 0c03: 1b21:1042
00:14.5 Class 0c03: 1002:4399
00:16.2 Class 0c03: 1002:4396
00:13.0 Class 0c03: 1002:4397
00:04.0 Class 0604: 1002:5a18
00:14.3 Class 0601: 1002:439d
00:16.0 Class 0c03: 1002:4397
01:00.0 Class 0300: 1002:6811
00:14.1 Class 0101: 1002:439c
00:00.2 Class 0806: 1002:5a23
00:12.2 Class 0c03: 1002:4396
00:00.0 Class 0600: 1002:5a14
00:18.4 Class 0600: 1022:1604
00:12.0 Class 0c03: 1002:4397
00:03.0 Class 0604: 1002:5a17
00:18.2 Class 0600: 1022:1602
00:15.0 Class 0604: 1002:43a0
05:00.0 Class 0280: 168c:002e
00:18.0 Class 0600: 1022:1600
00:14.4 Class 0604: 1002:4384
01:00.1 Class 0403: 1002:aab0
00:14.2 Class 0403: 1002:4383
00:11.0 Class 0106: 1002:4390
04:00.0 Class 0200: 10ec:8168
00:14.0 Class 0c05: 1002:4385
00:18.5 Class 0600: 1022:1605
#

What's the vendor id and device id of this video card?

Pls see attached file

esos wrote: ↑Tue Aug 02, 2022 10:05 pm

# busybox lspci
00:18.3 Class 0600: 1022:1603
00:15.1 Class 0604: 1002:43a1
00:13.2 Class 0c03: 1002:4396
00:18.1 Class 0600: 1022:1601
02:00.0 Class 0c03: 1b21:1042
00:14.5 Class 0c03: 1002:4399
00:16.2 Class 0c03: 1002:4396
00:13.0 Class 0c03: 1002:4397
00:04.0 Class 0604: 1002:5a18
00:14.3 Class 0601: 1002:439d
00:16.0 Class 0c03: 1002:4397
01:00.0 Class 0300: 1002:6811
00:14.1 Class 0101: 1002:439c
00:00.2 Class 0806: 1002:5a23
00:12.2 Class 0c03: 1002:4396
00:00.0 Class 0600: 1002:5a14
00:18.4 Class 0600: 1022:1604
00:12.0 Class 0c03: 1002:4397
00:03.0 Class 0604: 1002:5a17
00:18.2 Class 0600: 1022:1602
00:15.0 Class 0604: 1002:43a0
05:00.0 Class 0280: 168c:002e
00:18.0 Class 0600: 1022:1600
00:14.4 Class 0604: 1002:4384
01:00.1 Class 0403: 1002:aab0
00:14.2 Class 0403: 1002:4383
00:11.0 Class 0106: 1002:4390
04:00.0 Class 0200: 10ec:8168
00:14.0 Class 0c05: 1002:4385
00:18.5 Class 0600: 1022:1605
#

@esos

Just I expected, it was 1002:6811. I made a modifications on xorg-autoconf

As temporary workaround for you, try to edit /etc/X11/xorg.conf with text editor. Replace word "vesa" with "amdgpu" then save and restart Xorg. If failed to start xorg then run this shell command on commandline

xorg-autoconf > /etc/X11/xorg.conf

then run startx to start you desktop environment then edit again the xorg.conf file but this time replace word "vesa" with "radeon" then restart Xorg

To restart Xorg from Desktop environment goto Menu > Log Out then select RESTART X WINDOW

Sorry, it does not solve the problem

esos wrote: ↑Thu Aug 04, 2022 9:42 pm

Sorry, it does not solve the problem

@esos

Can you please send the Xorg log file here? Thanks

QuickPup64 22.01 BETA 20 released

Changes:
* Linux kernel 5.19
* Glibc 2.36
* Added bookmarking feature on Thunar (Just right click the folder and select ADD THIS FOLDER TO BOOKMARKS)
* xdotool added.

Note: Rustdesk just works on this release

Download: https://drive.google.com/file/d/1Bl3zMk ... 7KXClFD6un
MD5 Checksum: 9a9b6ca158ef53f9778694abaa01e3df

I can not send Xorg log file as you requested.

This is the reason:
"Your message contains 95905 characters.
The maximum number of allowed characters is 60000."