Fatdog64 ISO Builder

[Wognath]

Haha, it was beginner's luck. My 4 steps were condensed from 173 steps by leaving out the mistakes. FYI my computer has 3GB of memory. The only thing I can suggest is to double-check that everything under fatdog-iso-builder/ is owned by root. After that it just worked, though slowly. Instead of "go for coffee" I went for beer. Maybe that helped.

[jamesbond]

The problems seem to have been caused by shortage of RAM, because the temporary files are stored in /tmp during build process. Based on observation, you need a machine bigger than 4GB for it to work "as is" (8GB machine will work), because we need about 2.2GB free on /tmp for the standard pkglist build to be successful (that implies a machine with 4.4GB RAM).

proebler's screenshot shows me the kernel crashes because it can't find "init", this means the build encountered shortage of RAM during ISO creation process. belham2 and proebler's earlier problem shows bulldog login means that the basesfs was not created correctly.

The example I wrote about shows how you can run the build script in a machine with as low as 2GB RAM. The trick is line 16 and line 17, which tells the build script to use other locations (/mnt/sda in the example, but of course you should direct it to your own partition path) to be used instead of /tmp.

And for all would-be builders, I strongly suggest you attempt with the standard pkglist first, make sure it works and it boots, before trying to build a custom versions. This is to ensure that the build script works and any sort of failure is not caused by the custom versions; because, the dependency works in strange and mysterious ways. For example: removing libreoffice and gimp is okay, but removing seamonkey *is not* okay because seamonkey provides libnss and libnspr which are used by others; removing seamonkey may make other programs fail (e.g. google-chrome) unless you explictly install those libraries.

[proebler]

thanks jamesbond

here is my latest attempt:

/sda6 is an ext4 partition of >100GB
I have moved all of the build-iso files and directories to /sda6/Builder_FD.
I have created a directory /sda6/build
I then run

Code: Select all

 ./build-iso iso

from a terminal which I opened in /sda6/Builder_FD

Strangely, building with the default sfs-baselist, initrd now is 355MB and fd64.sfs 296MB.
In the original FD they are 344MB and 285MB
The iso is 360MB

Sadly still ending in kernel panic when I try to boot

I take it, that the mods to build-iso.conf override what is in build-iso.sh
I have in build-is.conf:
BASE_ROOTFS_DIR=/mnt/sda6/build
WORKDIR=/mnt/sda6/build-iso

[belham2]

The problems seem to have been caused by shortage of RAM, because the temporary files are stored in /tmp during build process. Based on observation, you need a machine bigger than 4GB for it to work "as is" (8GB machine will work), because we need about 2.2GB free on /tmp for the standard pkglist build to be successful (that implies a machine with 4.4GB RAM).

proebler's screenshot shows me the kernel crashes because it can't find "init", this means the build encountered shortage of RAM during ISO creation process. belham2 and proebler's earlier problem shows bulldog login means that the basesfs was not created correctly.

The example I wrote about shows how you can run the build script in a machine with as low as 2GB RAM. The trick is line 16 and line 17, which tells the build script to use other locations (/mnt/sda in the example, but of course you should direct it to your own partition path) to be used instead of /tmp.

And for all would-be builders, I strongly suggest you attempt with the standard pkglist first, make sure it works and it boots, before trying to build a custom versions. This is to ensure that the build script works and any sort of failure is not caused by the custom versions; because, the dependency works in strange and mysterious ways. For example: removing libreoffice and gimp is okay, but removing seamonkey *is not* okay because seamonkey provides libnss and libnspr which are used by others; removing seamonkey may make other programs fail (e.g. google-chrome) unless you explictly install those libraries.

Hi James, Proebler and Wognath (Proebler, I see you posted as I was writing this ),

Thank you, James, I applied your hint about line 16 and line 17 to the 'build-iso.conf', also expanded my savefile (just in case , up to 6GB), and wouldn't you know it, success, Bob-is-your-Uncle, and all that.

I booted into a desktop pristine, really stripped down version (at least for me) of Fatdog64. My built SFS came in at 139M. my small initrd at 4.5MB and the vmlinuz at 4.95MB.

I stripped/removed out the following out of the 'sfs-baselist' (as compared to a normal full fatdog install) before I ran './build-iso.sh iso small sfs initrd' in the terminal:

--libreoffice (all, plus Fatdog spelling dictionaries)
--transmission-qt5-2.2.4-x86_64-1
--vlc-qt5-2.2.4-x86_64-1
--vlc-plugin-2.0.6-x86_64-1
--pcreatetorrent-1.4-noarch-1
--fatdog-i18n (the Localised messages for Fatdog created by L18L)
--fd-help-2015.10.15
--refind-0.13.3-noarch-1
--grub2-efi64-2.00-x86_64-1 (my systems are all 'bios')
--preloader-efi64-2013.02-x86_64-1
--shim-efi64-0.2-x86_64-1
--efibootmgr-2015.03
--gtktetris-0.6.2b-x86_64-1
--armetronad-0.2.8.3.3-x86_64-1
--xournal-0.4.8-x86_64-1
--ctorrent-3.3.2-x86_64-1
--xscanimage-peasy-2015.05-x86_64-1
--xlockmore-5.46-x86_64-1
--peasyscale-cli-1.4-x86_64-1
--galculator-2.1.4-x86_64-1
--duff-0.5.2-x86_64-1
--gmeasures-0.7-x86_64-1
--vnstat--1.11-x86_64-1
--gtkhtml-browser-2015.12-x86_64-1
--psip-1.41-x86_64-1
--dvdauthor-0.7.1-x86_64
--vobcopy-1.2.0-x86_64-1
--hexedit-0.9.7-x86_64-1
--mhwavedit-1.4.23-x86_64-1
--sane-backend-2015.05-x86_64-1
--sane-frontend-2015.05-x86_64-1
--xsane-0.999-x86_64-1
--wvdial-1.6ldebian4-x86_64-1
--pppd-2.4.7-x86_64-1
--gimp-2.8.18-x86_64-1
--fdutils-5.5debian6 (everything below this line has the "..x86-64-1")
--ufiformat-0.9.9debian1
--gptfdisk-0.8.8
--dmraid-1.0.0rc16.debian5
--parted-3.2
--xfsprogs-3.2.2
--mdadm-3.3
--dvd+rw-tools-7.1debian10
--cdrtools-3.01
--btrfs-progs-3.18.2
--ntfs-3g-2016.2.22
--encfs-1.8.1
--lua-5.2.3
--viewnor-1.6
--mtpaint-handbook-3.49.06
--gifsicle-1.87
--engrampa-1.14.1
--evince-2.32.0
--calcoo-1.3.18
--geany-plugins-spell-1.28
--libspectre-0.2.7
--libgtkspell-2.0.16
--aspell-dict-en-7.1.0
--aspell-0.60.6.1
--gutenprint-5.2.10
--cups-filters-1.8.2
--qpdf-6.0.0
--poppler-0.42.0
--notecase-1.9.8
--hdparm-9.48
--smartmontools-6.4
--cpufreq-utils-0.8.1debian
--flash-plugin-11.2.202.644
--seamonkey-2,47

***to counteract completely un-installing seamonkey (so I can install Chrome afterwards) I added these to the sfs-baselist

--libnspr-4.11-x86_64-1
--libnss-3.21-x86_64-1
--sqlite3-3.8.11.1-x86_64



That's it, so far, lol. Everything booted up great, about 20-25 sec boot to desktop. I then created a savefile...rebooted back in, Fatdog had me set up all the localization stuff & then save it. WAs grinning, thinking I did it!!

But, as usually is my luck....I then ran into a snag when I was checking the "Fatdog64 Service Manager". I noticed that mdns was not enabled nor started. Uh oh, sure enough, checked my normal looking eth0 wired connection in the tray, and I've no internet, only "lo" access (but not the networkhub and/or router). Launching Network Configuration doesn't even see my motherboard built-in ethernet where a normal Fatdog64 install always does. Just to confirm things, launched Gslapt to have it update, and nada....the boat ain't floating for internet. Also, maybe I shouldn't have setup "ifplugd" to 'enable' and 'start' when 1st setting up my savefile? I don't know, am starting to get out of my depth here considering everything that might be related to network settings in fatdog.....


Haha, so, I've got to figure out what I either added and/or removed to the 'sfs-baselist' caused this. I've a feeling it was adding those three other packages (mentioned above, to counteract removing Seamonkey) from the ibiblio Fatdog710 database.

James (or anyone), any one of those removed and/or added sfs-baselist items listed above catch your eye for why I wouldn't have wired (or any kind) of network connection(s)? Thanks



{Update 2 hrs later} : figured it out...extracted the initrd that was made, and compared it to an initrd that does have the ability to have internet, and fixed (copied over & repacked) what was wrong. Now to download latest Chrome, see if it will not only install but run with all the changes I've done above.

{Update 3: Google Chrome Stable (latest edition) is now installed and running. Took me awhile to figure out why it would not start, despite installing correctly. Has nothing to do with root/spot permissions, and everything to do with a missing lib. Finally tracked it down: if you follow my method above and completely remove Seamonkey (and everything associated with it) when doing a terminal ./build, you must re-write the three lines I noted above in the sfs-basefile file plus---if you also completely remove "cups" and everything associated with it for the ./build, well, Chrome needs one of cups' libs. This lib is a "shared" dependency between browsers. Otherwise Chrome won't start (weirdly, I bet Seamonkey doesn't give one crap about it). Anyhow, for Chrome, this lib is critical lib and its name is: "libcups.so.2". Get a copy of this lib from your Fatdog64 install you are using to build things (copy it out of the /usr/lib64 folder) and after your build, place it back in the exact same folder (/usr/lib64). Do that, and everything is good. Chrome is now playing Netflix, runs Youtube, and surfs, just as well as it does on a full Fatdog install.


So, summing up, I've now got a Chrome Fatdog64-based ISO 'frugal' install that is exactly, when everything's added up, 192MB in size. This 192MB includes (not in addition to) the relatively small-sized (~46Mb) savefile that just holds chrome & its settings and a few settings of Fatdog. All in all, not bad, in fact, pretty darn good. I'm sure I could whittle it (this ISO) down further, but I've reached my objective. I wanted a sub-200mb sized 64-bit Fatdog install, to use solely for a decade+ old Celeron 64-bit laptop. This laptop does nothing except sit on a shelf over the elliptical and treadmill, and runs Netflix with really good quality. Thank you, Wognath & Proebler for the help. And a huge thank you to you, James, for this. Could not have even approached this project without the fatdog64-iso-build package, or without the detailed packages documents on ibiblio, and even more important, your hints how to get it to run for those of us too thick to work the build parameters/tips out for ourselves. Thanks again!!

[musher0]

Have a heart, people!

I think making this process available only to rich Puppyists who own
computers with 8 Gb of RAM constitutes economic discrimination.

Right after this, I'm going to file a complaint with the PPRL (Poor Puppyists
Rights League)!

Could the process not be done in say, /mnt/sda1/tmp instead of /tmp?
Slower, no doubt, but still could be done, no?

BFN.

[Dry Falls]

But suppose you already have a swap partition and start up with 'swapon /dev/sd<partition#>' ? I realize fatdog uses a swap file, but shouldn't both be recognized?

df

[belham2]

Have a heart, people!

I think making this process available only to rich Puppyists who own
computers with 8 Gb of RAM constitutes economic discrimination.

Right after this, I'm going to file a complaint with the PPRL (Poor Puppyists
Rights League)!

Could the process not be done in say, /mnt/sda1/tmp instead of /tmp?
Slower, no doubt, but still could be done, no?

BFN.

Musher,

It does not matter how you get the build out of the OS. You can link it and/or place it any way you want.

I built my mine using a computer that has the following:

--2GB ram (1.6GB accessible)
--a 8 yr AMD Sempron (unlocked to Athlon II X2)
--an IDE hard drive
--a 10 yr old Gigabyte motherboard

...and despite all the above, my build, each time I tried it, only took 20-25 mins. Just link however you want to, and go to town. And with the incredible documentation that James provides on ibiblio for each and every package and lib, explaining what they are and how they affect and/or needed by various programs, it made the build process incredibly easy (outside of my stupidity of not understanding the build parameters).

I have seen no other puppy and/or pup-related distro that even comes close to this, to make it "all" (the key word being ALL) available for the novice like myself. To let us believe that, yes, we can "build" our own puppy-like OS (other people in other threads (that I posted to today) are hollering that Fatdog is not a puppy, or that "I am a builder"......which points to, in my mind, the problem of the murga-board overall---the absolute intolerance by many when a novice succeeds & it is not done to their liking, an intolerance hidden behind niceities and pleasantries. This is unfortunate).


Just look at what James & crew done here, just with documentation alone:

http://distro.ibiblio.org/fatdog/packag ... CKAGES.TXT

or look here

http://distro.ibiblio.org/fatdog/packag ... CKAGES.TXT


Each time a Fatdog build is released, they have provided this for us. No other puppy builder has ever done this that I am aware of. Not ony that, James & crew put together the Fatdog64-ISO-Build download package. Like I said, it makes us (novices) enter a make- believe land where we can build. But in reality, all a person is doing is picking out packages and the documented libs needed, and entering only one line into a terminal:

# ./build-iso.sh iso small sfs initrd

That's it!! James & crew's "Fatdog64-Build_ISO" script is a master script that powers (other scripts) and the whole building process. An novice does nothing except watch the downloading of the vmlinuz and packages, watch the building of the sfs, and watch the initrd built at the end, where you are finally presented a spanking new ISO is a folder James & crew have already set up. My God, it is beautiful!!



I just gotta say, calling someone like me a "builder", lol, that's ludicrous. You and I both know I am not. The builders are you, james, kirk, sfr, phil, peebee, Barry, micko, etc, etc, etc. The problem is, we are always presented with a final build from you all (and, speaking for myself, I am always super grateful) and have little ability other than to reverse engineer it through reptitive re-mastering, to make something we can call our own.

James & crew have provided this. Furthermore, they've made it like Lego Blocks. And with their gentle help & tips, even non-builders like me can turn Lego Blocks into something beautiful.

A Fatdog64 OS, with a full Google Chrome browser installed, all under 200mb, all done on old computer hardware, and for old computer hardware if a person wants it.

To me, this is awesome.

[LazY Puppy]

(other people in other threads (that I posted to today) are hollering that Fatdog is not a puppy, or that "I am a builder"......which points to, in my mind, the problem of the murga-board overall---the absolute intolerance by many when a novice succeeds & it is not done to their liking, an intolerance hidden behind niceities and pleasantries.

That's definitely NOT correct.

I posted about FatDog not being a Puppy Linux just as an information. I'm not intolerant. Not to newbies that succeed things nor in general. And -of course- I'm not hiding such non-existent intolerance behind niceities and pleasantries.

You are talking about my post.

You lie, you quote incomplete and you interpret statements incorrectly.

Go read again my post and find out that I also answered a question of you about who did ever do remaster a Puppy by removing stuff from its main sfs.

Pity you didn't hide the your lies, incomplete quotings and incorrect interprets of statements behind niceities and pleasantries.

[dancytron]

The problem is that to overhaul WoofCE so that it is as easy to use as FatDog's apparently is would be a huge amount of not fun work. Not just programming, but boring documentation and commenting scripts too. Not nearly as fun and exciting as trying new desktops or building betas of the the next version.

[jamesbond]

@belham2: congrats on your success. The parameter you passed to build-iso is incorrect though.

If you want to build small initrd only - "./build-iso.sh initrd small"
If you want to build an ISO file with small initrd - "./build-iso.sh iso small"

________________________

If you want to get complicated, here are more variations:

INITRD AND ISO
==========
If you want to build an BIOS-only (no UEFI support) ISO file with small initrd - "./build-iso.sh iso small isolinux"
If you want to build an BIOS (no UEFI support) with grub4dos ISO file with small initrd - "./build-iso.sh iso small grldr"
If you want to build a standard (=huge) initrd only - "./build-iso.sh initrd"
If you want to build an ISO with standard (=huge) initrd - "./build-iso.sh iso"
If you want to build an BIOS-only ISO with standard (=huge) initrd - "./build-iso.sh iso std isolinux"
etc

SFS only
======
If you want to build only the basesfs - "./build-iso.sh base"
If you want to build only the devx sfs - "./build-iso.sh devx" (note: will need to add DEVX_ROOTFS_DIR= to build-iso.conf). Edit sfs-devxlist as needed.
If you want to build only the nls sfs - "./build-iso.sh nls" (note: will need to add NLS_ROOTFS_DIR= to build-iso.conf). Edit sfs-nlslist as needed.
If you want to build basesfs, devx, nls at the same time, - "./build-iso.sh multi"
If you want to build 32bit compat lib sfs - "./build-iso.sh base32" (note: will need BASE32_ROOTFS_DIR= in your build-iso.conf, and also edit sfs-base32list as needed).

If you want to build only the unsplit basesfs (unsplit means all the header files, docs, nls etc are in the same sfs) - "./build-iso.sh single" - but you will need to populate sfs-pkglist

Other notes
=======
If you already built a basesfs and want to build an initrd/iso, and don't want to rebuild the basesfs again, pass USE_EXISTING=1 to env before calling build-iso.sh, e.g.

USE_EXISTING=1 ./build-iso.sh iso

All these additional notes should go into the README or INFO or something, I know. I'll do that in the next release ... hopefully


_________________________


@proebler: make sure WORKDIR and BASE_ROOTFS_DIR points to the actual path. If you mount your sda6 in /sda6 (instead of /mnt/sda6), then it has to be specified that way.

__________________________


@musher0: As I stated earlier, and proven by belham2, it is indeed possible to build Fatdog64 in a machine with 2GB RAM and 4GB disk space. I won't recommend anything less as the minimum RAM required for Fatdog64 (and any other reasonable 64-bit distro) is 1GB.

@dry falls: It's better (and faster) to re-direct the tmp build dir to a specific partition using BASE_ROOTFS_DIR and WORKDIR instead of activating a 4GB swap, because of the crowding effect.

@dancytron: anyone who have used WoofCE-NG should be very familiar with Fatdog64 ISO Builder (I need to find a shorter name for this ...) because, well, both were derived from the same design.

[belham2]

@belham2: congrats on your success. The parameter you passed to build-iso is incorrect though.

If you want to build small initrd only - "./build-iso.sh initrd small"
If you want to build an ISO file with small initrd - "./build-iso.sh iso small"

________________________

If you want to get complicated, here are more variations:

INITRD AND ISO
==========
If you want to build an BIOS-only (no UEFI support) ISO file with small initrd - "./build-iso.sh iso small isolinux"
If you want to build an BIOS (no UEFI support) with grub4dos ISO file with small initrd - "./build-iso.sh iso small grldr"
If you want to build a standard (=huge) initrd only - "./build-iso.sh initrd"
If you want to build an ISO with standard (=huge) initrd - "./build-iso.sh iso"
If you want to build an BIOS-only ISO with standard (=huge) initrd - "./build-iso.sh iso std isolinux"
etc

SFS only
======
If you want to build only the basesfs - "./build-iso.sh base"
If you want to build only the devx sfs - "./build-iso.sh devx" (note: will need to add DEVX_ROOTFS_DIR= to build-iso.conf). Edit sfs-devxlist as needed.
If you want to build only the nls sfs - "./build-iso.sh nls" (note: will need to add NLS_ROOTFS_DIR= to build-iso.conf). Edit sfs-nlslist as needed.
If you want to build basesfs, devx, nls at the same time, - "./build-iso.sh multi"
If you want to build 32bit compat lib sfs - "./build-iso.sh base32" (note: will need BASE32_ROOTFS_DIR= in your build-iso.conf, and also edit sfs-base32list as needed).

If you want to build only the unsplit basesfs (unsplit means all the header files, docs, nls etc are in the same sfs) - "./build-iso.sh single" - but you will need to populate sfs-pkglist

Other notes
=======
If you already built a basesfs and want to build an initrd/iso, and don't want to rebuild the basesfs again, pass USE_EXISTING=1 to env before calling build-iso.sh, e.g.

USE_EXISTING=1 ./build-iso.sh iso

All these additional notes should go into the README or INFO or something, I know. I'll do that in the next release ... hopefully


_________________________

Thank you, James!! I'm going to do a couple more builds over the next few days trying variations of the parameters you listed here. Much thanks again for making this possible for someone like me

[proebler]

.. ok, I too can now report success with the iso-builder after sorting out the problems I had.
It is a queer sort of story.
I had put the build-iso files and directories on a bootable USB stick, which -of all things- I once set up to to boot to a (Win98) DOS console. The USB stick is 16GB, has a lot of free capacity, formatted to FAT32, so I use it simply as a storage device.

.. now, ROX cannot copy symlinks to a Win/DOS device, they are incompatible there !

I must have got (ROX) error warnings, when I copied initrd to the fatdog-initrd directory.
But I ignored the warnings when I checked, and -superficially at least- , found that things 'looked ok'.
(I have ignored warnings from ROX before with apparent impunity)
Well, in this instance, the warnings came with good reason.
I discovered, that the fatdog-initrd directory was missing the 'run' and the 'init' links and quite probably many others.
No wonder then, that the result was kernel panic.
There were other errors as well, possibly unrelated to the above, but rather to limiting RAM (?).
I found that more than half the files in pkgcache were empty (0byte) files, so I had to re-download them.

After that: Success, I have an iso without LibreOffice, Gimp, games; instead it has Gnumeric, Abiword, fotoxx and Qemu to do testing !

Some observations I have made:

The initrd which has to be stripped of kernel-modules.sfs and fd64.sfs and then copied into the fatdog-initrd directory must not be repacked . It has to be copied unpacked. (I didn't repack, but during my investigations also tried it repacked, which does not work)
Perhaps Note 3 in the README should say so. (see also the earlier posted step 13 of jamesbond's detailed instructions)

Something to watch when building successive iso's, is that the build directory does not get cleared after each build.
I got caught by that, when after building the full iso using the default sfs-baselist, I used a reduced, different sfs-baselist. The resulting build was again the full iso.
Perhaps the build directory ought to be cleared automatically (?).
BUT I have in fact used that retained build to later make some additions to a build/iso (again running ./build-iso.sh iso). In a way, an editing of the fd64.sfs, I suppose (?), I'm not sure, it worked.

This is it,
thanks again for this tool and the support.
proebler

[jamesbond]

Congrats proebler.

I will update note 3 in the README, yes (I thought it was obvious enough, but apparently not). Another note I will add also is that you will need a properly Linux filesystem to build. Definitely no FAT32, not NTFS.

EDIT:
RE: build-dir -- the build directory containing temporary rootfs is not cleared - yes, it is not. By default those are built in /tmp and are cleared, but if you redirect it elsewhere, I assume you would want to keep it (for further checking etc). Perhaps not a very good assumption. For now you would just have to remember to clear it after every build.

[Terry H]

Firstly, thanks to the fatdog team for making the fatdog64 iso builder available.

I have had 3 attempts to run the fatdog-iso-builder. On the 3rd attempt I got what appears to be a fully working iso. The problem is that 11 (of 612) packages were not downloaded as the message stated that they already existed. THe PC I am using is a desktop with AMD FX-6100 processor with 10 GB RAM.

The following is a summary of the 3 attempts I have made so far:

Attempt # 1
I downloaded and extracted fatdog-builder-iso and package list. Created build & build-iso folders on ext4 partition. Did all the copying and setup as specified in the jamesbond's qemu example (post #27) I messed up with the initrd, as after unpacking and removing the 2 items from the unpacked initrd, I repacked and copied that to the fatdog-initrd folder. Upon running ./build-iso.sh iso. The job did not download approximately 11 packages as they were flaged as already existing. The same packages were also skipped in the build. The iso that was produced failed to boot with a kernel panic. I presume this was due to my initrd mistake, not the skipped packages.

To test the generated iso's from each attempt I did a new frugal install with savefile=none.

Attempt # 2
Deleted the contents of the build folder, created the build-iso folder. I retained the fatdog-builder-iso and package list archives. Deleted everything else and did the setup again. My mistake this time was forgetting to extract the package list and include it in the fatdog-builder folder. The job ran but only downloaded 37 packages and created an iso. I was able to boot and login to a console session as root.

Getting a bootable iso was encouraging.

Attempt # 3
Same as Attempt # 2, but included package list. This time showed 612 packages to be downloaded. As per attempt # 1, the same packages were not downloaded and skipped in the build.

The skipped packages were:

Code: Select all

slapt-get-0.10.25-x86-64-1
libnettle-3.1.1-x86-64-1
e2fsprogs-1.42.12-x86-64-1
parted-3.2-x86-64-1
lua-5.2.3-x86-64-1
libacpi-0.2-x86-64-1
libnotify-0.5.2-x86-64-1
libgnutls-3.3.18-x86-64-1
bluez-4.10.1-x86-64-1
obexd-0.46-x86-64-1
xcb-util-keysyms-0.4.0-x86-64-1

The resulting iso seems to be fully functional. On testing this new frugal install, I was able to run slapt-get and parted from the command line. These were 2 of the packages which were in the skipped group. Checking for other libs showed that they were also included.

If possible could one of the fatdog team please advise how the packages may have been flagged as already existing and subsequently skipped, but subsequently seemingly being included in the output fatdog.iso.

Thanks in advance for any assistance.

[Terry H]

To check my results I decided to run the build on my wifes laptop, which hasn't had fatdog on it before. It has grub4dos on it, but didn't have any ext3/4 partitions. I shrank a data partition in windows and then created an ext3 partition using a frugal installed tahr pup I already had installed on it.

I downloaded the fatdog710 iso and created a new frugal install on the new partition. I then downloaded the fatdog-build and packagelist archives and did the setup to run the build system on this PC.

The result was the same, as the final run in my previous post. The same packages were not downloaded. I did a new frugal install using the new fatdog.iso with savefile=none. Runs fine, connected to internet using wifi, ran slapt-get from CLI update and upgrade. Updated 6 packages. I ran parted -l from cli and listed partitions. So all is good.

I still would like advice as per my previous post, however, it now appears to me that, the results I have received are normal. In the mean time I am going to make a few changes to the package list and run again. Mainly going to remove the browser and run a browser as an sfs.

[mcradventures]

Can this be used to make essentially the latest Fatdog but with the 3.14 kernel? I only ask because I like the sound of Fatdog but it doesn't run on the old laptop I have, but Tahr pup does, which uses an older kernel. I have narrowed down the issue to the kernel as it seems no "modern" distro with the 4.x kernel will boot on the laptop. I've spent two days trying to get ANY linux distro on this laptop and the only successful one was Tahr pup, but it lacks some features that Fatdog seems to have and I can't figure out any way to add those features to Tahr pup.

If this can't do it, is there any way to do it? Is there a possibility of Fatdog being released officially with an older kernel for older hardware? If curious, the laptop is a Dell Vostro 1000.

[step]

I don't know how to answer your specific questions directly, sorry. But have you considered running Fatdog 702 on your Dell? 702 did run on k3.14 until it was upgraded. Here's the kernel repo for 702 http://distro.ibiblio.org/fatdog/kernels/700/. Are you looking for specific features of 710 that aren't available in 702? If so, which ones?

[step]

@Terry H,

I suspect that indeed all the packages were downloaded, and that the "already downloaded" messages occur on subsequent download attempts, which depend on the inner workings of the ISO builder.

I have traced one exemplar package, parted-3.2, as it goes through the script. What I see is that it is downloaded successfully, then about 50 seconds later the script wants to download it again but finds it in the cache and outputs "already downloaded", then after some more time the script wants to install it, and finds it "already installed" (in my system), and so on.

I could make the whole trace available, if you really need it, but perhaps this excerpt is enough to show what's going on in the life of parted-3.2. And I guess the other packages go through the same drill.

Note that parted-3.2 takes two different IDs, 450 and 468, in the download list. There are duplicates in the list, probably because the script errs on the safe side. No package is downloaded more than once. The script "announces" 612 intended downloads, but it actually downloads only 601 packages. It means that 11 packages are duplicated, which is the number of packages in your list.

11 = 612 -1 - $(ls pkgcache/*.txz | wc -l) # -1 because pkgcache starts with a locally created package, pkgcache/bash-default-shell-1.0-noarch-1.txz

Code: Select all

+ : 'read pkg(parted-3.2-x86_64-1) Thu Jan 26 8:30:39'
+ pkg=parted-3.2-x86_64-1
+ set -- parted-3.2-x86_64-1
+ pkg=parted-3.2-x86_64-1
+ '[' -z parted-3.2-x86_64-1 ']'
+ PKGS=450
+ echo -n '450 of 612: '
450 of 612: + '[' -s pkgcache/parted-3.2-x86_64-1.txz ']'
+ download_file parted-3.2-x86_64-1.txz
+ echo downloading parted-3.2-x86_64-1.txz ...
downloading parted-3.2-x86_64-1.txz ...
+ '[' parted-3.2-x86_64-1.txz = parted-3.2-x86_64-1.txz ']'
+ wget -c -o /dev/null -O pkgcache/parted-3.2-x86_64-1.txz http://distro.ibiblio.org/fatdog/packages/710/parted-3.2-x86_64-1.txz
+ check_md5 parted-3.2-x86_64-1.txz
+ echo -n 'Checking integrity parted-3.2-x86_64-1.txz ... '
Checking integrity parted-3.2-x86_64-1.txz ... + read goodsum
++ awk -v pkg=./parted-3.2-x86_64-1.txz '$2==pkg {print $1;exit} END {print "NONE"}' pkgcache/CHECKSUMS.md5
+ read filesum
++ md5sum pkgcache/parted-3.2-x86_64-1.txz
++ awk '{print $1}'
+ '[' a65b74ddf8bf314430f15bde4cf5793f = NONE ']'
+ '[' a65b74ddf8bf314430f15bde4cf5793f '!=' a65b74ddf8bf314430f15bde4cf5793f ']'
+ echo good.
good.
+ return 0

-------------------------- about 50 seconds later -------

+ : 'read pkg(parted-3.2-x86_64-1) Thu Jan 26 8:31:24'
+ pkg=parted-3.2-x86_64-1
+ set -- parted-3.2-x86_64-1
+ pkg=parted-3.2-x86_64-1
+ '[' -z parted-3.2-x86_64-1 ']'
+ PKGS=468
+ echo -n '468 of 612: '
468 of 612: + '[' -s pkgcache/parted-3.2-x86_64-1.txz ']'
+ echo parted-3.2-x86_64-1 already exist, not downloaded.
parted-3.2-x86_64-1 already exist, not downloaded.
+ check_md5 parted-3.2-x86_64-1.txz
+ echo -n 'Checking integrity parted-3.2-x86_64-1.txz ... '
Checking integrity parted-3.2-x86_64-1.txz ... + read goodsum
++ awk -v pkg=./parted-3.2-x86_64-1.txz '$2==pkg {print $1;exit} END {print "NONE"}' pkgcache/CHECKSUMS.md5
+ read filesum
++ md5sum pkgcache/parted-3.2-x86_64-1.txz
++ awk '{print $1}'
+ '[' a65b74ddf8bf314430f15bde4cf5793f = NONE ']'
+ '[' a65b74ddf8bf314430f15bde4cf5793f '!=' a65b74ddf8bf314430f15bde4cf5793f ']'
+ echo good.
good.
+ return 0

[Terry H]

@step

Thanks so much for running the trace and the explanation. That response is more than satisfactory. With subsequent runs I had become satisfied that it was OK. The parted-3.2 example is sufficient.

Apart from checking that the affected applications ran, I had also checked the pkgcahe and saw the packages were present following the build. Unfortunately duplicate entries in the sfs-baselist didn't cross my mind. I've read through this thread several times now and I was surprised that this hadn't been queried previously in the almost year that this thread has been existing.

Hopefully this will be assistance to new users who want to run the Fatdog64 ISO Builder in the future. This systm is really an excellent inclusion to this community.

[rufwoof]

Made some notes ... followed/filled them in and ran the build script to build a base (cli) system only with wifi net connect ... and all ran quickly and smoothly.

/tmp threw me a bit. I boot frugally all running in ram on a 4GB system and could perhaps have gotten away with just leaving that as it, but I moved /tmp to a hdd based /tmp as part of the build. Subsequently I've seen a earlier post in this thread that details how to set /tmp to a different location within the build script.

My notes ...

Code: Select all

http://murga-linux.com/puppy/viewtopic.php?t=105329

The Fatdog64 ISO Builder.

It enables you to build a custom ISO from the ground up, from a given list of packages.
No remastering is involved. It is the same builder that we use ourselves to build the
official ISO.

Another way to explain it: Fatdog64 ISO Builder is the Fatdog's version of Woof. If you
have seen how the "next-generation" branch of Woof-CE (aka woof-ng), you would see a lot
of similarities since the woof-ng builder was originally based from this.

Downloaded the latest build script tarball from
http://distro.ibiblio.org/fatdog/iso/builder/
ran xz -d to decompress it and tar xvf ... to extract it (under a hdd based 
folder in my case within a folder /mnt/sda1/fatdog-build that I created)

===============

Get a recent ISO, extract out
its initrd, put it in a folder called `fatdog-initrd` and use that
folder to replace the one here. Note: use the extracted content,
and do not re-pack it again.

If you forgot to do this you will be gently reminded when you boot
the resulting ISO
Make sure you remove `kernel-modules.sfs` and `fd64.sfs` from the
extracted initrd to save space as they are not used and will be
replaced with by the build process anyway.

deleted all files/folders in fatdog-initrd then ..
cd /mnt/sda1/fatdog-build/fatdog-iso-builder/fatdog-initrd
cat /mnt/sda1/initrd | cpio -id # to extract
removed both fd64.sfs and kernel modules sfs


=================

All the working files will be created in this directory unless you
specify otherwise (via `build-iso.conf`). Thus make sure that you put
this in a filesystem large enough to contain all the downloaded
packages and the final output.

It will use `tmp` as temporary directory by default; so you will also
need plenty of space there. How big the space is needed depends on how
many packages you want to build.

Fatdog64 800 requires at least 2.5GB free in /tmp.
Newer version will require more space.

If you have less than 2.5GB in /tmp, you need to specify directory
location for storing temporary files.


mkdir -p /mnt/sda1/tmp
mount -M /tmp /mnt/sda1/tmp  # Move from tmpfs (limited/ram under frugal boot) to hdd based
# resize current allocation to /tmp (ram limit)
# mount -o remount,size=10G /mnt/sda1/tmp ... when it came to the actual
run I didn't need to do that as under fatdog tmpfs was sized to 16GB). The
following is also the df -h as I ran when making the notes under voidlinux ... 
# so df -h shows
# df -h
Filesystem      Size  Used Avail Use% Mounted on
inram           3.4G  115M  3.3G   4% /mnt/layers/RAM
/dev/sda1       447G  146G  279G  35% /mnt/sda1
overlay_result  3.4G  115M  3.3G   4% /
run             1.7G  696K  1.7G   1% /run
dev             1.7G  4.0K  1.7G   1% /dev
shm             1.7G   60M  1.7G   4% /dev/shm
cgroup          1.7G     0  1.7G   0% /sys/fs/cgroup
tmpfs            10G  8.0K   10G   1% /mnt/sda1/tmp


=====================

To build BIOS-only ISO with huge (standard/default) initrd, using syslinux bootloader:
`./build-iso.sh iso std isolinux`

To build a standard BIOS/UEFI ISO (like standard Fatdog64):
`./build-iso.sh iso`

I built the first of the above two noted choices. Ran through very quickly, went off to make coffee and by the time I returned it was back at the command prompt (had finished). So single digit minutes build time.

I opened the .iso that had been produced and copied out the initrd and
vmlinuz and set up grub4dos menu.lst to boot those files, along with
network connect ...

# menu.lst
color white/blue black/cyan white/black cyan/black
timeout 10
default 0

title Fatdog
root (hd0,0)
kernel /fatdog-build/vmlinuz net=wpa2:VM123456-2G:abcd1234:wlan0:dhcp pkeys=uk
initrd /fatdog-build/initrd

and it booted OK. At login prompt entered userid 'root' and it auto logged in
upon pressing <enter>

vmlinuz filesize around 6MB
initrd filesize (with kernel modules and main sfs integral to that) around 116MB

Font was small so once logged in I cd /lib/boot/consolefonts and ran
setfont ./big.psf.gz 
... to load a larger font


ping google.com
... worked OK ... etc