Just-Lighthouse64-805/900

[pup2023]

TazOc's Lighthouse...

any...archived...links?

[dancytron]

TazOc's Lighthouse...

any...archived...links?

https://archive.org/details/Puppy_Linux_Lighthouse64 is the final version I think, but there are dozens of builds on archive.org (thanks ally).

It's worth booting up and looking at. A lot of good design ideas.

[ally]

https://archive.org/details/puppylinux? ... ghthouse64

you're welcome D

[Dry Falls]

New version uploaded to mega.nz (see first post).

To re-emphasize, Lighthouse was built with Woof2, and not WoofCE. Just-Lighthouse is the result of 11 years worth of remasters. It keeps an older look and feel but is present-compatible. It is non-user-merge and will run as aufs or overlay (thanks to Ozsouth' help). And it is as close as a puppy can get to full compatibility with Slackware64-current which is pretty bleeding edge. This means you can use Slackware tools to upgrade any part or the whole system.

It still incorporates pupmode 14 and 15 developed by TazOC and Q5sys (from murga forum) so no mucking around with pseudo pmedia settings in the boot menu. pfix=noatosave is the default setting for save on demand.

df

[dimkr]

It still incorporates pupmode 14 and 15 developed by TazOC and Q5sys

Can you describe how they work and how they differ from others?

[Dry Falls]

Hi Dimkr. Noautosave forces the event manager to keep all changes in pup_rw no matter what media lighthouse is booted from. The following may be overkill but...
From the init script in initrd...
1: #130212 TaZoC Create loop devs above loop15. pfix=noautosave PUPMODE=14,15 (savefile writes on user request only.) see layer_extra_sfs_func.
2:

Code: Select all

[ $autosave -eq 0 ] && PNOAUTOSAVE="yes" #130312 tmpfs layer, (snapmerge on user request only).
...
if [ "$pfix" ];then
 for ONEFIX in `echo -n "$pfix" | tr ',' ' '`
 do
  case $ONEFIX in
   ...
   noautosave)   PNOAUTOSAVE="yes";; #130312 tmpfs layer, (snapmerge on user request only).

3:

Code: Select all

if [ "$PNOAUTOSAVE" = "yes" ]; then #130312 snapmerge on user request only
    case $PUPMODE in
     12) PUPMODE=14 ;; # tmpfs layer, no autosaves
     13) PUPMODE=15 ;; # ditto, but flash media
    esac
   fi

There are a handfull of scripts in the running system (after switch-root) which need edited such as pup_event_frontend_d, rc.sysinit and perhaps rc.shutdown which need to add 14|15 to 12|13.
ex. < if [ "$(echo $PUPMODE | grep -Ew '3|7|13|14|15')" ];then > or

Code: Select all

 if [ $PUPMODE != 14 -a $PUPMODE != 15 ] && [ $RAMSAVEINTERVAL -ne 0 -a $SAVECNT -gt $RAMSAVEINTERVAL ];then
  touch /tmp/snapmergepuppyrequest #request to savepuppy_func.
  SAVECNT=0
 fi

This is the full layer_extra_sfs_func extracted from the init script:

Code: Select all

layer_extra_sfs_func() { #101219 TazOC Layer SFS from RAM if COPYEXTRASFS2RAM="yes" and sufficient free, else mount in place
CNTLOOP=$1; ONEBASE="$2"; ONEEXTRA="$3"; COPYEXTRASFS2RAM="$4"

ONEBASELNK="$ONEBASE" #110127 in case ONEEXTRA is a relative link
if [ -L "$ONEEXTRA" ]; then #110127 can be a symlink, but must be a relative link
 ONEEXTRADIR="`dirname "$ONEEXTRA"`" #110127
 [ ! -f "${ONEEXTRADIR}/"`readlink "$ONEEXTRA"`"" ] && return 1 #110127
 ONEEXTRA="${ONEEXTRADIR}/"`readlink "$ONEEXTRA"`"" #110127 need the target
 ONEBASE="`basename "$ONEEXTRA"`" #110127
fi

#precaution: make sure ONEEXTRA exists
[ -d "$ONEEXTRA" ] || [ ! -e "$ONEEXTRA" ] && echo " not found" && return 1 #110127

rm -f /dev/loop${CNTLOOP} #130212
mknod /dev/loop${CNTLOOP} b 7 $CNTLOOP #130212
SIZEONEBASEK=`du -k "$ONEEXTRA" | cut -f 1`
SIZEONEBASEK=$(($SIZEONEBASEK * 100 / 99)) #some slack.
SIZEONEBASEKtmpfs=$SIZEONEBASEK #121128
SIZEONEBASEK=$(($SIZEONEBASEK * 11 / 5)) #110220 6/5 -> 21/10 #111127 16/5 #121128 12/5 #130202
MINRAM2CPY=$SIZEONEBASEK #111127
if [ "$SWAPPART" = "" ];then
 MINRAM2CPY=$(($SIZEONEBASEK + 96000)) # TazOC no swap, need more RAM
fi
[ "$COPYEXTRASFS2RAM" = "yes" ] && echo -en " min to copy: $(($MINRAM2CPY / 1024))M free: $(($RAMSIZE / 1024))M..." #100520 TazOC #130427
if [ $RAMSIZE -gt $MINRAM2CPY ] && [ "$COPYEXTRASFS2RAM" = "yes" ]; then #110106
 echo " copying to RAM."
 mkdir -p /mnt/tmpfs${CNTLOOP}
 mount -t tmpfs -o size=${SIZEONEBASEKtmpfs}k tmpfs /mnt/tmpfs${CNTLOOP} #121128
 sync; sleep .1
 cp -af "$ONEEXTRA" /mnt/tmpfs${CNTLOOP} &
 copy2ram_progress_func
 export RAMSIZE=$(($RAMSIZE - $SIZEONEBASEK)) #110106
 echo -en " ${purple}R${NC}" >/dev/console # R=copy2ram
 sync; sleep .1
 losetup /dev/loop${CNTLOOP} /mnt/tmpfs${CNTLOOP}/${ONEBASE}
 LOOP_RET=$? #110127
 ONEBASE="$ONEBASELNK" #110127 in case ONEEXTRA is a relative link, record it in BOOTCONFIG later
 return $LOOP_RET #110127
else # mount in place
 ONEBASE="$ONEBASELNK" #110127
 echo -en " M" >/dev/console # M=mounted in place
 echo " mounting."
 sync
 losetup /dev/loop${CNTLOOP} $ONEEXTRA
 return $?
fi

} # End layer_extra_sfs_func

df

ps running lighthouse in overlay is still experimental as it mostly uses a modified WoofCE init script. Noautosave is not yet incorporated. Aufs is the default layering file system.

[dimkr]

Hi Dimkr. Noautosave forces the event manager to keep all changes in pup_rw no matter what media lighthouse is booted from. The following may be overkill but...

Thanks, this makes perfect sense. I'm trying to reduce the number of boot options, PUPMODEs, etc' in my woof-CE fork. Currently it's only PUPMODE 5, 12 or 13 (without periodic saving - only at shutdown or on user request), and I'm looking for a clean way to implement shutdown without any save/no save prompts for users interested in an "immutable" but customized Puppy. I think I'm looking for something similar to pfix=noautosave.

[Clarity]

What is the script in the ISO.zip for?

Lighthouse v900.jpg (14.15 KiB) Viewed 1215 times

[Clarity]

Just a comment: This new v900 is different from the old v900 (otherwise it would not have been presented to us).

But, it still has the same name as the old. Would it be prudent, in the future to name updates with a updated version number?

Reason: Some of us keep all ISO files in a single folder on our system. Same name updates 'overlay' the old version. Thus the ability to compare is lost.

Hope this is reasonable

P.S. If this comment is vague, I draw attention to FD which when a need to replace its older version, it releases with a newer version to avoid confusion. For example they released v900...then when updated, they released v901 as the update...and so on.

Just a comment.

[Dry Falls]

In the directory ISO, there is also an md5 file. update-isolist recalculates the md5 of the iso's present and creats a PKGLIST file which I renamed to the date the iso was made. That tells you which version you have. Each update supersedes the previous so there will only ever be one iso unless I do something different in the future, and that version will have a different name.

ps., Fatdog is not a rolling release. That is to say, it is a stable release. While not technically "rolling" Slackware-current is developmental/date-sensitive prior to the official (stable) version release. You are free to rename the iso to anything you wish when you download it.

When Slackware releases 15.1, lighthouse will bump it's version number.

Hope that helps,

df

[Dry Falls]

Updated, reorganized and uploaded Just-Lighthouse64-900 repo. See first post for links to iso, packages and sfs addons.

Just in case, I uploaded the Fatdog kernel to /packages/BASE/kernels/k6.1.9fd.tar.xz which includes a huge firmware set and can be dropped into your frugal installed lighthouse. This is a nice kernel (thanks fatdog team). Otherwise, try the fdrive if EFI boot is not cutting it. The official Slackware firmware package is close to 500Mb. I think that would be a last resort.

df

[vektor_alian]

Hi Dry Falls

Thank you for continuing this cool project. I used it a long time ago as 32 bit before that jerk with the ID10T error invented 64 bit.

I just hit my quota with Mega so I will wait to download the rest later.

Vektor

[Clarity]

Hello @Dry Falls
I have 3 different versions of v900 from you. When reporting what do you recommend as how to differentiate when all are numbered v900?

Could a suffix addition be appropriate from you on these?

Curious

[Dry Falls]

Hello @Dry Falls
I have 3 different versions of v900 from you. When reporting what do you recommend as how to differentiate when all are numbered v900?

Could a suffix addition be appropriate from you on these?

Curious

As I noted before, slackware-current is a moving target. Right-click --> Properties will give a date for the sfs-files or iso. There are also md5sums recorded, also available as a right-click function. Each new upload supersedes the previous, so you can delete the old. If you download the packages and sfs directories to your storage media, symlink them to /var/www in your running system. Then <slackpkg upgrade-all> will take care of installation.

If the internet worked like it did when we were 20 years younger, it would be a simple thing to notify the user which update is available and rsync could take care of the rest. Alas, I don't have a paid account anywhere so the user will have to keep his/her own clone organized -- that is, if there actually were any testers or users. Sorry. As I also stated in the opening posts, I'm just trying to keep this old dog alive and available to others.

df

[Dry Falls]

Updated and uploaded Just-Lighthouse64-900 repo. See first post for links to iso, packages and sfs addons. Delta patch for last iso.

[Dry Falls]

Updated and uploaded Just-Lighthouse64-900 repo. See first post for links to iso, packages and sfs addons. New iso. Same kernel (6.1.58) but has tested favorably with fatdog and ozsouth latest builds.

df