Alternative way to build Ubuntu / Debian Puppy [RETIRED]

Under development: PCMCIA, wireless, etc.
Message
Author
stemsee

#41 Post by stemsee »

No Wonder! duh!

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#42 Post by 01micko »

Just make sure you rename your kernel image to vmlinuz and the module sfs to kernel-modules.sfs :wink:
Puppy Linux Blog - contact me for access

User avatar
mavrothal
Posts: 3096
Joined: Mon 24 Aug 2009, 18:23

#43 Post by mavrothal »

Just make sure you rename your kernel image to vmlinuz and the module sfs to kernel-modules.sfs :wink:
Actually (James) with all different kernels per puppy and multiple puppies, using the generic vmlinuz and modules.sfs can be a problem. Symlinks would be a solution but we install in (V)FAT too...
Grub and the likes could use the full names but the init (and DISTRO_SPECS) should also be modify to recognize the specific kernel or put the kernel in the initrd (as in FD_ARM/XOpup). But then changing kernels would not be so easy. :evil: Maybe it shouldn't as a "random" kernel can really break your system.

BTW Mick, since you were posting while I was editing, I do not know if you noticed the comment about directories being empty, above.
BTW2 you do not need the git directories to be empty (or date stamped). Git reset/clean/{fetch,pull} should do it.
BTW3 I assume "NG" means next generation, however this is not nesseceraly the most common use of the initials... :twisted:
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==

stemsee

success

#44 Post by stemsee »

Edit: Booted normally into trusty tahr i.e. straight to xorgwizard = keyboard select then video select then straight to desktop!

Now posting from EmSee-2nd-Edition using new kernel, new initrd and kernel-modules.sfs only had to rename main sfs to puppy.sfs. Previous kernel posted here 3.14.5-pae works, but newer one is better, same version recompiled.

I think copying my previous main.sfs files into savefiles might be the easiest way to load them onto the puppy.sfs from the build. in order to build it up.

That was a truly painless process!!

Edit: Sharing my newest kernel 3.14.5-pae and kernel-modules.sfs and initrd in tar.gz folder for general usage. Kernel is compiled with timer @1000hz not 300hz as in 01micko's 3.12.21, also i486 not pentium pro, and extra functionality that might be useful to someoen, somewhere, sometime - maybe!

https://drive.google.com/file/d/0B4GhZV ... edit?usp=1

have a nice day!


EDIT: I noticed that loading my own base.sfs results in the boot directory not being mounted on /mnt/home but /initrd/mnt/pup_ro2 I didn't check if that was the case when booting the trusty puppy.sfs from the build.
Last edited by stemsee on Mon 09 Jun 2014, 09:11, edited 1 time in total.

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#45 Post by jamesbond »

Glad to hear the success stories.

Good work Mick!!
I've merged your changes build-iso.sh.

@stemsee, what do you mean by "xinput create-master second"?
Well, I don't think jobs are the same as threads.. I should have commented it however I have been using -j6 forever on my athlon X2. Cooked machine is a possibility but more likely is the thermal cut out protection.
No, no cooked machine unless your machine's thermal protection is faulty.
In general, the recommended number is 1.5x your CPU cores.
If you have too many jobs, then the overall result becomes *slower*, not faster.
If you really want to compile in a flash, and you have a few machines to spare, then learn to use distcc :)
Actually (James) with all different kernels per puppy and multiple puppies, using the generic vmlinuz and modules.sfs can be a problem. Symlinks would be a solution but we install in (V)FAT too...
Agreed. Just to note that build-iso.sh is a quick and dirty script :)
It is there just to show that once you have the SFS, you can easily create an ISO.
Please feel free to hack build-iso.sh to come with the proper naming scheme kernel and module.sfs, pointing DISTRO_PUPPYSFS and DISTRO_ZDRVSFS to the right name.
put the kernel in the initrd (as in FD_ARM/XOpup
I think you mean "put modules.sfs" in initrd. Yes, this is an option, this is what I actually do for Fatdog64/FatdogArm/XOpup. But note: putting it in initrd means it will stay in RAM. This may or may not be a good thing:
a) Fatdog64's module.sfs is around 40MB, and this 40MB will be kept around in memory (it *will not* show in "free", but it's memory that programs can't use nonetheless). For Fatdog64, this isn't a problem because it runs in a machine with 1GB memory. A comfortable 64-bit machine will have 2GB or more. What is 40MB for a friend :)
b) FatdogArm's modules.sfs is very small (around 8MB), and thus can stay there, as reasoned above.
Now, I didn't check the size of typical Puppy kernel's modules.sfs; and whether it is acceptable to hold *that* in RAM while Puppy is running.

One thing I didn't check when I put the modules.sfs into ZDRV - does ZDRV gets copied to RAM too at boot time? If not, that means when you use CD to boot it, the CD can't be taken out.

@Mav - NG does mean "Next Generation" - as you can see from "samba-tng", "util-linux-ng", and many other examples :)

Mick I saw you removed "-o 64" from isohybrid, is that because 32-bit kernels don't boot with that?
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

stemsee

#46 Post by stemsee »

xinput installed on puppy results in # xinput list commmand showing one mouse0 and keyboard0, the same command on L64 and all other linux distros results in a list of input devices as seen in hardinfo - input . a 'Master' is the head to which are attached the first keyboard and mouse and all other input devices. By creating a second master xinput allows you to attach to it a second keyboard and mouse which gives another pointer that acts indepedently of the first as in multi-touch. You can of course create several masters with several pointers and keyboards etc. It may be possible still to 'map' a master to a display/screen/desktop. Which is useful for me and my family to share one pc with extra displays keyboard and mice = pseudo multi-seat without nested servers = accelerated graphics and much better performance. Not for most people's usage I know.

Edit: Here is the patch for mapping input device to screen.

http://lists.x.org/archives/xorg-devel/ ... 23898.html
Last edited by stemsee on Thu 19 Jun 2014, 18:55, edited 3 times in total.

User avatar
mavrothal
Posts: 3096
Joined: Mon 24 Aug 2009, 18:23

#47 Post by mavrothal »

jamesbond wrote: One thing I didn't check when I put the modules.sfs into ZDRV - does ZDRV gets copied to RAM too at boot time? If not, that means when you use CD to boot it, the CD can't be taken out.
If there enough RAM, yes
NG does mean "Next Generation" - as you can see from "samba-tng", "util-linux-ng", and many other examples :)
Depends where you look :lol:
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#48 Post by 01micko »

--if suffix is -nfg then you absolutely know it's no good :P

james, as for the the -o 64 option, I think it's a case of old isohybrid in slacko, nothing more.

PS @jamesbond. re kernel-kit. Do you have a script for getting kernel firmware and cutting out inappropriate bloat?
Puppy Linux Blog - contact me for access

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#49 Post by jamesbond »

xinput installed on puppy results in # xinput list commmand showing one mouse0 and keyboard0, the same command on L64 and all other linux distros results in a list of input devices as seen in hardinfo - input . a 'Master' is the head to which are attached the first keyboard and mouse and all other input devices. By creating a second master xinput allows you to attach to it a second keyboard and mouse which gives another pointer that acts indepedently of the first as in multi-touch. You can of course create several masters with several pointers and keyboards etc. It may be possible still to 'bind' a master to a display/screen/desktop. Which is useful for me and my family to share one pc with extra displays keyboard and mice = pseudo multi-seat without nested servers = accelerated graphics and much better performance. Not for most people's usage I know.
Ah, that's because xorg hotplugging is *NOT ENABLED* in puppy. The ones built with deb-build does work (if you also apply the pinstall.sh patches from rootfs). For others, what stemsee says is quite interesting, here's what Arch has to say about it: https://wiki.archlinux.org/index.php/Multi-pointer_X.
EDIT: typo.

@Mav, good that ZDRV is loaded into RAM :)
@Mick, (about -o64) I see, thanks. I use that "-o 64" because the default is "-o 0" (basically means that the start of the partition includes the partition table itself) and certain machines will not boot with this setup.
--if suffix is -nfg then you absolutely know it's no good
LOL :D
PS @jamesbond. re kernel-kit. Do you have a script for getting kernel firmware and cutting out inappropriate bloat?
No. What we usually do when we build the modules.sfs is something like this

Code: Select all

# in kernel source, after completion of make oldconfig
make -j6 bzImage modules
make modules_install INSTALL_MOD_PATH=./modules
cp -a /lib/firmware modules
mksquashfs modules kernel-modules.sfs -comp xz -Xbcj x86
Basically we copy whatever existing firmware in the running Fatdog, may be plus a few that others have reported missing in the forum. What we have in firmware is quite large and may contain obsolete stuff as well (I cleaned out radeon firmware before we released 630, I think, but there are many other that I haven't looked at) ...
Last edited by jamesbond on Mon 09 Jun 2014, 12:47, edited 1 time in total.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

stemsee

#50 Post by stemsee »

[quote="jamesbond"No. What we usually do when we build the modules.sfs is something like this

Code: Select all

# in kernel source, after completion of make oldconfig
make -j6 bzImage modules
make modules_install INSTALL_MOD_PATH=./modules
cp -a /lib/firmware modules
mksquashfs modules kernel-modules.sfs -comp xz -Xbcj x86
Basically we copy whatever existing firmware in the running Fatdog, may be plus a few that others have reported missing in the forum. What we have in firmware is quite large and may contain obsolete stuff as well (I cleaned out radeon firmware before we released 630, I think, but there are many other that I haven't looked at) ...[/quote]

Exactly what I did and thought should be the solution.

XINPUT on puppy: After maybe two years I have my answer! Thank you Jamesbond. Barry Kauler owes you $50 au ! Or half anyway. lol

Also I am now typing from the trusty built in woof-ce-ng. Gave a blowfish result of 8.1 Unheard of!!!

stemsee

latest stable kernel non-pae

#51 Post by stemsee »

I am posting from RSH's L.A.S.S.I.E running on latest 'stable' kernel 3.15 non-pae i486 (but says i686), just compiled on kernel-kit-ng by 01micko with initrd by jamesbond, and kernel-modues.sfs with lots of firmware, manually squashed by stemsee. Kernel is 4G highmem, 1g/3g split 1gb for kernel and 3gb for user/system. So 3gb appears in specs. timer =1000hz.
I forgot to remove suffix so uname -a gives 3.15-EmSee-pae but it is not pae! Sorry about that.

Here is the kernel, initrd and modules.sfs
https://drive.google.com/file/d/0B4GhZV ... edit?usp=1

enjoy!
Attachments
capture22264.jpg
(32.66 KiB) Downloaded 1109 times
Last edited by stemsee on Wed 11 Jun 2014, 09:59, edited 1 time in total.

stemsee

#52 Post by stemsee »

Now posting from DebianDog, booted on FD initrd and 3.14.5 kernel with kernel-modules.sfs (zdrv), all hardware up and running ootb! Nice!

This is fun!! Now for some old pups!

I couldn't get Lazy pup nor Lupi to boot with the FatDog initrd.

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#53 Post by jamesbond »

Just because it is quiet doesn't mean nothing is happening. Work on this is still on-going. Check out the "woof-next" branch of Woof-CE. It is still in early state - but it's moving. Summary here.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#54 Post by 01micko »

General info-

Just remember... remove userspace aufs-utils as kernel-kit wraps the correct version (built against the new headers) in the zdrv sfs.

EDIT: Kernel-kit is now pushed to woof-CE.
Puppy Linux Blog - contact me for access

stemsee

#55 Post by stemsee »

@Jamesbond
How to manage savefile booting with FD initrd???

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#56 Post by jamesbond »

stemsee wrote:@Jamesbond
How to manage savefile booting with FD initrd???
Sorry, can you please clarify your question? Also, if this is Fatdog-related question, that should go to Fatdog thread (use the one you see is still active).
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

stemsee

#57 Post by stemsee »

@jamesbond

Not fatdog proper but the initrd in woof-ng. Does the initrd require a kernel argument to load a puppy.2/3/4sf file and where does it mount it? Is pupsave=ram:/path/to/savefile still valid? And can initrd parse a line DISTRO_PUPSAVE=puppy-save.2/3/4sf

I am trying to boot an alien os but still have puppy savefile.

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#58 Post by jamesbond »

stemsee wrote:Not fatdog proper but the initrd in woof-ng. Does the initrd require a kernel argument to load a puppy.2/3/4sf file and where does it mount it? pupsave=ram:/path/to/savefile still valid?
It is specified in DISTRO_SPECS that got included in initrd by build-iso.sh. You can't simply change them by specifying them from boot parameter (Mick, please correct me if I'm wrong). Fatdog's initrd (the real one, not the one in woof-next --- the one in woof-next's is still Puppy original initrd) does allow you to specify what basesfs you want to load through a boot parameter.

Anyway, basesfs, in Puppy's initrd, gets mounted in /initrd/pup_ro2. ZDRV (the kernel modules) gets mounted in /initrd/pup_z. Savefile gets mounted in /initrd/pup_rw, except when you use PUPMODE=13, where it will get mounted at /initrd/pup_ro1.
Is And can initrd parse a line DISTRO_PUPSAVE=puppy-save.2/3/4sf
I don't know. I don't think you can specify arbitrary names for Puppy savefile, though. Fatdog's initrd, on the other hand, does.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

stemsee

#59 Post by stemsee »

@jamesbond

Thanks again!

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#60 Post by jamesbond »

Hot News!

woof-next now builds the following (will boot up to graphical desktop with rox/jwm - at least in qemu):
- 32/64-bit ubuntu trusty
- 32/64-bit debian sid
- 32/64-bit slackware 14.1
It shouldn't be too difficult to do 32/64-bit debian jessie or 32/64-bit ubuntu utopic for anyone who wants to to do that.

All puppies have native package manager: debian/ubuntu have synaptics configured; slackware will have gslapt configured.

woof-next adapts Puppy to the parent distro; this is a different approach from current Woof2 which adapts the parent distro to Puppy.

The following infrastructure has been setup:
1. Build-time:
- rootfs-packages/debian-setup contains specific files/setup instructions for debian/ubuntu (currently they are shared, if later this is difficult, it can easily be split)
- rootfs-packages/slack-setup contains specific files/setup instructions for slackware.

2. Run-time:
There is an "rc.distro" which comes from the above "distro*-setup" rootfs-package, it is called by rc.sysinit to adapt whatever PATH etc so that puppy can run on top the base distro.

3. Size minimisation - the build infrastructure has commands to take out the most common source of bloats (doc, gtk-doc, etc).

4. Devx can be build in the same way like the basesfs is built (a sample devx pkglist is given for slackware)

5. Brand-new kernel kit from Mick 8) (I think this is already in "testing" branch too).

The builders are more or less finished (unless if someone wants to contribute building from other parents, like Mageia, CentOS, etc - I think for me I'll stop at these three distros). The next (and long) journey is to test and adapt puppy scripts to work on top of these various parent distros.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

Post Reply