FRU_mini_jammy_wayland00.sh

[wiak]

FRU_mini_jammy_wayland00.sh is just a simple single script to build a pretty minimal FirstRib/KL mini_jammy distro containing Wayland Sway (like i3 tiling window manager).
Remove dummy tar and make it executable before use. Read the following text carefully before, otherwise, simply running the build script in empty director such as /KL_wee_jammySway

Really just for fun or very basic experimenting with Wayland using Sway tiling manager.
Hardly any apps included. Basically just Midnight Commander (mc) as filemanager for now, which means editor mcedit is also available.
If you wanting an all-singing-all-dancing-with-sound and so on, this isn't it. Use something like the KL Fedora build, but with GNOME and you'll be happier if that's what you want.
Of course you can add whatever bigger apps you wish via package manager apt, and save-on-demand (when in default FirstRib RAM2 mode) via command: snapmergepuppy

NOTE WELL: The build uses Ubuntu debootstrap for base build. I had a problem with that because debootstrap turns out to be fussy in that it needs the build partition mounted with noexec and nodev options and Thunar mounted mine as exec, dev, so build failed. You can check with 'mount' command how your partition is mounted. I thus needed to run the following prior to using this build script to make the build partition on my system mounted noexec,nodev:

Code: Select all

sudo mount -i -o remount,exec,dev </dev/partition>

On my system /dev/partition was /dev/nvme0n1p8. Yours will most likely be named very differently (e.g. /dev/sda3 or whatever you are using). DISCLAIMER: all system script work is at your own risk of course!... but no problem when I did this

Once you are sure your build partition is mounted noexec,nodev (it might already be of course), just run the build command:

Code: Select all

./FRU_mini_jammy_wayland00.sh

be patient, and let it build!!!... NOTE: This first builds a mini-void linux system inside which the debootstrap is then run in a chroot. If you later want to rebuild, just keep the little void linux firstrib_rootfsDBTSTAP directory and it won't need to be rebuilt again (you can delete it later any time...). In fact to do a rebuild, you just need to remove/delete the main firstrib_rootfs directory (or sfs) and leave everything else already downloaded - the script doesn't bother redownloading them again then.

Once build complete, simply run

Code: Select all

./wd_grubconfig

per usual with FR-builds to get accurate grub stanza for booting.

IMPORTANT: On booting, login as user spot (or sway won't work without further effort). User: spot Password: spot (Note that user root has passwd root, but spot is in sudo group anyway).

To pop up terminal in Sway (starts fullscreen) user key combination Super + Enter, and then Ctrl-D or exit to close the terminal. Opening more terminals similarly will tile them...
In terminal, to reboot use: sudo reboot -f

Since Sway is a drop in replacement of i3 tiling manager (albeit Sway is for Wayland) the following reference card for i3 also applies to Sway usage: https://i3wm.org/docs/refcard.html

If you want to play with a very simple stacking Wayland manager instead, just sudo apt install weston, which won't add much to the size of the distro, and start weston after login by simply entering command: weston
========================================================

In Case You First Simply Want To Download All The Pieces:

If you first want to simply download all the pieces, uncomment line 37 of the attached FRU_mini_jammy_wayland00.sh script, forcing exit of script at that stage

Code: Select all

#### Remove below comment if you just want the downloaded parts...
#exit

That would allow you to add the installation of extra apps to the f_00 plug file.

On re-running it, the component parts are not re-downloaded again since already there...

You can also edit FRU_mini_jammy_wayland00.sh script to change what it does with the completed firstrib_rootfs by commenting out default mksquashfs line and uncommenting lines below per the script-contained info:

Code: Select all

# Squash up the rootfs and number the layer ready for booting
mksquashfs firstrib_rootfs/ 07firstrib_rootfs.sfs

# Alternatively you can comment out the above line and uncomment the following:
#mv firstrib_rootfs 07firstrib_rootfs

# or alternatively, you can make a pseudo-full-install, that will allow direct updates:
#mkdir -p 07dummy
#rm -rf upper_changes  # BE CAREFUL. Assuming new install so upper_changes should not exist anyway
#mv firstrib_rootfs upper_changes

z

For some detail on how such KL builds work you can refer to: https://forum.puppylinux.com/viewtopic. ... 487#p98487

[fredx181]

The build uses Ubuntu debootstrap for base build. I had a problem with that because debootstrap turns out to be fussy in that it needs the build partition mounted with noexec and nodev options and

I think (but could be wrong) that it's also "chroot" that won't run on a noexec device.

[wiak]

The build uses Ubuntu debootstrap for base build. I had a problem with that because debootstrap turns out to be fussy in that it needs the build partition mounted with noexec and nodev options and

I think (but could be wrong) that it's also "chroot" that won't run on a noexec device.

First of all, I don't have the debootstrap failing issue at all if I boot into a KL distro. Turns out it only happens for me when I'm using my full-installed Linux Mint, which doesn't by default allow root user log in, so I am logged in as user spot (who has sudo rights). Then as logged in user spot I get the weird debootstrap fail cos of noexec, nodev on partition, but chroot still working fine.

Aside from debootstrap needing noexec, I find, when using Linux Mint and leaving partition as noexec (as Mint mounts it via thunar) that chroot itself works fine: I can chroot into the built filesystem and run the likes of apt install without issue (and that is with my partition mounted noexec and nodev...). I realise though that my understanding of noexec (from mount man pages) musn't be correct or I would have wondered how anything worked with noexec on the partition...

So in practice, if person using Puppy or KL or DebianDogs as host, I don't expect the issue will arise for most people. I only mentioned it for those like me who are using something like Linux Mint as normal user, which mounts the partition in that noexec way. Not sure why Linux Mint mounts things that way, but doesn't usually have any negative effects on what I use.