Alternative way to build Ubuntu / Debian Puppy [RETIRED]

Message

stemsee · #61 Post by **stemsee** » Mon 30 Jun 2014, 17:01

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

jamesbond · #62 Post by **jamesbond** » Mon 30 Jun 2014, 18:02

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

stemsee · #63 Post by **stemsee** » Mon 30 Jun 2014, 18:26

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!

Iguleder · #64 Post by **Iguleder** » Mon 30 Jun 2014, 19:29

Wow, sounds too good to be true.

Ummmm ... I think it's time to build CentOP: Community Enterprise Official Puppy

stemsee · #65 Post by **stemsee** » Mon 30 Jun 2014, 19:43

@jamesbond

Quick question

When I specify a adrv and ydrv in initrd (woof-ng) the system complains of /pup_z duplicate .. do you know why? When I remove the ydrv entry all is fine.

@Iguleder

Offering support on CentOP might see you become the first puppy billionaire!

gcmartin · #66 Post by **gcmartin** » Mon 30 Jun 2014, 21:53

Is CentOS that much different from Fedora/RedHat? Kinda like Ubuntu from Debian? True/false?

01micko · #67 Post by **01micko** » Mon 30 Jun 2014, 22:04

gcmartin wrote:Is CentOS that much different from Fedora/RedHat? Kinda like Ubuntu from Debian? True/false?

No.

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.

gcmartin · #68 Post by **gcmartin** » Mon 30 Jun 2014, 23:16

01micko wrote: ...Iguleder.. you confused someone methinks ...

Thanks Mick, was wondering whether the base would/could be used for related distros. And, whether CentOS is implied as a suggested base.

stemsee · #69 Post by **stemsee** » Thu 03 Jul 2014, 12:29

@jamesbond

Is the woof-ng initrd good for 64 bit aswell? I always get no working init found " pass init= option to the kernel" what should that look like init= ?

jamesbond · #70 Post by **jamesbond** » Fri 04 Jul 2014, 04:19

stemsee, yes the initrd works for 64-bit too.

Iguleder · #71 Post by **Iguleder** » Fri 04 Jul 2014, 20:04

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.

Karl Godt · #72 Post by **Karl Godt** » Sat 05 Jul 2014, 11:37

stemsee wrote:@jamesbond
I always get no working init found " pass init= option to the kernel" what should that look like init= ?

Kernel should look for the file " /sbin/init " by default .

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

as kernel parameter may work or work not .

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

jamesbond · #73 Post by **jamesbond** » Sat 05 Jul 2014, 16:43

@stemsee: upload your initrd somewhere then we can take a look. Like Karl said, perhaps init is missing or corrupt.

Iguleder wrote:I just started messing with containers and wrote my own, small container solution.

I looked at the code. I think it is a good start.

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

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.

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 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?

Iguleder · #74 Post by **Iguleder** » Sat 05 Jul 2014, 17:04

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

gcmartin · #75 Post by **gcmartin** » Sat 05 Jul 2014, 17:51

"Containers"

Isn't there a Virtualization solution that does this, already? Thus, its an off-the-shelf solution. Right/wrong?

Also, isn't it still free to use?

Iguleder · #76 Post by **Iguleder** » Sat 05 Jul 2014, 22:27

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.

stemsee · #77 Post by **stemsee** » Mon 07 Jul 2014, 00:28

@Jamesbond
Here is the initrd generated by woof-next for 64 bit trusty
https://drive.google.com/file/d/0B4GhZV ... sp=sharing
[/url]

jamesbond · #78 Post by **jamesbond** » Mon 07 Jul 2014, 11:05

@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 · #79 Post by **gcmartin** » Mon 07 Jul 2014, 12:18

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.

stemsee · #80 Post by **stemsee** » Mon 07 Jul 2014, 13:10

@Jamesbond

I use kernel 3.15.1Emsee 64bit as posted in repacked fatdog631. iso on your fatdog 631 thread! I boot a frugal install on bare metal!

(old)Puppy Linux Discussion Forum

(old)Puppy Linux Discussion Forum

Alternative way to build Ubuntu / Debian Puppy [RETIRED]