Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Fri 13 Dec 2019, 08:05
All times are UTC - 4
 Forum index » Advanced Topics » Puppy Projects
Fatdog64-802/801/800 Final [21 May 2019]
Moderators: Flash, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 29 of 30 [448 Posts]   Goto page: Previous 1, 2, 3, ..., 27, 28, 29, 30 Next
Author Message
belham2

Joined: 15 Aug 2016
Posts: 1707

PostPosted: Thu 21 Nov 2019, 03:04    Post subject:  

rufwoof wrote:
In multi-session save mode, you set Fatdog to load all of the prior saves automatically at next reboot, there's no need to manually set/load them by-hand, you just add the appropriate 'savefile' kernel boot parameter.

You can't be selective, as they're sequential save sfs's, so missing one out in the middle would mess things up. You can however opt to not load the last N saves. For readability I've shortened down my actual uuid in the following, but that's the kernel boot paramater I use for multi-session. The last two ":" don't have to be included, but I leave them as that way its a reminder of where the 'skip' N saves value is

savefile=direct:multi:uuid:5d::

i.e. if I change that to

savefile=direct:multi:uuid:5d::2

then it wont load the last two saves.

Or you could just manually delete the last (most recent) save sfs

When you have say 10+ saves and want to consolidate them, I boot (so all the saves are loaded into ram), manually delete all of the multisession save files (sfs's) - backing them up first just in case, and then click the desktop 'save' icon ... and its back down to just two save sfs's.

My full menu.lst entry looks like
title FatDog
root (hd0,0)
kernel /fatdog-vmlinuz pkeys=uk waitdev=5 basesfs=ram:uuid:5df8f89e-33d5-4720-b3f2-9c9030a718bd:/fd64.sfs savefile=direct:multi:uuid:5df8f89e-33d5-4720-b3f2-9c9030a718bd::
initrd /fatdog-initrd.xz

Note that in my case I originally clicked on the initrd to open it, dragged out the fd64.sfs from that, and then closed the initrd again (by clicking the repack-initrd file) so as to have the main sfs (fd64.sfs) outside of initrd. Note also that I've renamed the vmlinuz and initrd (and I've also opted to xz compress the initrd) ... i.e. not they're not the default/standard names

The appeal of multisession for me is that I install it all to and boot/run from usb stick (bootloader etc.), and all saves are written back to that usb. But where I have Event Manager's Save Session Interval set to zero so it only ever saves on demand, and the usb can be removed between times (i.e. is physically isolated after having booted up the system). Mostly I'm very frugal with saves Smile i.e. tend to just boot, use, shutdown without saving, and I'm careful as to what saves are added (boot clean, make changes, save ... without doing anything else so that the system remains 'clean'). I keep my bookmarks in a text file, and have tilda drop down terminal installed, where one of its tabs has that bookmarks text file open (and where hovering-over and clicking a link opens up that url in chrome). Chrome is about the only reason I run 'save' i.e. boot, use the control panel to update to the latest version of chrome, save.

Another appeal is that Fatdog only improves with age, each later release builds upon the last release. With Puppy it often seemed one step forward two steps back i.e. some past improvements were suddenly lost.

Yet another appeal of Fatdog for me is that its alsa equaliser works. i.e. running alsamixer presents the usual alsa mixer, but running alsamixer -D equal ... presents a working equaliser. And, at least for me, its alsa supports multiple sound sources being played simultaneously.



Thanks, Rufwoof, that clears it up for me. Had totally forgot about I needed to make menu.lst changes if I want Fatdog to look for something I created on a previous pristine boot and I had not created a 'savefile' at the end of that pristine boot (so Fatdog could remember things for next next boot).

Soon as I saw your menu.lst example, I had to shake my head at myself Rolling Eyes

Thanks again.
Back to top
View user's profile Send private message 
rufwoof


Joined: 24 Feb 2014
Posts: 3675

PostPosted: Thu 21 Nov 2019, 05:39    Post subject:  

This is another menu.lst of mine, that boots from hdd (again for readability I've shortened down the uuid for the disk, you can identify the uuid for a disk/partition by using the blkid command)

title Fatdog TIP
root (hd0,0)
kernel /FATDOG-TIP/vmlinuz net=wpa2:abcd:1234:wlan0:dhcp pkeys=uk lateshell basesfs=ram:uuid:4d054dbd-ff:/FATDOG-TIP/fd64.sfs savefile=direct:multi:uuid:4d054dbd-ff:/FATDOG-TIP/:
initrd /FATDOG-TIP/initrd

where the files are stored in a /FATDOG-TIP folder

At bootup it connects to wifi (net= ... settings, abcd and 1234 are not my actual ssid/password) and boots to cli (lateshell kernel parameter). When done with cli you can either 'exit' to resume bootup to the full gui desktop, or whatever (shutdown/reboot).

_________________
( ͡° ͜ʖ ͡°) :wq
Fatdog multi-session usb

echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh
Back to top
View user's profile Send private message 
rufwoof


Joined: 24 Feb 2014
Posts: 3675

PostPosted: Mon 25 Nov 2019, 08:11    Post subject:  

jamesbond wrote:
@rufwoof: kexec as a standard build.

Thanks for the suggestion. I will keep this in mind, but at the time being I'm reluctant to do so.

Outside of the standard build - fair enough, but having (static) kexec available in the repository perhaps ??

Assuming a usb boot type setup, having a default Bulldog that caters for booting (to initrd cli), prompting for the usb to be unplugged before continuing, so that the usb is physically isolated, and only then loading up the main system and/or net connecting ... keeps the MBR/bootloader/kernel/initrd (usb) out of harms way (clean). Whilst providing the potential to include checksums/filesize details checking of the main sfs so that the fd64.sfs is pre-validated prior to it being loaded/used. With kexec available, that could be used as a secure 'bootloader' (Bulldog in effect being used as a form of bootloader to boot other Puppy's/whatever). kexec compiled as a static needn't be contained within Bulldog/initrd, in fact its possibly better to keep that binary outside of initrd, storing/running it alongside whatever its being used to boot.

With bbshell/bbhook in the pipeline however, that is pretty much possible as-is. kexec could be 'installed/run' by that 'external' script. However process_network would ideally be better placed in init AFTER bbshell/bbhook

My thinking (thoughts seeded by gjuhasz's Puli http://murga-linux.com/puppy/viewtopic.php?p=1042618#1042618) is that rearranging init, perhaps moving process_net down from its current position in tip/current to being just after bbhook/bbshell, and also adding another bbhook/bbshell after process_net ... would do the trick. Two bbhook's/bbshell's (pre-net and post net) perhaps named bbshell1 and bbshell2 ... or perhaps something like bbprenet, bbpostnet. With the intent that bbprenet can be used to prompt to unplug the usb with that occurring before (early) net connect (net connection being a potential system integrity risk), and bbpostnet being used (assuming a net: kernel boot parameter also having been set) to ssh to a known ssh server in order to potentially flag any man-in-middle attack. Those scripts could also be used to checksum/filesize check fd64.sfs (or whatever) against known values (stored on the usb/copied into ram), as could any other Puppy boot files be validated/checked (that might be being booted using kexec instead of booting fd64.sfs).

Any appeal for a portable Bulldog based secure 'bootloader' usb stick, purely for secure bootup purpose would have the natural tendency to also induce booting the main fd64.sfs IMO (expand appeal/usage of Fatdog). Transforming Bulldog from a predominately little used available option into something that has wider usage appeal (amongst other things - a secure portable bootloader) Smile

Specifically ...

Make kexec static available in the repo
http://murga-linux.com/puppy/viewtopic.php?p=1040675#1040675

Revise init to move process_network down to below bbhook/bbshell (in the current TIP), renaming bbhook/bbshell to bbpreearlynet

Add another bbhook/bbshell (bbpostearlynet) immediately after process_network

Revise the standard kernel .config (build) to include the KEXEC support by default

CONFIG_KEXEC_CORE=y
CONFIG_KEXEC=y

I have tried that and moving process_network down to later on in init worked OK for my setup. I don't think that will have any other implications - but leave it for the experts/wiser Smile

_________________
( ͡° ͜ʖ ͡°) :wq
Fatdog multi-session usb

echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh
Back to top
View user's profile Send private message 
jamesbond

Joined: 26 Feb 2007
Posts: 3388
Location: The Blue Marble

PostPosted: Mon 25 Nov 2019, 20:00    Post subject:  

@rufwoof:

- Make kexec static available in the repo
OK.

- Revise init to move process_network down to below bbhook/bbshell (in the current TIP), renaming bbhook/bbshell to bbpreearlynet
- Add another bbhook/bbshell (bbpostearlynet) immediately after process_network
Counter-proposal:
1. process_net stays where it is (that is, before bbhook/bbshell)
2. bbhook/bbshell remains what they are
3. Add a "wait" prefix to the "net" parameter to pause boot before net is processed. (net=wait:original-net-parameters).

- Revise the standard kernel .config (build) to include the KEXEC support by default
This comes with risks as well. I don't think the benefit (for the general population) is worth the risk, so I will have to say no to this one. Everyone who wants to do this is of course welcome to compile their own kernel, as you do, but standard Fatdog will not come with this enabled.

- Any appeal for a portable Bulldog based secure 'bootloader' usb stick
I did that for FatdogArm six years ago: http://lightofdawn.org/wiki/wiki.cgi/KexecBootMenu but I fail to see the benefit of doing that for the x86_64 platform where we already have excellent bootloaders. Of course I do see the point that a Bulldog-based bootloader the way you propose will be much, much more flexible - as you have the entire power of Linux kernel and userspace available for use, as opposed to the limited scripting abilities of even the best bootloaders - but for now it remains a very obscure use case.

_________________
Fatdog64 forum links: Latest version | Contributed packages | ISO builder
Back to top
View user's profile Send private message 
rufwoof


Joined: 24 Feb 2014
Posts: 3675

PostPosted: Mon 25 Nov 2019, 20:51    Post subject:  

I like your "wait" net idea James. Works for me
Code:
process_net() {
   [ "$net" = "ask" ] && read -p "net=" net 2>&1
   [ -z "$net" ] && return;
   OIFS="$IFS"; IFS=":"; set -- $net; IFS="$OIFS"
   
   [ "$1" = "wait" ] &&
      shift &&
      echo 'Starting pre-net shell. Type "exit" to continue.' &&
      setsid cttyhack /bin/sh 
   
   echo -n "Configure network "
   # network type
   case $1 in ......

Alternatives to running a shell as per the above might be to run a script i.e. perhaps containing a prompt to unplug the usb and press enter to resume standard bootup (net connect etc.).

_________________
( ͡° ͜ʖ ͡°) :wq
Fatdog multi-session usb

echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh
Back to top
View user's profile Send private message 
jamesbond

Joined: 26 Feb 2007
Posts: 3388
Location: The Blue Marble

PostPosted: Mon 25 Nov 2019, 21:46    Post subject:  

Actually I did this:
Code:
[ "$1" = "wait" ] && shift && read -p "About to configure network, press Enter to continue ..." p 2>&1

I moved process_net all the way just before bbhook/bbshell is run. This way, all the other stuff that might needs the USB (mergeinitrd, key loading etc) would have been completed before net is started, and you can unplug the USB as there is nothing else that it needs.

You can see the details in tip, I just uploaded it. kexec-tools-static is now also in the repo.

_________________
Fatdog64 forum links: Latest version | Contributed packages | ISO builder
Back to top
View user's profile Send private message 
rufwoof


Joined: 24 Feb 2014
Posts: 3675

PostPosted: Tue 26 Nov 2019, 22:00    Post subject:  

Downloaded OpenSSL 1.1.1d and used the Fatdog recipe as a guide to compile it. made DESTDIR and built a sfs of that. Loading and running that seemed OK, so I've now unsquashed that to / and created a multi-session save.

Earlier versions of OpenSSL are beyond/near their EOL dates https://www.openssl.org/ (Thanks to Mikeslr for highlighting that).

James wrote:
I moved process_net all the way just before bbhook/bbshell is run. This way, all the other stuff that might needs the USB (mergeinitrd, key loading etc) would have been completed before net is started, and you can unplug the USB as there is nothing else that it needs.

You can see the details in tip, I just uploaded it. kexec-tools-static is now also in the repo.

Thanks James. Want to test out OpenSSL for a while yet before getting around to moving over to that latest tip.

_________________
( ͡° ͜ʖ ͡°) :wq
Fatdog multi-session usb

echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh
Back to top
View user's profile Send private message 
rufwoof


Joined: 24 Feb 2014
Posts: 3675

PostPosted: Wed 27 Nov 2019, 12:06    Post subject:  

Relevant ??
Quote:
In common with the Fatdog kernels your firmware does not have the AMDGPU firmware for this year's AMD processors: raven2 and picasso. I copied them out of the Debian Buster firmware-amd-graphics package.

http://murga-linux.com/puppy/viewtopic.php?p=1042806#1042806

_________________
( ͡° ͜ʖ ͡°) :wq
Fatdog multi-session usb

echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh
Back to top
View user's profile Send private message 
rufwoof


Joined: 24 Feb 2014
Posts: 3675

PostPosted: Fri 29 Nov 2019, 21:55    Post subject:  

Hitting a problem with encrypted folders.

Switched over from using openssl to encrypt my .ssh folder (ssh keys/config) to use encfs instead (same as per the right click rox encrypt folder option).

..ssh and .ssh seem to work fine generally (adding/removing/editing files etc), however for a particular ssh server in the ssh config file I have a entry that includes ...

ControlMaster auto
ControlPath /root/.ssh/%r@%h:%p

ssh (client) configuration values for a particular ssh server connection. Previously that worked fine, but with encfs 'opened' .ssh folder content the ssh connect fails.

Basically that ControlPath configuration parameter creates a link to the actual ssh connection and I think its either the @ in the file (link) name that is causing the problem for encfs ?? Or perhaps its because the .ssh folder is being fuse mounted ??

_________________
( ͡° ͜ʖ ͡°) :wq
Fatdog multi-session usb

echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh
Back to top
View user's profile Send private message 
jamesbond

Joined: 26 Feb 2007
Posts: 3388
Location: The Blue Marble

PostPosted: Sun 01 Dec 2019, 10:36    Post subject:  

@rufwoof: ... Downloaded OpenSSL 1.1.1d ...
Yes, thanks. I've updated openssl to 1.1.0l (I don't want to move to 1.1.1 yet without extensive testing).

@rufwoof: ... does not have the AMDGPU firmware ...
firmware depends on kernel version. If the kernel doesn't support the new hardware, there is no point adding new firmware.

@rufwoof: ... Hitting a problem with encrypted folders. ...
Never tried this configuration before, but I think it could be due to .ssh folder permission. ssh needs it to be 0400. Try chmod the folder to 0400 __after__ it is mounted, and see if it helps.

Note: I have reverted the change that performs chmod 0400 on /proc/cmdline. None of the other big distros do that, and it causes breakage in existing scripts when running as non-root user. So for now I'm not doing that. If you need this yourself then you can customise either initrd/bbhook (if you use bulldog only) or create a service script if you use the full fatdog.

_________________
Fatdog64 forum links: Latest version | Contributed packages | ISO builder
Back to top
View user's profile Send private message 
LateAdopter

Joined: 27 May 2011
Posts: 321
Location: Reading UK

PostPosted: Sun 01 Dec 2019, 13:46    Post subject:  

jamesbond wrote:
@rufwoof: ... does not have the AMDGPU firmware ...
firmware depends on kernel version. If the kernel doesn't support the new hardware, there is no point adding new firmware.

Hello jamesbond
That's right, the 4.19.86 kernel that you have just built does not support raven2/picasso that were released about January. I tried it with my updated version of Bionicpup64. - Xorg can't find a driver.
Now that I've got my new box running with stemsee's 5.3.11, I'm working towards building a later kernel. I've just got to find out how to get HDMI audio working...!
Back to top
View user's profile Send private message 
don570


Joined: 10 Mar 2010
Posts: 5395
Location: Ontario

PostPosted: Wed 04 Dec 2019, 20:49    Post subject:  

Quote:
I've just got to find out how to get HDMI audio working...!


I noticed that when audacity is installed (it has a lot of dependencies)
... it has a choice of sound sources
__________________________________________________

I have nvidia GT1030 card and I think it can output hdmi audio but I
haven't checked.

Audacity and alsamixer list it as a possible output.

https://superuser.com/questions/758341/does-the-hdmi-port-on-a-video-card-support-audio

____________________________________________

Also I've had good results with a USB sound card (actually adaptor)
Check here...
http://murga-linux.com/puppy/viewtopic.php?p=998602#998602
_________________________________________________
Back to top
View user's profile Send private message 
don570


Joined: 10 Mar 2010
Posts: 5395
Location: Ontario

PostPosted: Wed 04 Dec 2019, 21:09    Post subject: connected to raspberry pi server  

Report:

I connected to a raspberry pi server (it was running Raspberry Pi Buster Raspup RC)

There is a connection icon in Raspberry Pi Buster but I was adventurous
and tried the terminal commands...



Code:
# smbclient -L 192.168.1.106
Enter WORKGROUP\root's password:

   Sharename       Type      Comment
   ---------       ----      -------
   Downloads       Disk     
   IPC$            IPC       IPC Service (Samba 4.7.8)
Reconnecting with SMB1 for workgroup listing.

   Server               Comment
   ---------            -------

   Workgroup            Master
   ---------            -------
                        CISCO99987
   WORKGROUP            FATDOG64-567



SMB share is 'Downloads'
I could connect with following command in raspberry pi Buster...

Code:
# mount-FULL -t cifs //192.168.1.106/Downloads /root/samba-sharefolder -o guest


where I created the folder /root/samba-sharefolder

There is no password for 'guest' nor did I make a samba user 'guest'
_______________________________________________

I made a server in the raspberry pi and connected to it as well
(see image). Two servers are listed.
_________________________________________[/code]
raspberry-puppy.png
 Description   
 Filesize   45.93 KB
 Viewed   152 Time(s)

raspberry-puppy.png

Back to top
View user's profile Send private message 
step

Joined: 04 May 2012
Posts: 1225

PostPosted: Thu 05 Dec 2019, 04:29    Post subject:  

In your picture, which shows the result of share discovery across your LAN, the serverName FATDOG... is the share hosted by the Fatdog64 PC. By default it's /home/spot/Downloads open to SMB guest users (no password). By default that share is disabled. It gets enabled when you run the samba service on Fatdog64, either manually or from the control panel Services applet.
The serverName PUPPYPC* is the share hosted by the Buster PC.

_________________
Fatdog64-810|+Packages|Kodi|gtkmenuplus
Back to top
View user's profile Send private message 
don570


Joined: 10 Mar 2010
Posts: 5395
Location: Ontario

PostPosted: Sat 07 Dec 2019, 14:20    Post subject:  

Possible bug ???

When I try to contact my fatdog64 802 computer using ssh -X option
there is a problem launching X programs over SSH

Here is the terminal of my raspberry pi Buster

Code:


# ssh -X root@192.168.1.108
The authenticity of host '192.168.1.108 (192.168.1.108)' can't be established.
RSA key fingerprint is SHA256:OH4yeiOEAZuodZTCs2PYajjWwK0V/LftTHvPyXEZTuw.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.1.108' (RSA) to the list of known hosts.
root@192.168.1.108's password:
[18041] Dec 07 01:19:19 lastlog_perform_login: Couldn't stat /var/log/lastlog: No such file or directory
[18041] Dec 07 01:19:19 lastlog_openseek: /var/log/lastlog is not a file or directory!

* Running in PUPMODE 13  (saving changes to RAM)
* Type save2flash whenever you want to save session to pupsave
# /etc/eventmanager has RAMSAVEINTERVAL which you can adjust to your liking

# mtpaint

(mtpaint:18070): Gtk-WARNING **: 01:19:26.656: cannot open display:
#


Note that mtpaint won't launch. The same is true when I try other GUI programs.
But I can get SSH to work in terminal (non-GUI).
______________________________________________
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 29 of 30 [448 Posts]   Goto page: Previous 1, 2, 3, ..., 27, 28, 29, 30 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Puppy Projects
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1457s ][ Queries: 13 (0.0624s) ][ GZIP on ]