'WeeDogged' Manjaro XFCE

[wiak]

@gabtech Glad that worked for you. Did you use the external w_init or modified the internal to initrd.gz one?

@wiak the filemnt set as run action works great but the notifications on mounting shows an empty box and also an empty text field in the notification box. I might need to install a dependency for the message to render correctly.

I've seen that... I'll have to double-check because I haven't tried it for a while. I think it used to be libglade missing (also not in official Arch Linux repos anymore). I suspect the filemnt program calls a GTK2+ notification splash of some sort or other so filemnt should be modified or more likely the splash program to make it work.

However, I'm not sure until I check, if that is the reason and I'm in WDL_FossaPup64 at this exact moment (forgot to change my menu.lst this morning after the experiments last night...) and don't thus have that filemnt addon module till I reboot in WDL_Arch64.

EDIT: yes, it is the included in sfs gtkdialog-splash program needing now obsolete libglade libs:

Code: Select all

[root@bootstrap papa]# gtkdialog-splash 'hi'

/tmp/yaf-splash: error while loading shared libraries: libglade-2.0.so.0: cannot open shared object file: No such file or directory

Similarly, pupdialog needs libglade libs. I've never looked at either gtkdialog-splash or pupdialog code to see how they are implemented.

I'll modify the 10gtkdialogGTK3_filemnt64.sfs to not use that for the splash messages (or I'll modify the gtkdialog-splash is maybe easiest), and re-upload once I do that. I didn't notice the missing splash before because my system had a copy of libglade libs on it (libglade is still available from Arch AUR).

Good to hear you are testing a new WDL_Void - but when you say build_firstrib_rootfs-latest.sh build script, do you mean the very latest build_firstrib_rootfs-400rc1.sh version, which I sent you I think whilst preparing that and the rest for github site?

wiak

[rockedge]

@wiak Yes, WeeDog-Void's firstrib_rootfs was built using build_firstrib_rootfs-400rc1.sh.

What I am testing out is how does just grabbing the 01firstrib_rootfs.sfs (or as in my case, also an uncompressed version) from a known operating WeeDog-Void (64 bit) built completely by both the step 1 and step 2 build scripts, and setting up a frugal install directory and use the skeleton initrd.gz. Replacing the original script built initrd. In this test it I used a known working system.

Next test will be build a brand new firstrib_rootfs using the Void plug file and go right to the initrd-skeleton.gz.

Where is the tool that converted the Puppy Linux zdrv.sfs to work with WeeDog so I can use a huge kernel from Puppy Linux?

I'll have to track that down in the forum(s) or just copy the kernel modules into the initrd-skeleton.gz. I also will try to shrink the initrd.gz with Fred's script. It is 76 M currently.

EDIT: After running Fred's script the initrd.gz has shrunk from 76 M to 15 M and boots normally. Although I don't see any booting speed differences between the 76 M and the 15 M versions on this particular machine.

[gabtech]

@wiak

I used external w_init, thanks.

[wiak]

EDIT: After running Fred's script the initrd.gz has shrunk from 76 M to 15 M and boots normally. Although I don't see any booting speed differences between the 76 M and the 15 M versions on this particular machine.

I've never noticed much difference between using a small initrd or a large one. I suppose just the small extra time for kernel to load it into RAM, which isn't a lot for 80MB on most drives nowadays. At switch_root time the kernel clears out most of the RAM except mounted parts still needed (and thats same for small intird and big one, so no difference at the end of the day).

Of course it is convenient to have a small initrd.gz and helps keep overall download size smaller, which is proportionally important if the distro itself is small. Puppy huge kernel builds certainly help there (pity most of them don't include inbuilt overlayfs support or would be no modules needed by the initrd, but as it stands that one module (kernal/fs/overlayfs/overlay.ko is needed...

It's also a 'pity' that Puppy's zdrv doesn't 'only' contain lib/modules; there are a few other Puppy bits and pieces in there. The biggest annoyance is that Puppy (and Debian/Ubuntu-based distros) have until recently at least used /lib/modules rather than the likes of Arch and Void who make pretty much all lib directories symlinks to /usr/lib, so the modules end up in /usr/lib/modules, so that script you refer to that converted zdrv mainly does that conversion. I believe (I think I read) that Debian/Ubuntu are now moving to that same /usr/lib arrangement as Arch and Void and similarly pretty much all bin directories as symlinks to /usr/bin, which ends up being very convenient. No matter what distro root filesystem we are booting, the initrd itself is structured same as a typical Void Linux distro (which is lucky - only really happened because Void Linux was the original and only focus). Have you looked on the dev github site for that zdrv convert script - it might be there - I'll have to look into that too to see if still useful or can be made more useful. I'm gradually renaming all WeeDog special scripts to begin with name wd_XXX. Since they are all tiny it is convenient to always provide a copy of them (such as modify_initrd_gz.sh becoming wd_modify_initrd.gz.sh, and others such as wd_mount, and I should really rename wiakwifi to wd_wifi for consistency and keeps them altogether when looking for what's available with the ls command.

But yes, Puppy huge kernel and specially constructed 00modules.sfs is very handy for making a really small bootable distro, and automatically allows the initrd access to overlay module without having to copy any modules into the initrd at all (used to call it 00firmware_modules.sfs but it is only the modules that are required and only the 00 is important in the name - in recent initrd 00modules/ can also be left as an uncompressed directory if user wishes - convenient sometimes). Still, pity zdrv.sfs itself didn't just contain the Puppy modules in /usr/lib/modules form and then would have just needed to rename it 00zdrv.sfs, but of course Puppy zdrv wasn't designed with WeeDog builds in mind!

re: filemnt. I actually think that program is equally useful at console so shouldn't be using a graphical-based splash anyway. Then again, trickier to implement than sounds - maybe a simple gxmessage (or even xmessage) or Xdialog would do and be easier. Mind you I have a habit of just starting up an xterm (or whatever the system terminal is like in desktop file Terminal=true with 'read' command or 'sleep' to hold it prior to closing) and printf message to it and if xterm not found could just OR printf message, which would go to console I guess... with sleep after. Not fancy - I know, but good enough for me. I'll look into replacing the current splash to at least work without libglade anyway.

wiak

[wiak]

@wiak the filemnt set as run action works great but the notifications on mounting shows an empty box and also an empty text field in the notification box. I might need to install a dependency for the message to render correctly.

@rockedge

Attached is a quickly hacked filemnt (remove dummy tar and chmod +x and place as alternative in /usr/local/bin or wherever you previously had filemnt command).

I'm only concentrating on getting mount and umount to work with Success or Failure message and so on, but without using the usual nice gui splash (which cause an issue because of libglade and GTK3) - so this just uses simple xterm pop-up. You can change the terminal used for pop-up if you wish: just a variable near the top of the filemnt script I've called vterminal="xterm", so make that whatever else works and of course you can use terminal geometry and colour tricks to get things looking better. As I say, I've not addressed other issues - for example traditional Puppy/Dog sfs_load was for aufs so irrelevant with WeeDog, but that section of code may need to be disabled prior to me putting new filemnt in the 10gtkdialogGTK3_filemnt64.sfs.

Anyway, apart from the spartan looks, please let me know if it works a wee bit better than previous.

EDIT: NOTE: In the one I finally put in 10gtkdialog....sfs I'll likely use something like gxmessage, or even Xdialog, if it is available and no issues, but I am also looking to basically have filemnt working at console level with commandline filemanagers like mc, and when in GUI, in a simple system Xdialog might not be installed buy some terminal is likely to be so I like that as a kind of base splash method. Not so keen on fancy yad or gtkdialog type splashes myself - too many dependencies and thus too much to go wrong... Filemnt is basically a developers tool afterall - so don't need it to be ultra-glamorous IMO! (not that it's splash effect was ever particularly glam).

Code: Select all

gxmessage -borderless -center -bg orange -timeout 3 "hello splash"

or even (fewer dependencies but uglier):

Code: Select all

xmessage -center -bg orange -timeout 3 "hello splash"

or

Code: Select all

Xdialog --center --no-buttons   --interval 3 --infobox  "hello splash" 0 0

or at console:

Code: Select all

TERM=vt100 dialog --infobox  "hello splash" 0 0

For dialog or Xdialog need an --rc-file to specify background colours I think.

wiak

[wiak]

IMPORTANT if you are using 10gtkdialogGTK3_filemnt64.sfs

I have uploaded a new version that gets rid of the issue with pupmessage and gtkdialog-splash not working without libglade libraries.

You can download this new/improved one using the same get_WDL_10gtkdialogGTK3_filemnt64_sfs.sh.tar (with dummy tar removed and made executable with chmod +x). If you don't have that get_WDL... script you can fetch it at same place as before, here: https://weedoglinux.rockedge.org/viewto ... p=355#p355

Instead of using pupmessage and gtkdialog-splash scripts I have opted to use gxmessage, so you must have that installed on your system, but unlike the above it is commonly available from most (probably all) distros' package managers.

Note, I've also modified filemnt command to also work at a console (non-X) as long as you have one of the following filemanagers installed: Midnight Commander (mc), nnn, vifm, or lfm. That list could be added to of course. I have only tested this new facility with Midnight Commander though. Usage at console (to get to console I used ctrl-alt-f2 and logged in there in my own WDL_Arch64 distro. Then:

you can mount and iso in (per example Midnight Commander) by entering command: filemnt path_to_where_the_iso_is
Similarly for an sfs file it would be: filemnt path_to_where_the_sfs_file_is
After doing so, Midnight Commander fires up with the uncompressed iso (or sfs) ready for your further manipulations...

NOTE WELL: Since this 10gtkdialogGTK3_filemnt64.sfs is at WDL overlayfs layer 10, make sure any higher layer (including upper_changes DOES NOT) contain any filemnt script since the higher layer one will over-write the lower layer such that you think it is not working! (I made that mistake in testing myself...).

Note also that filemnt contains a function related to shinobar's sfs_load, which was designed for aufs - though I've fixed the related messaging in filemnt for that section too (to use gxmessage) I do not know what will happen if using an overlayfs-capable sfs-load (such as Fredx181 uses in dd-bullseye - I have not tested that since my own interest is in getting iso and sfs files to auto-open on filemanager click (or at console)

Let me know how it goes if you test it.

wiak

[rockedge]

@wiak something happened when I tried out the new version of filemnt and the WDL-Void (jwm - rox) totally crashed the moment I clicked on an SFS. The system completely froze and required a hard stop. Not quite sure if that was to blame though. I will create a backup and try it again!

[wiak]

@wiak something happened when I tried out the new version of filemnt and the WDL-Void (jwm - rox) totally crashed the moment I clicked on an SFS. The system completely froze and required a hard stop. Not quite sure if that was to blame though. I will create a backup and try it again!

Yes, keep me posted about it.

It's working fine for me. Using it just now on this WDL_Arch64 system. The only change in it is the use of gxmessage really (along with test if TERM=linux to allow it to work in a console). Filemnt is just a script and I haven't changed anything else supplied in the sfs.

I do have one printf statement to adjust sometime (not going to newline), but its a very minor matter.

As I said on posting it, make sure you try it with a new upper_changes in case something in there overwrite the 10gtkdialog... layer, and if you do have any other sfs layers above layer 10 then make sure no files in there that will overwrite the 10gtkdialogGTK3_filemnt64.sfs either. I originally forgot these matters - never crashed my system in any way but I kept getting older filemnt behaviour (because older filemnt was in one of the higher layers...).

Most of the utils that filemnt calls up are old Puppy ones, which I haven't changed at all. I can't guarantee it though with Void Linux or any other system, but fine in my own tests (though only tried with WDL_Arch64 because that's all I have on here at the moment).

Seems to have been quite a few new downloads, but no-one else indicated any issue as yet.

wiak

[gabtech]

I successfully weedogged fred's Fossadog.

[wiak]

I successfully weedogged fred's Fossadog.

Well that has a pure (debootstrap) based rootfilesystem, so you probably found that a bit easier to WD than Puppy. Fine if you wanted to use WDL initrd with it, to use overlayfs say (since default FossaDog uses aufs). However, more generally, FossaDog (unlike Puppy) has ability to use multiple numbered squashfs addon layers anyway, so no advantage on the whole, and some disadvantage since aufs allows Puppy form of sfs_load, whereas overlayfs needs alternative tinycorelinux-like symlink method (such as fredx181 uses with dd-bullseye). And per usual some of the distro-provided utility scripts will likely need modified to work with WDL layering structure. Still good to know you managed. Interesting to know what distros it works with and doesn't work with.

The WeeDogLinux build_firstrib_rootfs script is itself able to build a firstrib_rootfs for Ubuntu, Debian, or Devuan (also using debootstrap to start that off), but I haven't developed any systems with that since DebianDogs already do that so well. Still, it is an alternative for someone who wants to build their own Ubuntu/Debian/Devuan build plugin from scratch (i.e. starting from stage where debootstrap part has completed).

[recobayu]

My grub4dos menu entry: (replace "12e1e33f-47a6-4979-b13a-404e60f746b9" with your UUID)

Code: Select all

title WDL_manjaXFCE
find --set-root uuid () 12e1e33f-47a6-4979-b13a-404e60f746b9
kernel /WDL_manjaXFCE/vmlinuz-5.13-x86_64 w_bootfrom=UUID=12e1e33f-47a6-4979-b13a-404e60f746b9=/WDL_manjaXFCE
initrd /WDL_manjaXFCE/initrd.gz

Hi @fredx181. How to create menu.lst if i use manjaro? I do not see a grub4dosconfig on it.
Thank you.

[fredx181]

My grub4dos menu entry: (replace "12e1e33f-47a6-4979-b13a-404e60f746b9" with your UUID)

Code: Select all

title WDL_manjaXFCE
find --set-root uuid () 12e1e33f-47a6-4979-b13a-404e60f746b9
kernel /WDL_manjaXFCE/vmlinuz-5.13-x86_64 w_bootfrom=UUID=12e1e33f-47a6-4979-b13a-404e60f746b9=/WDL_manjaXFCE
initrd /WDL_manjaXFCE/initrd.gz

Hi @fredx181. How to create menu.lst if i use manjaro? I do not see a grub4dosconfig on it.
Thank you.

If you have an existing menu.lst on a bootable drive you have, then just add the above stanza (indeed no grub4dosconfig on WDL-manjaro), if not, I normally use this: viewtopic.php?f=46&t=464 to make a drive bootable and modify the menu.lst to my needs then.
edit: but perhaps @wiak can provide an easier or better solution.

[recobayu]

Thank you @fredx181. Now I can boot using this flashdisk. But now I have a problem. Kernel panic. I follow your step.

[fredx181]

Thank you @fredx181. Now I can boot using this flashdisk. But now I have a problem. Kernel panic. I follow your step.

I'd say this has not to with the bootloader, could it be that you missed one or more steps in how you did setup WeeDogged Manjaro ?
We have no insight in how you did, perhaps if you can write about it, then more chance you will get help.
Most of the times when I had a kernel panic "not syncing" it had to do with vmlinuz not matching with the initrd.

[recobayu]

Alhamdulillah, finally I can do this.
I use fossadog to do all step from @fredx181, and it works. The previous, I use manjaro XFCE, but got kernel panic.
Yeay! Thank you, @wiak and @fredx181.
Could I install app and remaster this wdl_manjaxfce?

Edit: Yes. I can install app from pamac. And after I reboot, the system still to the last I change. So WDL is automatically save it.
Thank you.

[wiak]

Alhamdulillah, finally I can do this.

That's good to hear. Hope you find it useful.

wiak

[recobayu]

Yes of course.
Wiak, is there an instructable for making WDL arch linux like WDL_manjaroxfce?
Thank you.

[wiak]

<-- Back to WDL Cheatsheet menu: viewtopic.php?p=36426#p36426

Wiak, is there an instructable for making WDL arch linux like WDL_manjaroxfce?

Here's what I did (using Fredx181 WDL_manjaXFCE howto modified for official Arch Linux iso so most words are quotes from Fred...); hope it helps others (not sure if I made it over-complicated or not). Note that the official Arch Linux ISO I used doesn't come with X installed:

EDIT: See here for creating a much smaller initrd.gz: viewtopic.php?p=36345#p36345

- Create "WDL_arch" folder on ext4 partition
- Download arch ISO and mount it. I used commandline-only iso from here: https://mirror.arizona.edu/archlinux/is ... x86_64.iso
- From mountpoint, copy the file "/arch/X86_64/airootfs.sfs" in ISO to "WDL_arch" folder, and
- copy the linux kernel from "/arch/boot/X86_64/vmlinuz-linux" in ISO to "WDL_arch" folder
Done that, it's all I needed from the arch ISO (you may or may not need more for EFI boot depending what you already use to boot other distros on your system).
- Rename airootfs.sfs to 08airootfs.sfs (that's the only sfs file you need to boot this arch linux official root filesystem)
- Download get_WDLskelinitrd_kmod400rc1.sh.tar from here: https://weedoglinux.rockedge.org/viewto ... p=355#p355 (remove dummy tar and chmod +x). IMPORTANT: NOTE that this script downloads a different skeleton initrd.gz from the one used for manjaro XFCE. This larger/special initrd.gz can handle .zst compressed modules as used in official arch distro /usr/lib/modules, so is needed in this case.
- Run get_WDLskelinitrd_kmod400rc1.sh in "WDL_arch" , then script: modify_initrd_gz.sh and initrd: initrd_kmod_v400rc1.gz will appear
- Run ./modify_initrd_gz.sh initrd_kmod_v400rc1.gz from terminal in "WDL_arch"
- A skeleton folder "initrd_kmod_v400rc1_decompressed" will appear, leave terminal open for later
- Mount 08airootfs.sfs
- Copy folder inside usr/lib/modules from mounted 08airootfs.sfs (e.g. 5.13.13-arch1-1) to: usr/lib/modules inside "initrd_kmod_v400rc1_decompressed" dir (or: see EDIT above)
- In terminal that's left open (see above) type: exit
- A new date stamped initrd will be created (including the copied kernel modules), when done rename to "initrd.gz" (or leave it as is and point to that name in bootloader config)

How my "WDL_arch" folder looks (not sure if you need the extra UEFI stuff per Fred's manjaro XFCE howto):

WDL_arch_folder_contents.png (16.73 KiB) Viewed 3590 times

Optional: get the "10gtkdialogGTK3_filemnt64.sfs", see here the https://weedoglinux.rockedge.org/viewto ... p=355#p355 and place also inside "WDL_manjaXFCE" folder

My grub4dos menu entry: (replace "b812c597-8099-4bee-9bb3-8b9c10f1e902" with your UUID)

Code: Select all

title WDL_arch (sda4)
find --set-root uuid () b812c597-8099-4bee-9bb3-8b9c10f1e902
kernel /WDL_arch/vmlinuz-linux w_bootfrom=UUID=b812c597-8099-4bee-9bb3-8b9c10f1e902=/WDL_arch
initrd /WDL_arch/initrd.gz

As you can see, the procedure is very very similar no matter what live distro you are using for making the WDL version. Only major difference for Arch Linux is the special initrd.gz required because Arch uses zst compressed modules. And of course it's a different main rootfs sfs file (only one in this case: airootfs.sfs).

NOTE that this howto is for WeeDogging an official Arch Linux root filesystem which only gives a commanline login (no X or Wayland GUI). This is different from the method I use to construct my usual WDL_Arch64, which is built using WeeDogLinux build_firstrib_rootfs script via archbootstrap script and a specially constructed build plugin that produces a full X desktop using openbox/tint2/pcmanfm combination (or can be easily modified for full Wayland system). You can find build_firstrib_rootfs script here: viewtopic.php?p=37093#p37093
I haven't released latest WDL_Arch f_plugin for use with that yet, but there is an exemplar f_plugin by rockedge for a WDL_Void Linux build here: viewtopic.php?p=37122#p37122

wiak

[ronriel]

Hi wiak,
I tried diferrent distros (mint, linuxfx, elementary) and they successfully booted. However, I always get stuck on the login screen. The distro's default username and password does nothing.
How can I bypass the login screen like in Manjaro?

-ronriel

[rockedge]

@ronriel I think we'll need to track down where the login screen package is being started and comment it out. What seems to be happening also is the setting of the root user and root user password is not occurring during the boot as we are setting it up. Can you try to use the mount / umount scripts to mount the distro's rootfs directory and set the root password manually?

These are some thoughts and I have not tried out weedogging Mint yet to see how to get past the login prompt screen. Best bet is to try to set the root password or create a user using the mount rootfs scripts before trying to boot the distro.

[wiak]

Haven't heard back from ronriel. We should document how to use mount_chroot to set password, specially now with new version that allows specifying name including layer number of the rootfs. Easier than trying to debug how upstream distro sets login password in first case.

[rockedge]

I agree fully @wiak. Good idea to document the setting of the password via the mount/umount scripts.

I am going to try out some tests on WDL-manjaro as well as the Ubuntu Kylin "WeeDogged" and try out some ways to set the root and user "weedog" for a smoother set up.

[ronriel]

Hi wiak, rockedge,
Thanks for the reply. I would really want to try your suggestions but I have no idea how set the root password from a distro's mounted rootfs.

-ronriel

[wiak]

Added auto WDL frugal install of Pop!_OS to weedogit.sh build script (previously just allowed WDL frugal initrd install of vanilladpup64, which installs fast and works fine, but Pop!_OS is full-on GNOME so probably slow if you don't have powerful system (I don't know cos stupidly built it on very slow usb2 stick so no idea of its actual performance if installed on sensible media): viewtopic.php?p=49926#p49926

Will add Manjaro XFCE auto install to weedogit.sh script soon, but before that will come EndeavourOS XFCE, which I've previously tried, found it fast and great to use - really liked it (did a manual WDL manual install using WDL skeleton initrd.gz back then).