Puppy Linux Discussion Forum

fatdoguser wrote: Tue Mar 19, 2024 9:48 am

@Clarity As I recall it was simple enough. ...

Yes! That why I thought there 'might' be a simple tool already within.

No problem on my end, ATM.

Hi @fatdog and team..
Thank you for this very fast boot of fatdog.
I use this option boot menu:

title fatdog (sda3/fatdog)
  find --set-root uuid () 1785ce6e-d396-4a26-bec7-c850512b8179
  kernel /fatdog/vmlinuz mergeinitrd1=local:/fatdog/initrd rootfstype=ramfs 
  initrd /fatdog/initrd-nano

I really watch my stopwatch and it only takes 28 second to boot into my desktop. Really fast on my dell latitude e6400. It is still using old hard disk.
I hope this initrd-nano also can be implement on puppy linux.
Thank you very much, @fatdog and team.

Yes, boots very fast for me from frugal install using initrd-nano too.

Considering it includes LibreOffice components it is remarkably small and powerful. Size may not always be important, but sometimes very handy to have a small distro with many useful utilities: FatDog seems to fit that portable need better than most any other distro nowadays.

wiak wrote: Sun Apr 07, 2024 4:48 am

very handy to have a small distro with many useful utilities: FatDog seems to fit that portable need better than most any other distro nowadays.

Yes!!!
a high-quality distro
recommended

How to make initrd-nano in puppy linux?

recobayu wrote: Sun Apr 07, 2024 1:44 pm

How to make initrd-nano in puppy linux?

Most Puppy Linux initrd.gz are around 2312 K compressed and decompressed is 4192 K.

rockedge wrote: Sun Apr 07, 2024 3:34 pm

recobayu wrote: Sun Apr 07, 2024 1:44 pm

How to make initrd-nano in puppy linux?

Most Puppy Linux initrd.gz are around 2312 K compressed and decompressed is 4192 K.

Of course it isn't the size of the initrd really; well, the huge-style initrd that embeds the underlying main rootfilesystem, will be slow to load of course. (FR/KL can make/use similar huge initrd structure by the way. At least the FR initrd is designed to handle such constructs, but never been a focus in terms of a user installation tool/method).

Rather it is how efficiently you can mount all the layers and start whatever services and network and load the desktop. Not much you can do about it sometimes though (e.g. xfce might start up lots of stuff and take time doing it, or some systems have complex init system arrangements) - FatDog clearly keeps its init system lean and fast, which is very nice of course. That's the kind of advantage used to be seen in Puppy more generally - a simple fast sysv init system, but FatDog seems to be doing it all a bit better these days IMO.

Disadvantages in going it alone too of course - limited packages - more maintenance required to keep distro alive so lots of dev time between releases, but FatDog team keep doing a great job. Puppy on the other hand suffers from no solid dev team really working on its very old and hacked woof-CE code base. Seems to me that FatDog carries the Puppy-type distro torch these days and does a good job of that thus far. Everyone gets older though... All projects need new blood in terms of active developers because even the most experienced developers eventually want to put their feet up and do something else with their time... The word used in Puppy world: Do-ocracy seems to me to be more of a warning than an asset. Really it suggests that if no-one does the work, nothing will be done. Hence the ongoing importance of a continuing solid dev team, which is no-doubt what keeps FatDog moving forward over time.

I say soon we begin to address the overall Puppy Linux woof-CE and start looking into the initrd design. I see good things around the FatDog project and definitely those FR has to offer that would take Puppy up a level.

wiak wrote:

Do-ocracy seems to me to be more of a warning than an asset.

Does sound a wee bit like a threat.

@fatdog is the ONLY forum distro which OOTB can be booted as a frugal (no matter if used via its ISO file booting or via a manual setup by the users) as weill as running within KVM VMs AND will also boot from traditional PXE method or via the simplified PXE ISO boot method that Ventoy offers.

One can also, without using a ISO file launcher (for example ISObooter/SG2D/Ventoy), boot directly from its ISO file via a GRUB2 stanza, as well.

It just works with everything I have booted it from over the recent years.

It has only 2 shortcoming that WoofCE and KL provide for their community. Those distros cater to an audience making it extremely easy for novice or experienced users tp boot their distros to desktop. WoofCE offer a guide for persistence (SAVESPEC present in the booting folder). KLs offer clear 'sample' boot stanzas. These distros negate the need for any user to tamper with the menu to go OOTB to desktop with persistence. As such these reduce the chances for user error(s) going to desktop.

For FATDOG, the knowledgeable user must interrupt the boot menu and guide persistence management; thus no guide file NOR pre-defined guide menus. Oh, we know that we can allow it to default to root use, but, if one wants to keep all of the sessions in a named folder, the ability does not exist, currently.

FD is fast and well designed.

Further to the Chinese txzes (version 321.0.6) for Fatdog64-901 released on Oct 15, 2023, I have upgraded them to version 321.6.1 to enable Chinese support on more applications. Known limitations for version 321.6.1:

1. No Chinese support in urxvt for fcitx, gcin, hime, ibus, rime and scim. To enable Chinese support in console, I have added lxterm in all 7 input platforms.

2. No Chinese support in yong for geany, LibreOffice 7.5.2.2 and seamonkey 2.53.15

I. icake language txzes:
I have created 7 half-Chinese language txzes for fatdog64-901:
fcitx Chinese input platform: fcitx64_4.2.9-en-zh-bionic-321.6.1.txz (26 mb)
gcin Chinese input platform: gcin64_2.9.0-en-zh-bionic-321.6.1.txz (10 mb)
hime Chinese input platform: hime64_0.9.11-en-zh-bionic-321.6.1.txz (10 mb)
ibus Chinese input platform: ibus64_1.5.19-en-zh-bionic-321.6.1.txz (56 mb)
rime Chinese input platform: ibus64-rime_1.4.0-en-zh-bionic-321.6.1.txz (79 mb)
scim Chinese input platform: scim64_1.4.18-en-zh-bionic-321.6.1.txz (15 mb)
yong Chinese input platform: yong64_2.5.0-en-zh-bionic-321.6.1.txz (10 mb)

Plus 2 Chinese language txzes each for fatdog64-901:
Simplified Chinese: fatdog64-901-zhcn-321.6.1.txz (4 mb)

Traditional Chinese: fatdog64-901-zhcn-321.6.1.txz (3 mb)

To use:
(a) any 1 of the 7 half-Chinese language txzes will enable you to display and input Chinese in fatdog64-901

(b) the 2 Chinese language txzes will give you Simplified Chinese (zhcn) or Traditional Chinese (zhhk) menus, icon labels, tooltips for fatdog64-901. Please note that all Chinese language pets rely on a suitable half-Chinese language pet already installed to the system to provide Chinese input platform and Chinese fonts. Otherwise the system cannot input Chinese and display Chinese (shown as squares).

II. icake combo txz
I have also created an icake combo txz for fatdog64-901 with all 7 Chinese input platforms above and 3 user interface languages:
icake64-fatdog64-901-combo-est-fghirsy.321.6.1.txz (216 mb)

III. icake combo live iso
I have also remastered 1 icake combo live iso based on fatdog64-901 with all 7 Chinese input platforms above and 3 user interface languages:
icake64-Fatdog64-901-20240503-est-fghirsy.iso (875 mb)

so the total number of different systems created by the above icake combo txz and combo live iso is 21:
21 = 7 Chinese input platforms (fcitx, gcin, hime, ibus, rime, scim or yong) X 3 user interface languages (English, Simplified Chinese and Traditional Chinese)

more information about the fcitx, gcin, hime, ibus, scim and yong txzes, please see: Documentation-and-Tools

As always, a huge thank you @icake for the Chinese language packs and remaster (added link to your post here).

I have just noticed a phenomenon that I consider odd. I have overlooked this as it does NOT affect the system once on desktop, but it probably shouldn't be there OR should be reworded to something like "NO prior sessions found" to better indicate the message's meaning.

When booting FD ISO files, pristine, before arriving at desktop, FD posts a message about "FDsave.ext4 not found".

This occurs by taking the 'default' FD boot menu selection; namely no user changes in the default, topmost menu entry to start the booting of the OS.

Important to note: This message DOES NOT 'seem to' have any operational impact on the running the pristine booted FD.

Clarity wrote: Wed Jun 05, 2024 5:45 am

I have just noticed a phenomenon that I consider odd.

This message has been there in the last 12 years or so, since Fatdog64 600 days.

I have overlooked this as it does NOT affect the system once on desktop, but it probably shouldn't be there OR should be reworded to something like "NO prior sessions found" to better indicate the message's meaning.

No, because ... (read on ...)

When booting FD ISO files, pristine, before arriving at desktop, FD posts a message about "FDsave.ext4 not found". This occurs by taking the 'default' FD boot menu selection; namely no user changes in the default, topmost menu entry to start the booting of the OS.

When you boot with the first menu entry, which is the default boot, Fatdog64 will run with "savefile" mode, that is, it will attempt to load a savefile/savedir. Hence it will emit the message if it cannot find the savefile/savedir.

The "no sessions found" etc is only relevant when you boot Fatdog64 in multisession mode, that is, the third entry. But in this case, missing sessions aren't an error, so there will be no message emitted at all.

Important to note: This message DOES NOT 'seem to' have any operational impact on the running the pristine booted FD.

Correct. If a savefile/savedir cannot be found, the boot will proceed as normal, in pristine mode - which is what it should be.

Fatdog64 902 is released. Please see first post viewtopic.php?t=9544.

FATDOG ISO file boot results is now shown on the forum, here.

After updating from FD 900 to 902 and using my existing save-file/save-folder, I note that
the System Information reports the Distribution as Fatdog64 Linux 900 instead of 902.
The reported Kernel information is correct.
This is only the case where I use the split initrd.
With the large initrd the Distribution is reported correctly.
(using the same save-file/save-folder in both cases)
On creating a fresh save-file in split initrd mode, the Distribution is reported correctly
as Fatdog64 Linux 902.
No big deal, just reporting the observation.
Regards proebler

Thanks for the report @proebler.
If you don't mind, can you please run the following, on the problematic setup:

find /aufs -name os-release -o -name fatdog-version

This basically will find out where the files where hardinfo get the information from, are located. They should normally be located in /aufs/pup_ro, but it will be interesting where else these files exist.

# find /aufs -name os-release -o -name fatdog-version
/aufs/pup_ro/etc/fatdog-version
/aufs/pup_ro/etc/os-release
# 

see more in the attached file

I have now discovered the cause.
Two things in combination.
The principal cause, an error in the menu.lst:

 kernel /FD_split/vmlinuz basefs=uuid:3a4f57a9-44b0-4a75-9566-56e6f55dcdec:/.FD_split/fd64.sfs savefile=ram:uuid:3a4f57a9-44b0-4a75-9566-56e6f55dcdec:/.FD_split/fd64save dofsck

basefs where it correctly should be basesfs

That, in combination with a fatdog64.sfs from FD900 left in / of the partition.

What happens with this combination is, that during booting the 'basefs' is ignored and the fatdog64.sfs (from FD900) gets used.

A 'light has gone up'
I was wrong in my assertion back in Oct 2023 viewtopic.php?p=100388#p100388

"I have found that grub4dos tolerates two versions of writing the kernel argument for "basesfs", both 'basesfs=..' and 'basefs=..' equally work."

It was the combination then as well.
Yes, a sort of coincidence, https://forum.puppylinux.com/viewtopic ... 98#p100498

Fatdog64-902 Final was released on Jun 15, 2024 by the fatdog team.

for more information and discussions

download Fatdog64-902.iso (633 mb)

I have created 7 half-Chinese language txzes for fatdog64-902:
fcitx Chinese input platform: fcitx64_4.2.9-en-zh-bionic-321.6.1.txz (26 mb)
gcin Chinese input platform: gcin64_2.9.0-en-zh-bionic-321.6.1.txz (10 mb)
hime Chinese input platform: hime64_0.9.11-en-zh-bionic-321.6.1.txz (10 mb)
ibus Chinese input platform: ibus64_1.5.19-en-zh-bionic-321.6.1.txz (56 mb)
rime Chinese input platform: ibus64-rime_1.4.0-en-zh-bionic-321.6.1.txz (79 mb)
scim Chinese input platform: scim64_1.4.18-en-zh-bionic-321.6.1.txz (15 mb)
yong Chinese input platform: yong64_2.5.0-en-zh-bionic-321.6.1.txz (10 mb)

Plus 2 Chinese language txzes for fatdog64-902:
Simplified Chinese: fatdog64-902-zhcn-321.6.1.txz (4 mb)

Traditional Chinese: fatdog64-902-zhcn-321.6.1.txz (3 mb)

To use:
(a) any 1 of the 7 half-Chinese language txzes will enable you to display and input Chinese in fatdog64-902

(b) the 2 Chinese language txzes will give you Simplified Chinese (zhcn) or Traditional Chinese (zhhk) menus, icon labels, tooltips for fatdog64-902. Please note that all Chinese language pets rely on a suitable half-Chinese language pet already installed to the system to provide Chinese input platform and Chinese fonts. Otherwise the system cannot input Chinese and display Chinese (shown as squares).

more information about the fcitx, gcin, hime, ibus, rime, scim and yong txzes, please see: Documentation-and-Tools

Thank you @icake for your consistent support and persistent service providing Chinese language support for Fatdog64 over the years!

I've added the links to your post from the first post.

---------------

@proebler - thank you for clarifying. I was rather confused myself when the output of your find command looks correct to me (I was hoping it was wrong so I could try to diagnose further). But fortunately you find the problem yourself and thanks for getting back to me so we didn't waste time non-existing bugs.

Fatdog64-903 Final is released. Please see first post.

Note about the size: 902 ISO is about 618MB. 903 ISO is 681 MB, a difference of 63MB. Since 903 is supposedly only a small update, where does this extra "fat" come from?

903 release uses kernel 6.10.2. In this newer kernel, the nouveau driver (for nvidia GPU) needs to use NVIDIA firmware to work successfully with newer cards. This has been the case since kernel 6.7. Hence, we have to include additional NVIDIA firmware (you can find that in /lib/firmware/nvidia), and guess what, the size of this additional firmware stuff is 63MB The cost of progress

If you don't care about this (you don't run nvidia) or don't run the latest hardware (which requires drivers only supported in 6.2 kernel onwards), you can always use LTS (long-term-supported) 6.1.x kernels.

Currently we only have 6.1.90-debtest4 which is used by 902, but in the future we may continue to supply updates to the 6.1.x line as needed; or you can try @ozsouth's aufs non-usrmerge kernels that he updates often.

PS: The decision to go for 6.10.x series is not permanent. The 6.10.x line is most probably a short-lived line, not an LTS line, so on the next release 6.10.x line most probably will have been retired. As such, depending on the situation, when the release is made, and feedback that we receive, we might go with even newer kernel versions, or revert back to 6.1.x series.

Hello! Firstly, I would like to thank you for the new released version of FatDog! I also downloaded and tried using ISO Builder. I downloaded the files 903-pkglist.tar.xz and fatdog64-iso-builder-2024.08.tar.xz (https://distro.ibiblio.org/fatdog/iso/builder/), in order to make the base file (fd64 .sfs) custom. During the download and installation of the packages, there were some error messages (Checking integrity (package name).txz .... FILE MISSING! or UNLISTED or BAD CHECKSUM) resulting in an unusable sfs file. However, Fatdog64-903.iso, it's great!

Dear fatdog team
I was wondering if there is an easy way to update to 903 but keep the 902 kernel.
While in the huge initrd the usrespace sfs and the kernel sfs are distinct, when you install using the small inirtd, as in my case, you only have one sfs with everything in it. I do not know if there is a mechanism/script for kernel change using the huge initrd, but with the small initrd kernel change looks like it will take a lot of manual and error-prone work.
I would think that the one SFS minimizes confusion and messups from the user but you might want to maintain the distinct kernel sfs in small initrd installation too.

@Duprate, thank you for testing. The 903-pkglist was wrong (hence the reference to fatdog-scripts-904). But in addition, ibiblio changed their systems and the repo update mechanism didn't work - hence the BAD CHECKSUM. Both have been corrected now. Please re-download 903-pkglist and try again.

@retiredt00, thank you for the feedback. I will look into it. How did you get the small initrd, did you use the BIOS Fatdog Installer, or created it yourself using fatdog-split-initrd?

-------------------------------------------

While in the huge initrd the usrespace sfs and the kernel sfs are distinct, when you install using the small inirtd, as in my case, you only have one sfs with everything in it.

There are really 3 kinds of "small" initrd, ordered by size (smallest to largest):
a) "nano" initrd, this is basically the initrd without kernel-modules.sfs and basesfs. This is about 19MB for 903 release.
b) "micro" initrd, where only a few bunch of modules are kept in the initrd and the rest are moved to basesfs (this is probably what you've got right now). This will be bigger than the nano.
c) "mini" initrd, where the kernel-modules.sfs are retained, but the basesfs has been removed. This is about 173MB for 903 due to the inclusion of NVIDIA firmware.

(a) is available from fatdog.iso, but it's really easy to create this by hand: remove the fd64.sfs and the kernel-modules.sfs, then click re-pack.
(c) is really easy to create as well, click open an initrd, remove only the fd64.sfs and then click re-pack.
(b) cannot be created by hand easily. Its creation was the original purpose of fatdog-split-initrd.

Nowadays, fatdog-split-initrd can also create (c) in addition to (b), but it still creates (b) by default for historical and compatibility reasons. BIOS Fatdog Installer uses fatdog-split-initrd behind the scenes, hence it also creates (b) by default.

I do not know if there is a mechanism/script for kernel change using the huge initrd,

There are three ways:
a) http://distro.ibiblio.org/fatdog/web/faqs/kernel.html
b) http://distro.ibiblio.org/fatdog/web/fa ... ernel.html
c) Run Fatdog Updater and choose "Update kernel".

but with the small initrd kernel change looks like it will take a lot of manual and error-prone work.

Indeed. The only way to update this, is to grab the initrd from a newer iso, and run it through fatdog-split-initrd to get the new "micro" small initrd and new fd64.sfs. And then update bootloader config to point to the new kernel + new small initrd + new basesfs. It's all manual process (because we don't want to touch bootloader configuration).

I would think that the one SFS minimizes confusion and messups from the user but you might want to maintain the distinct kernel sfs in small initrd installation too.

We already have that, with the "mini" initrd. But to some people, 173MB (or 110MB for 902 release with 6.1.x kernel), isn't exactly small enough. This is one of the reasons why Fatdog Installer still use "micro" by default instead of "mini" despite its easier updatability.

You can actually force Fatdog Installer to create "mini" initrd by running it from terminal like this: SPLIT_MODE=mini fatdog-installer.sh, but newcomer to Fatdog will probably never do it this way.

Since Fatdog Installer now automatically adds "nano" initrd (which is even smaller than "mini") when installing standard huge initrd, many of the reasons for "micro" initrd are no longer relevant. I'm wondering whether we should just switch the default small initrd to "mini" instead of "micro" for both fatdog-split-initrd and Fatdog Installer.

jamesbond wrote: Mon Aug 19, 2024 4:02 am

@retiredt00, thank you for the feedback. I will look into it. How did you get the small initrd, did you use the BIOS Fatdog Installer, or created it yourself using fatdog-split-initrd?

Dear jamesbond thank you for your response.
Yes I used the FD902 BIOS Fatdog Installer. The initrd is 19MB and includes a small kernel sfs with the encryption related modules.

What I ended up doing is:
download 902 and 903 ISOs,
expand their respective initrd,
swap the kernel sfs from 902 to 903,
repacked the modified huge 903 initrd,
split the modified 903 initrd with the fatdog-split-initrd.sh script to a new location
replaced the resulting fd64.sfs in my 902 installation leaving the original 902 initrd and 902 vmlinuz unchanged.
This seams to work but I am not sure if there is anything else in the 903 user space that would require the 903 kernel or if the new small initrd should be used too.
Also should the 902 or 903 devx be used with this setup (not sure if any kernel headers information is included in the devx that may affect any program compilation)
Thanks

retiredt00 wrote: Mon Aug 19, 2024 7:57 am

Dear jamesbond thank you for your response.

No worries, happy to help.

... replaced the resulting fd64.sfs in my 902 installation leaving the original 902 initrd and 902 vmlinuz unchanged.
This seams to work but I am not sure if there is anything else in the 903 user space that would require the 903 kernel or if the new small initrd should be used too.

That should be all right. You don't need anything else. The userspace doesn't depend on the kernel. As for the initrd, generally speaking, I would usually recommend to use the corresponding initrd (in this case, 903 initrd). Not because of the dependency between initrd and userspace (in Fatdog they're quite independent from each other, you can use initrd from other versions with userspace/basesfs from other versions except the very ancient ones), but because newer initrd usually comes with newer features.

But for this particular release, the difference between 902 and 903 initrd is so vanishingly small using one or the other wouldn't make any difference (it's only some diagnostic printout changes).

Also should the 902 or 903 devx be used with this setup (not sure if any kernel headers information is included in the devx that may affect any program compilation)

In general you should use the same version for the devx, as the version in your basesfs. In this case, you should use 903 devx. Not so much because of kernel headers, but more of application/program headers and manpages. You want the correct version corresponding to the programs you have in the base.

As for kernel headers: We don't include them in devx. In fact we don't provide kernel headers at all. We provide the complete kernel sources which includes the headers that you can use to build modules - the primary purpose of kernel headers; but you can also use it to rebuild the entire kernel yourself if you need to, for one reason or another.

A few days ago , I booted FD902 with kernel 6.10.2 to test it and now did the same thing with FD903 to see if the situation repeated itself on this machine with Nvidia graphic card .
As expected , it booted with the nouveau module .
Before installing the Nvidia modules I typed xorgwizard blindly on the prompt console but I got no screen . Booting with pfix=xorgwizard though , took me initially to Xorgwizard .
I loaded devx and kernel sources and installed the latest proprietary driver from Nvidia after I exited to prompt .
The issue is that , on prompt console I had no video of the console .
After I blacklisted nouveau and run the Nvidia installation file , inserting blindly the commands , I waited till the sound of my CPU cooler got quiet and typed xwin . I got to the desktop with Nvidia modules working . I could not unistall devx !

Before and after installing this modules I tried to change the wallpaper . It didn't work .
In terminal desktop-wallpaper complains about "/sys/class/graphics/fb0/virtual_size" .

In the kernel I noted that in the framebuffer folder we got only one module now , which in my case was not in use . I guess that's why we dont't have video on prompt, too .
Could this issue be corrected ?

jamesbond wrote: Mon Aug 19, 2024 4:02 am

@Duprate, thank you for testing. The 903-pkglist was wrong (hence the reference to fatdog-scripts-904). But in addition, ibiblio changed their systems and the repo update mechanism didn't work - hence the BAD CHECKSUM. Both have been corrected now. Please re-download 903-pkglist and try again.

I re-downloaded 903-pkglist.tar.xz and fatdog64-iso-builder-2024.08.tar.xz. Now it works perfectly! Thanks, Jamesbond ....

@Gobbi, thanks for letting us know. The desktop-wallpaper issue will be fixed in the next release. Meanwhile, I have attached a patch file that should fix desktop-wallpaper for you, and for other users with nvidia graphics I guess. To apply the patch file, rename the file without ".gz", copy the file to / (the top directory), then open a terminal window and type

cd /
patch -p1 -i ./desktop-wallpaper.patch

and press Enter. The shell should print

patching file usr/local/apps/Desktop-Wallpaper/sh/screen.sh

and that's it. If you get a different response copy it to this thread so we can examine any eventual error.

When you're finished, move /desktop-wallpaper.patch to the trash, and run the desktop-wallpaper program to confirm it's fixed.