Alternative way to build Ubuntu / Debian Puppy [RETIRED]
I built 32/64 bit trusy
and 32/64 bit unicorn
32bit builds work for me, 64 bit builds don't work for me, but I think it may be the initrd.
Very easy to add packages to include in build. I added synaptic, vlc (complains about root), qemu, samba4, python, qasmixer, hardinfo and lots more just by specifying them in the pkglist .... but lost keyboard functionality somewhere!
Builds in record time too, like 20 minutes or so!
N.B. You have to manually change ARCH to amd64 or i386 as the variable doesn't get exported to the deb-build.sh script in /builders
and 32/64 bit unicorn
32bit builds work for me, 64 bit builds don't work for me, but I think it may be the initrd.
Very easy to add packages to include in build. I added synaptic, vlc (complains about root), qemu, samba4, python, qasmixer, hardinfo and lots more just by specifying them in the pkglist .... but lost keyboard functionality somewhere!
Builds in record time too, like 20 minutes or so!
N.B. You have to manually change ARCH to amd64 or i386 as the variable doesn't get exported to the deb-build.sh script in /builders
Yes, a response, finally
You didn't see arch in build.conf created by setup.sh? Then it is a bug that I need to look at. Anyway, the idea is to make it easy even after you run setup.sh to modify the build setup your own way
You didn't see arch in build.conf created by setup.sh? Then it is a bug that I need to look at. Anyway, the idea is to make it easy even after you run setup.sh to modify the build setup your own way
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]
It is amazingly easy! You succeeded there!
Of course I am finding ways to lay down my personal customisations for the build! I actually built a very functional pup a couple weeks ago. But I was doing something else so I didn't bring it up to release standard. Anyway after some trials and errors it looks like I will be building all current distros in a day!!
So I will try to build a Fedora pup, after I create my essentials list, and tray templates, and puppy-pin! etc etc
It's an order of magnitude improvement over woof-ce!
Of course I am finding ways to lay down my personal customisations for the build! I actually built a very functional pup a couple weeks ago. But I was doing something else so I didn't bring it up to release standard. Anyway after some trials and errors it looks like I will be building all current distros in a day!!
So I will try to build a Fedora pup, after I create my essentials list, and tray templates, and puppy-pin! etc etc
It's an order of magnitude improvement over woof-ce!
No.gcmartin wrote:Is CentOS that much different from Fedora/RedHat? Kinda like Ubuntu from Debian? True/false?
red hat : fedora = debian : ubuntu
ubuntu : mint = red hat : centos = fork
Community Enterprise Official Puppy
Iguleder.. you confused someone methinks
-
Anyway, once I have slacko-6.0 out the door I can concentrate further on this wonderful development.
Puppy Linux Blog - contact me for access
- Iguleder
- Posts: 2026
- Joined: Tue 11 Aug 2009, 09:36
- Location: Israel, somewhere in the beautiful desert
- Contact:
I just started messing with containers and wrote my own, small container solution.
I was thinking - we could use containers in Puppy. It could be extremely cool to build a multi-distro Puppy. We could run the X server "natively" and trap distro-dependent files in containers (e.g an Ubuntu container, a Slackware container, etc') that share /tmp with the host (for .X11-unix).
EDIT: attached a screenshot. See how clean and meaningful the process list is. The user doesn't see stuff like syslogd and klogd, so despite of the fact the user runs as root, he or she cannot do any harm. This approach to security is much better than the "spot" thing, IMHO.
I was thinking - we could use containers in Puppy. It could be extremely cool to build a multi-distro Puppy. We could run the X server "natively" and trap distro-dependent files in containers (e.g an Ubuntu container, a Slackware container, etc') that share /tmp with the host (for .X11-unix).
EDIT: attached a screenshot. See how clean and meaningful the process list is. The user doesn't see stuff like syslogd and klogd, so despite of the fact the user runs as root, he or she cannot do any harm. This approach to security is much better than the "spot" thing, IMHO.
- Attachments
-
- container.png
- (67.61 KiB) Downloaded 288 times
-
- container-thumb.png
- (22.7 KiB) Downloaded 399 times
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]
Kernel should look for the file " /sbin/init " by default .stemsee wrote:@jamesbond
I always get no working init found " pass init= option to the kernel" what should that look like init= ?
If that's not there , because /init in initrd.gz does something wrong or is not there actually in the puppy_abc.sfs main SFS file
or is corrupted or hidden by a .wh. AUFS marker file ,
then
Code: Select all
init=/bin/bash
/sbin/init should launch busybox init which should launch /etc/rc.d/rc.sysinit by default ( see man 5 inittab ' sysinit ' entry) ,
which does much for usable filesystem like mounting /proc and /sys .
If you run init=/bin/bash , you need to mount these manually .
@stemsee: upload your initrd somewhere then we can take a look. Like Karl said, perhaps init is missing or corrupt.
I looked at the code. I think it is a good start.Iguleder wrote:I just started messing with containers and wrote my own, small container solution.
Agreed. We can already do that today with chroot, but container offers something even better than that. Or even better - we can run each application in its own container - thus a runaway browser process can't bring down the entire desktop.I was thinking - we could use containers in Puppy. It could be extremely cool to build a multi-distro Puppy. We could run the X server "natively" and trap distro-dependent files in containers (e.g an Ubuntu container, a Slackware container, etc') that share /tmp with the host (for .X11-unix).
I see you changed your mind since our last discussion http://www.murga-linux.com/puppy/viewto ... 660#703660 Anyway, since your container is "init", then who starts klogd? Or is the container code is intended to be the container's init rather than the real init?EDIT: attached a screenshot. See how clean and meaningful the process list is. The user doesn't see stuff like syslogd and klogd, so despite of the fact the user runs as root, he or she cannot do any harm. This approach to security is much better than the "spot" thing, IMHO.
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]
- Iguleder
- Posts: 2026
- Joined: Tue 11 Aug 2009, 09:36
- Location: Israel, somewhere in the beautiful desert
- Contact:
This ain't init - see the code I linked to. The process (contain.c) forks inside the container and changes its name to "init", runs a child process (argv[2]), then does init's signal handling.
The real init starts klogd and when it's time to let the user log in, it traps login in a container
The real init starts klogd and when it's time to let the user log in, it traps login in a container
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]
- Iguleder
- Posts: 2026
- Joined: Tue 11 Aug 2009, 09:36
- Location: Israel, somewhere in the beautiful desert
- Contact:
Containers are a way to run applications from multiple distros in parallel. In many cases, it's a cheap and lightweight alternative to virtualization, because it doesn't require additional software and doesn't have a performance penalty.
Containers are a good way to run packages of another distro, because they allow you to trap its libraries in a sandbox. Like chroot, but more secure, because containers allow you to make sure the "unsafe" applications cannot touch existing processes.
By the way - I just added support for building ISOs using xorriso instead of mkisofs. I want to upgrade isolinux, so we can build UEFI-capable images in the future.
Containers are a good way to run packages of another distro, because they allow you to trap its libraries in a sandbox. Like chroot, but more secure, because containers allow you to make sure the "unsafe" applications cannot touch existing processes.
By the way - I just added support for building ISOs using xorriso instead of mkisofs. I want to upgrade isolinux, so we can build UEFI-capable images in the future.
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]
@Jamesbond
Here is the initrd generated by woof-next for 64 bit trusty
https://drive.google.com/file/d/0B4GhZV ... sp=sharing
[/url]
Here is the initrd generated by woof-next for 64 bit trusty
https://drive.google.com/file/d/0B4GhZV ... sp=sharing
[/url]
@Iguleder - understood. Your pull request is merged, too.
@gcmartin: container is an example of http://en.wikipedia.org/wiki/Operating_ ... ualization.
@stemsee: your initrd is identical to mine (except the DISTRO_TARGETARCH which is informative only - and I've fixed the bug now, thanks), and mine boots fine in qemu. How do you test it? Which kernel do you use?
@gcmartin: container is an example of http://en.wikipedia.org/wiki/Operating_ ... ualization.
@stemsee: your initrd is identical to mine (except the DISTRO_TARGETARCH which is informative only - and I've fixed the bug now, thanks), and mine boots fine in qemu. How do you test it? Which kernel do you use?
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]
Thanks @jamesbond, providing for a consistent definition for "Containers". Good read for all. Single base running several/many "jails", each thinking they are exclusive base. Another excellent explanation found here.
My 1st remembrance was with Linux-VServer in 2003 and OpenVZ.
My 1st remembrance was with Linux-VServer in 2003 and OpenVZ.
Last edited by gcmartin on Mon 07 Jul 2014, 13:18, edited 1 time in total.