Page 4 of 6
Posted: Mon 30 Jun 2014, 17:01
by stemsee
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
Posted: Mon 30 Jun 2014, 18:02
by jamesbond
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
Posted: Mon 30 Jun 2014, 18:26
by stemsee
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!
Posted: Mon 30 Jun 2014, 19:29
by Iguleder
Wow, sounds too good to be true.
Ummmm ... I think it's time to build CentOP: Community Enterprise Official Puppy
Posted: Mon 30 Jun 2014, 19:43
by stemsee
@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!
Posted: Mon 30 Jun 2014, 21:53
by gcmartin
Is CentOS that much different from Fedora/RedHat? Kinda like Ubuntu from Debian? True/false?
Posted: Mon 30 Jun 2014, 22:04
by 01micko
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.
Posted: Mon 30 Jun 2014, 23:16
by gcmartin
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.
Posted: Thu 03 Jul 2014, 12:29
by stemsee
@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= ?
Posted: Fri 04 Jul 2014, 04:19
by jamesbond
stemsee, yes the initrd works for 64-bit too.
Posted: Fri 04 Jul 2014, 20:04
by Iguleder
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.
Posted: Sat 05 Jul 2014, 11:37
by Karl Godt
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
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 .
Posted: Sat 05 Jul 2014, 16:43
by jamesbond
@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?
Posted: Sat 05 Jul 2014, 17:04
by Iguleder
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
Posted: Sat 05 Jul 2014, 17:51
by gcmartin
"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?
Posted: Sat 05 Jul 2014, 22:27
by Iguleder
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.
Posted: Mon 07 Jul 2014, 00:28
by stemsee
@Jamesbond
Here is the initrd generated by woof-next for 64 bit trusty
https://drive.google.com/file/d/0B4GhZV ... sp=sharing
[/url]
Posted: Mon 07 Jul 2014, 11:05
by jamesbond
@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?
Posted: Mon 07 Jul 2014, 12:18
by gcmartin
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.
Posted: Mon 07 Jul 2014, 13:10
by stemsee
@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!