Fatdog64 ISO Builder

[smokey01]

I increased qemu default RAM setting from 500MB to 1000MB.

Why not try running the Fatdog64 ISO Builder in a regular Fatdog rather than a virtual one as in Qemu. I'm not saying it's not possible but I have my doubts.

[proebler]

I moved to a different machine that has 4GB RAM, booting FD without savefile and then repeated the iso building.

@smokey01
I used qemu for testing only, once the iso had been built in the regular FD.

[belham2]

Hi all,

Was wondering if anyone could give me a hint on how to get the Fatdog64 'build-iso.sh' to start/launch ina working Fatdog64 OS?

What I've done do far:

1) I'm in Fatdog64 doing/trying all of this (the latest ISO just released), frugally-installed & a few programs added by me (Chrome, mainly). It is on a big 180GB USB HD, booted using grub4dos, if this matters, stable with no problems after using it for a few weeks now.

2) I downloaded, from ibiblio, the latest, the "710-pkglist.tar.xz" and "fatdog64-iso-builder-2016.12.tar.xz" files

3) I used SFR's Uextract and extracted them to their folders

4) I opened each of the extracted folders, and since these are in the "Spot" download directory, I moved them to the ~ root /home directory (to get them all out of Spot)

5) I read thru the provided "README.md" file...everything seems straightforward.

6) I copied the contents of a known good, bootable Fatdog64 ISO "initrd" extracted (like the above "README" directions say) and placed everyting into the provided "fatdog64-initrd" folder/directory.

7) I next spent a few hours going thru line-by-line the default 'sfs-baselist' file provided and removed and/or changed things to what I want (same for sfs-base32list, sfs-devxlist, sfs-nlslist & sfs.pkglist)

Eight) I then came back to the 'build-iso.conf' file, opened it and removed the "#" in front of everything under "### configuration" and under "# modules required for boot, spearated by spaces" so everything in this build file is lit up BLUE and ready to go

9) Next, I both clicked and double-clicked the "build-iso.sh" extracted file, and nothing happens and/or opens. Then, thinking I need to open it and get it ready to go, I did so, removing (not sure if this matters) the "#" that is in front of top lines saying this:

$1 - building sfs: base/devx/nls/base32/single/multi
$1 - building iso: iso [std/mini/small/micro] [uefi/xorriso-uefi/grldr/isolinux] (small is the same as mini)
$1 - building initrd: initrd [std/mini/small/micro]

Still, that did nothing. The build-iso.sh still will not start/launch, and I know everything has the correct perrmissions of 'a+x (Make executable/searchable)'--even downloaded stuff using 'wget' to keep it out of "spot" upon further testing (see below).


So I am lost here. How do I get this 'build-iso.sh' script up and running, so that it does what is says in the README where it is the Master script that controls everything, from the making of SFS to the initrd to the ISO?? (sincere apologies if this something simple and stupid, but it is my first time at ever trying something like this )


Thank you for any help on what to do.

P.S. Proebler and Wognath, would sure like to know how you even got the build-iso.sh script to even launch?? Let alone build the "failing" builds you are getting. I have now tried (everything mentioned above) on four diff machines I own, besides this Fatdog dedicated machine. Downloaded four different times from ibiblio no less. And the build-iso.sh script fails to even initiate/start on all four different machines (the machines are, respectively, debian, ubuntu, manjaro and the last is a machine with perfectly good working old versions (700 and 702) of Fatdogs on two diff hard drives). This build-iso.sh script fails to launch on all of them...what the heck am I doing wrong? I even just now went so far as to download the Feb '16 and May '16 versions of the fatdog64-iso-builder, and the "build-so.sh" script again fails to start or initiate anything each of the machines, despite having/setting root privileges for all I tried (as mentioned, with one of these extra machines being another Fatdog-dedicated machine, with two separate (700 & 702) fatdog-installed hard drives on them. Dang, this is getting to be a big...ugh)

[Wognath]

@Belham
This is new territory for me, but have had some luck. I think build-iso.sh must be launched from command line since it requires a parameter: lines 6-9. My steps:
1) modified the sfs-baselist from 710 and moved it to fatdog-iso-builder directory; 2) launched using

Code: Select all

./build-iso.sh base

since I'm only making a new fd64.sfs. After about 1/2 hour on my machine, new fd64.sfs appears in iso subdir. 3) Unpacked initrd, copied in new fd64.sfs and repacked. 4) Reboot with fingers crossed
This has worked and I am now in the process of tracking down libs I need but removed with some item in sfs-baselist (seamonkey )

I moved them to the ~ root /home directory (to get them all out of Spot)

and chown -R root:root, right?

[belham2]

...another update


Have not tried this fatdog64-iso-builder in 3 other 64-bit pups, Tahr64, Slacko64 and Barry's Quirky 8.0

The "build-iso.sh" script, after setting it up, just plain refuses to run as root.

And I do not know what I am doing wrong.


If someone who's actually used this please post what they did, would appreciate it. As far as I can see, this package and script are not functional given the wide range of machines it has failed to initiate/start on.

But, then again, I only see trees, and rarely see the forest, in puppyland

[belham2]

@Belham
This is new territory for me, but have had some luck. I launched build-iso.sh from command line. It requires a parameter: lines 6-9. My steps:
1) modified the sfs-baselist from 710 and moved it to fatdog-iso-builder directory; 2) launched using

Code: Select all

./build-iso.sh base

since I'm only making a new fd64.sfs. After about 1/2 hour on my machine, new fd64.sfs appears in iso subdir. 3) Unpacked initrd, copied in new fd64.sfs and repacked. 4) Reboot with fingers crossed
This has worked and I am now in the process of tracking down libs I need but removed with some item in sfs-baselist (seamonkey )

I moved them to the ~ root /home directory (to get them all out of Spot)

and chown -R root:root, right?

Thanks, Wognath

If this is new territory for you, then I am the absolute Virgin mary's half-son....as I am lost, haha.

Let me set the parameters again in the terminal, and see if i am idiotically (and repeatedly) typing in the wrong thing.

Thanks again for posting!!



P.S. Awwwwsssshhhhh######t! I just looked at what you posted, and now I see my mistake.....holy nuts, I have been leaving the "." off and just typing "/build-iso.sh base" Where's the auditions for Dumb & Dumber 5? I am heading there right now....

[belham2]

Hi again, Wognath,

Joy turns to another roadblock. Well, I just replicated Proebler's exact same experience.

First, I tried my few sfs-base modifications I made to the file. It built the ISO, I opened the ISO, copied everything into a folder, set up grub4dos to account for it, and it booted but immediately dropped to the dreaded:

bulldog login:



Next, I used just the standard files that are extracted from the ibiblio download of "Fatdog64-iso-builder" (using only what is given there after you extract it), made a new ISO, and it too booted (loading the fd64.sfs), and once again, the booting process stopped at the dreaded:

bulldog login:


Here's my grub4dos entry, accounting for everything correctly (I know this, because this setup works on other hard drives I have booting Fatdog):

Code: Select all

title CustomFatdog64 (sda1/fatdog64)
  uuid a3e4f07a-c77a-4483-b0be-cb3164dcaf4d
  kernel /CustomFatdog64/vmlinuz waitdev=5 rootfstype=ramfs basesfs=local:/CustomFatdog64/fd64.sfs savefile=direct:device:sda1 pfix=fsck
  initrd /CustomFatdog64/initrd

So the $64,000 question is why is Fatdog dropping to the "bulldog login" on booting when everything, including when the fd64.sfs, is being pointed at and accounted for??

Not sure where to turn and/or what to do next. Going to have to let this go today, spent some ~6 hours on this, and wife is pissed since it's Sunday

[jamesbond]

Here is the step of tests I've done.
1. I boot Fatdog64 710 ISO under qemu, with 2GB RAM (-m 2048), and a virtual disk of 4GB formatted as ext3, no savefile (I named the virtual disk as disk.ext3 so it can easily be mounted later using Rox).
2. The rest I did in this qemu.
Purpose of 1 & 2 - to simulate running the ISO builder in pristine environment, in a machine with 2GB RAM, and an existing Linux partition with 4GB space free.

3. I launched seamonkey and downloaded ISO builder dated 2016.2 from ibiblio.
4. I downloaded package list for 710, also from ibiblio.
5. I mounted the 2GB virtual disk (in my qemu, it showed up as "sda") using Rox - so the mount point is /mnt/sda
6. I right-click the iso builder tarball and choose extract. I did the same to the package list tarball.
7. I moved extracted contents of the pkglist tarball (sfs*list files) to replace those files in the extracted iso builder folder.
6 & 7 is done using Rox.

8. I mounted the virtual CDROM drive that contains the Fatdog64 710 ISO. In my qemu this is "sr0" so it is mounted under /mnt/sr0.
9. From /mnt/sr0 folder, I dragged and dropped (=copying) efiboot.img to "fatdog-iso-root" inside the extracted iso builder folder.

10. Using rox, I navigated to the "fatdog-initrd" folder inside the extracted iso builder folder.
11. I deleted everything under that folder (init, and "bin" folder) - still using Rox
12. I launched terminal in that folder, by typing back-quote.
13. In the terminal, I typed "cpio -i < /mnt/sr0/initrd" to extract the initrd from the Fatdog64 710. I can see that folder was populated with stuff extracted from initrd.
14. I deleted "fd64.sfs" and "kernel-modules.sfs" using Rox.

15. Now on the terminal I opened in step 12, I typed "cd .." to move up to the root folder of the iso builder.
16. I typed "geany build-iso.conf" and edited the file. I added

BASE_ROOTFS_DIR=/mnt/sda/build
WORKDIR=/mnt/sda/build-iso

to the end of the file. And I saved the file, and quit geany.
17. Then in the terminal I typed "mkdir -p /mnt/sda/build". Remember, "/mnt/sda" is where my virtual disk is mounted.
18. Then I typed "./build-iso.sh iso".

19. It will start downloading files. When all files have been downloaded, it will start instaling them. When installation is done, it will build fd64.sfs. When the basesfs is done, it will build the ISO in the "iso" folder.

Note: Go for coffee. Downloading from ibiblio is slow. Doing mksquashfs with XZ compression is also slow.
All these can be configured later using build-iso.conf (downloading from elsewhere, and changing the compression to use gzip/bzip2/lzo/lz4 etc) once you've got the basic steps right and working.

20. When it is done, shutdown qemu.
21. Loop-mount the virtual disk by clicking it in Rox.
22. I copied over the created fatdog.iso to my physical disk - just the usual Rox drag and drop.
23. Then I unmounted the virtual disk (clicking it again)

24. I tested booting the resulting fatdog.iso using qemu again (qemu-system-x86 -enable-kvm -m 1024 -cdrom fatdog.iso).
25. It works.

Note: all done with pristine Fatdog64 710 boot, no savefile needed, no devx needed, in a machine with 2GB RAM and 4GB free space (Linux filesystem).
I do not recommend nor discommend building in a VM. This is just an example. You can build directly in physical machine instead if you meet the requirements.

[belham2]

Note: all done with pristine Fatdog64 710 boot, no savefile needed, no devx needed, in a machine with 2GB RAM and 4GB free space (Linux filesystem).
I do not recommend nor discommend building in a VM. This is just an example. You can build directly in physical machine instead if you meet the requirements.

Hi James,

Thanks for the long answer how to do it in VM in Qemu. I came back this past to my desk to take another swing at this before I go to bed. I guess I could set up a VM environment on another machine, but I am having trouble understanding why (on this current Fatdog64 setup machine) why that would give me any different outcome than what I describe here (please note, I have experience with Fatdog, and have setup it on other machines, from full installs to HDs, to frugal installs to USBs and SD cards, have made small inits, etc, have done numerous remasters, but I've never encountered this bulldog login thing since I learned about over a year ago. So this is confusing me.

Here's what happened when I came back to this Fatdog64 OS/machine and attempted to do it all again:

This time, from the terminal, I got the ISO and the SFS to build from running the build-iso.sh script in the terminal. I watched it download about 500 lines of the stuff I had designated in the build-iso.conf file, and ignored (& it didn't download anything else).

After the downloading, the machine (this is inside a Fatdog64 710 frugal install with a savefile) then went about building my new fd64.sfs and iso. When all was done, I had a brand new 115MB fd64.sfs and a regular std ISO.

I then put this new fd64.sfs in a new folder (on the sda1 drive where everything is booted from) called it "CustomFatdog64, and also uxtracted the new ISO and dragged all its contents to this CustomFatdog64 folder.

I set up my grub4dos (on this sda1 drive) with two different entries to see if this creation would boot:

Code: Select all

title CustomFatdog64 (sda1/fatdog64)
  uuid a3e4f07a-c77a-4483-b0be-cb3164dcaf4d
  kernel /CustomFatdog64/vmlinuz waitdev=5 rootfstype=ramfs basesfs=local:/CustomFatdog64/fd64.sfs savefile=none pfix=fsck
  initrd /CustomFatdog64/initrd

Code: Select all

title CustomFatdog64 (sda1/fatdog64)
  uuid a3e4f07a-c77a-4483-b0be-cb3164dcaf4d
  kernel /CustomFatdog64/vmlinuz waitdev=5 rootfstype=ramfs basesfs=local:/CustomFatdog64/fd64.sfs savefile=direct:device:sda1 pfix=fsck
  initrd /CustomFatdog64/initrd

In both instances, this is what the terminal showed and stopped at as this built Fatdog64 booted:

Code: Select all

Decompressing Linux....Parsing ELF...done.
Booting the kernel.
Waiting 5 seconds for devices to be ready...
Loading base sfs from local, searching for /CustomFatdog64/fd64.sfs
Looking in sda1 - found
Loading base sfs from /dev/sda1 on /CustomFatdog/fd64.sfs
Not using save file.   ([i]2nd instances, fatdog loaded a small savefile w/ no problems[/i])

Welcome to Bulldog Linux
bulldog login:

Since I have read your http://distro.ibiblio.org/fatdog/web/fa ... tions.html and I also read this from a reply you gave to someone long ago http://45.33.15.200/puppy/viewtopic.php ... df58bedf86, I have no idea what is going wrong.

The only things in the basesfs text that I changed was putting "#" in front of nearly all the programs I don't use and/or want. I left everything, and I mean everything else (all libs and all other fatdog stuff) alone.

Why then would I be getting this this prompt when I'm not using "basesfs=none", have described where base sfs is, Fatdog says it found it and loaded it in the booting up, yet (as noted above), it immediately drops to the "Welcome to Bulldog Linux, bulldog login:" prompt?


Thank you for help, tips and/or pointers you can give about this.

P.S. This building is being performed on a nearly empty 180gb Seagate hardrive with a single sda1 partition on sda. So space is not an issue or problem, nor is setting up grub4dos and fatdog booting (which I've done on it many times before and currently using Fatdog64 installed 'frugally' on it to run the fatdog64-build-iso downloads.

[proebler]

@belham2
It seem that you have now arrived at the same situation which I was in at my post of 27-12-16.
Reading from your 2nd link http://45.33.15.200/puppy/viewtopic.php ... df58bedf86

.. If you find yourself in "bulldog", you're basically running from initrd; you only have busybox commands at your disposal. No GUI, no X, no graphical desktop ..

gives some explanation. But why we get into the situation we still don't know.
Perhaps Wognath will find the solution?

[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.