I think an improvement might be to allow specifying additional repositories as a variable in the script. Of course, I'm thinking of Chrome, but there are lots of other "independent" Debian/Ubuntu repositories out there that people might want to use.fredx181 wrote:Thanks guys !
It creates new /etc/apt/sources.list and includes the right (stretch)dog repository depending if it's 32 or 64 bit build.dancytron wrote:I take it that it uses the list of repositories from the distribution you are using to run it? That's what it seemed to do. edit: no it doesn't
/snip/
Fred
Create Debian 9 (Stretch) minimal ISO similar to DebianDog
fredx181 wrote: A few questions:
- 01-filesystem.squashfs, what's the size (from right-click > How big ?)?
- From what OS you did run it ?
- Enough free space on the partition you build on ?
Fred
1) 133.5MB for the 01-filesystem.squashfs
2) Ran it from Trinity-Stretch 32
3) a 3GB build partition, then moved what I needed over to my big "frugal" partiton with all the various Puppies, DDogs, Trinities and Toni's Mintpup, and BAMMMM---it booted like a champ once I realized the dumba## stunt I was pulling when first trying to get it to boot (plz don't ask, it is embarrassing, lol).
I AM LOVE with this process----oooooh, the moditifcations to the build-script are running through my head, question popups for what DE you want, what borwser, what email, etc, etc......the customization could be incredible.
I am not going to bed NOW (unless the wife come stomping down the stairs and flashes me the "I am going to KILL YOU" look, lol)....I am having too much fun here.
Let's be careful not to kill the elegant simplicity of it.belham2 wrote:fredx181 wrote: A few questions:
- 01-filesystem.squashfs, what's the size (from right-click > How big ?)?
- From what OS you did run it ?
- Enough free space on the partition you build on ?
Fred
1) 133.5MB for the 01-filesystem.squashfs
2) Ran it from Trinity-Stretch 32
3) a 3GB build partition, then moved what I needed over to my big "frugal" partiton with all the various Puppies, DDogs, Trinities and Toni's Mintpup, and BAMMMM---it booted like a champ once I realized the dumba## stunt I was pulling when first trying to get it to boot (plz don't ask, it is embarrassing, lol).
I AM LOVE with this process----oooooh, the moditifcations to the build-script are running through my head, question popups for what DE you want, what borwser, what email, etc, etc......the customization could be incredible.
I am not going to bed NOW (unless the wife come stomping down the stairs and flashes me the "I am going to KILL YOU" look, lol)....I am having too much fun here.
How about just embedding some different "recipes" inside the script but commented out? Want xfce, uncomment the xfce line. Want lxde, then uncomment the lxde line. Want KDE with libre-office, Firefox, Thunderbird, Gimp, KODI and all the other goodies, then uncomment that line.
That could then become an easy way to share configs, by just saying, "This is the recipe that I used, just paste it into the script and go."
The script is really quite simple at the moment so would be a good time to think about modularising it in such a way that it could easily be amending for particular purposes/additions/distributions without changing the resulting core script. I played with mcewanw's wex recently and it has some kind of facility for addon functions without needing to change original script at all, but I'm pretty much a novice myself when it comes to scripting.
wiak
wiak
I am sending you PWF v4.5 which moves rc.network into /etc/pwf. This should solve your problem.saintless wrote:Removing /etc/rc.d, /etc/DISTRO_SPECS, and /initrd in remasterdog and remastercow scripts is sometning I insisted to include to prepare DebianDog for puppy-boot option (using initrd.gz from puppy with debian kernel).fredx181 wrote:t...his line should be removed (or commented out:Now that peasywifi is in the dog repositories, I guess I'll have to update all remaster script packages that have similar as this line (not sure yet, maybe easier to consult rcrsn51 about a small change in peasywifi) sigh...Code: Select all
rm -rf tmpa/etc/rc.d
Better remove the lines above from the scripts to make easier puppy developers to keep the same structure for packages like peasywifi (inside /etc/rc.d for puppy and dog based system). Porteus-boot and live boot will not create /initrd or /etc.rc.d (both are puppy specific for important configuration files).
Toni
The service script in /etc/init.d just needs to point to the new location.
Last edited by rcrsn51 on Thu 03 Aug 2017, 00:40, edited 1 time in total.
I note fred that you say this script can be run from any Debian-based OS. I can't help but wonder, if it is 'possible' it could be made to run from a Puppy (?) - in particular, does 'debootstrap' program need a debian-based system or can a different Linux be used for that chroot installed debian environment (followed by rest of script?).
https://wiki.debian.org/Debootstrap
wiak
EDIT:
Seems that one advantage of debootstrap over multistrap is that debootstrap doesn't itself need dpkg/apt. Seems to me that once the new debootstrap debian system is built in a chroot then that could be used to complete the build(?) - i.e. maybe arranged thus could then indeed use even a non-debian-type Puppy system (or any Linux system) for the build?
multistrap:
https://wiki.debian.org/Multistrap
https://wiki.debian.org/Debootstrap
Just thought it would be great if a Puppy user could use this to immediately build a DebianDog to a usb stick or something (or maybe a mod of this script could do that?).debootstrap is a tool which will install a Debian base system into a subdirectory of another, already installed system. It doesn't require an installation CD, just access to a Debian repository. It can also be installed and run from another operating system, so, for instance, you can use debootstrap to install Debian onto an unused partition from a running Gentoo system.
wiak
EDIT:
Seems that one advantage of debootstrap over multistrap is that debootstrap doesn't itself need dpkg/apt. Seems to me that once the new debootstrap debian system is built in a chroot then that could be used to complete the build(?) - i.e. maybe arranged thus could then indeed use even a non-debian-type Puppy system (or any Linux system) for the build?
multistrap:
https://wiki.debian.org/Multistrap
Its main limitation compared to debootstrap is that it uses apt and dpkg directly so can only work on a debian system - debootstrap depends on nothing but shell, wget, binutils and thus can run pretty-much anywhere.
The main advantage with multistrap is the flexibility to mix packages from different repositories and different suites and manage customised variants with configuration files.
Last edited by wiak on Thu 03 Aug 2017, 01:00, edited 1 time in total.
wiak wrote:Just thought it would be great if a Puppy user could use this to immediately build a DebianDog to a usb stick or something (or maybe a mod of this script could do that?).wiak
The script needs apt-get.Run from a Debian based system 32-bit or 64-bit (will create i686 (32-bit) or x86_64 (64-bit) live system accordingly to the architecture of the OS you are running from)
Yes, I know the current mklive build script needs apt-get, but I have pointed out that debootstrap itself doesn't. I wondered if the debootstrap-created debian system (in a chroot) could as a secondary stage then be used to complete the build process (since that could use apt-get whereas the underlying system could be say a Puppy which itself couldn't use apt-get)? If you see what I mean.
Main thing I was thinking was that the script 'debootstrap' could itself be run under Puppy linux (or other Linux if desired) - creating a Debian system in a chroot (jail/container), and the rest of the mklive script run from that chroot (jail/container) thereafter...
wiak
Main thing I was thinking was that the script 'debootstrap' could itself be run under Puppy linux (or other Linux if desired) - creating a Debian system in a chroot (jail/container), and the rest of the mklive script run from that chroot (jail/container) thereafter...
wiak
Hi wiak,
Eight months ago I posed the challenge of adding adrive builder, apt or synaptic to Puppies (in general), mentioning those which already included apt and synaptic. http://murga-linux.com/puppy/viewtopic.php?t=109436.
To date, only Pelo has suggested this apt/synaptic solution. http://murga-linux.com/puppy/viewtopic. ... 960#961960. Neither Pelo nor I claim to have any expertise in programming. And I haven't had the time to explore the validity of his response.
You're welcome to 'give it a go.'
mikeslr
Eight months ago I posed the challenge of adding adrive builder, apt or synaptic to Puppies (in general), mentioning those which already included apt and synaptic. http://murga-linux.com/puppy/viewtopic.php?t=109436.
To date, only Pelo has suggested this apt/synaptic solution. http://murga-linux.com/puppy/viewtopic. ... 960#961960. Neither Pelo nor I claim to have any expertise in programming. And I haven't had the time to explore the validity of his response.
You're welcome to 'give it a go.'
mikeslr
That's not what I'm suggesting or have in mind mikeslr. Rather, I'm suggesting it should be reasonably easily possible to modify the fred-provided mklive-stretch build system in the first thread of this post such that it can be run from a standard Puppy (or other Linux system) - the result will still be a debian-live debiandog type system rather than an otherwise standard Puppy with apt/dpkg capability.mikeslr wrote: Eight months ago I posed the challenge of adding adrive builder, apt or synaptic to Puppies (in general), mentioning those which already included apt and synaptic. http://murga-linux.com/puppy/viewtopic.php?t=109436.
I do have a technical background but it is in project management and not myself programming per se. As a project manager I look for general purpose methodologies rather than a specific implementation (such as, in this case, a mklive-stretch build system that needs to be run from a Debian apt/dpkg capable system - via chroot second stage, I doubt that limitation is necessary, and via modularisation I do not see that 'stretch' needs to be a specified limitation either, so if modularised appropriately I believe it shouldn't be later necessary to rewrite an almost identical mklive build script to build non-stretch system). Making a good project great is often about implementing a specific idea in a more general purpose manner (indeed traditional Unix philosophy works in that direction).
EDIT: If you go too far down the path on a design that is very specific it becomes much harder later to universalise/generalise the method - hence the importance to modularise and generalise as close as possible to the germination of the project idea. To put it another way, at the beginning, things are reasonably simple; that's the best time to invest in looking for most general purpose/flexible solutions.
wiak
EDIT2: I have total faith, by the way, that Fred himself is perfectly capable of relatively easily making this script work the way I suggest. All changes require some extra work (and tests of course) but now would be the time... But of course he might not like the suggested approach or want to implement it, which is fine.
Hi wiak,
I think I see what you mean, something like: once the chroot is created by debootstrap, Debian management will 'take over' so it could maybe work from a non-Debian OS, right?
Well, I had a quick look at the dependencies for debootstrap in DEBIAN/control file, only mentioned is "wget", so that looks good.
But further I looked inside the debootstrap script and noticed some "dpkg" command lines, so the host OS probably needs dpkg installed to make debootsrap work.
On line 109 of the mklive-stretch script (first stage, still outside chroot):
debootstrap is no more than a script and the other dependencies can be installed on a Puppy I guess (xorriso and isolinux are just to create ISO, but can be done in other ways also, using genisoimage, and squashfs-tools (for mksquashfs) is included in any puppy)
Then line 115 runs debootstrap
I attached the debootstrap script, to test in puppy, just extract it somewhere in PATH, e.g. /usr/bin/
So maybe, just maybe, if a Puppy has dpkg, things might work.
To be honest, at this point of time, I don't feel like trying to make this work in puppy, prefer to focus now on other things.
But if you or anyone want to go the road to make it work on Puppy, I can help in some way maybe.
I think the best is to try first if debootsrap works OK, by for example for 32-bit:
Fred
I think I see what you mean, something like: once the chroot is created by debootstrap, Debian management will 'take over' so it could maybe work from a non-Debian OS, right?
Well, I had a quick look at the dependencies for debootstrap in DEBIAN/control file, only mentioned is "wget", so that looks good.
But further I looked inside the debootstrap script and noticed some "dpkg" command lines, so the host OS probably needs dpkg installed to make debootsrap work.
On line 109 of the mklive-stretch script (first stage, still outside chroot):
Code: Select all
apt-get install debootstrap wget xorriso isolinux xz-utils squashfs-tools -y --force-yes
Then line 115 runs debootstrap
Code: Select all
debootstrap --arch=$ARCH --variant=minbase stretch chroot http://ftp.us.debian.org/debian/
So maybe, just maybe, if a Puppy has dpkg, things might work.
To be honest, at this point of time, I don't feel like trying to make this work in puppy, prefer to focus now on other things.
But if you or anyone want to go the road to make it work on Puppy, I can help in some way maybe.
I think the best is to try first if debootsrap works OK, by for example for 32-bit:
Code: Select all
mkdir -p stretch/chroot && cd stretch
debootstrap --arch=i386 --variant=minbase stretch chroot http://ftp.us.debian.org/debian/
Fred
- Attachments
-
- debootstrap.tar.gz
- debootstrap (script only)
- (5.46 KiB) Downloaded 595 times
Last edited by fredx181 on Thu 03 Aug 2017, 08:30, edited 2 times in total.
Probably the best is to modify the remaster scripts and others (so that it doesn't remove /etc/rc.d) and build new packages because there are more programs that include /etc/rc.d, e.g. your peasy firewall monitor (and maybe more I can't think of now)rcrsn51 wrote:I am sending you PWF v4.5 which moves rc.network into /etc/pwf. This should solve your problem.
But thanks anyway !
Fred
Thanks Fred,fredx181 wrote: But further I looked inside the debootstrap script and noticed some "dpkg" command lines, so the host OS probably needs dpkg installed to make debootsrap work.
I quickly looked inside debootstrap, and it seems to me that you just need to give the arch and for such case dpkg being installed isn't a requirement. Here are the lines from debootstrap usage I noticed (particularly note the last line):
Code: Select all
usage()
{
echo "Usage: ${0##*/} [OPTION]... <suite> <target> [<mirror> [<script>]]"
echo "Bootstrap a Debian base system into a target directory."
echo
cat <<EOF
--help display this help and exit
--version display version information and exit
--verbose don't turn off the output of wget
--download-only download packages, but don't perform installation
--print-debs print the packages to be installed, and exit
--arch=A set the architecture to install (use if no dpkg)
[ --arch=powerpc ]
EDIT: Having said that, I maybe will do my best to try and check debootstrap working in a Puppy since I think I understand maybe enough for that testing stage. First I have to install a Puppy though since I don't have one on here just now! I'll try on a Slacko, just for proof of concept...
wiak
Last edited by wiak on Thu 03 Aug 2017, 08:54, edited 1 time in total.
Ok, just a matter of trying it out then, if the debootstrap process works properly, then simply do (chroot binary required):wiak wrote:I quickly looked inside debootstrap, and it seems to me that you just need to give the arch and for such case dpkg being installed isn't a requirement. Here are the lines from debootstrap usage I noticed (particularly note the last line):
Code: Select all
chroot chroot # if chroot is the name of directory already created
EDIT: sorry there's more required to test that, see here:
https://github.com/DebianDog/MakeLive/b ... -in-chroot
@dancytron
Yes, good idea, probably that's rather easy to implement.I think an improvement might be to allow specifying additional repositories as a variable in the script. Of course, I'm thinking of Chrome, but there are lots of other "independent" Debian/Ubuntu repositories out there that people might want to use.
You think of also your special setup for running chrome as normal user ?
Btw, as it is now there's only root account, no multiuser support I tested yet.
Fred
Sorry Fred,
I've downloaded Puppy Slacko but probably won't have time to try debootstrap out with it until tomorrow (hope I can find chroot program for Slacko - otherwise I'll try XenialPup or similar). I am pretty confident it should work anyway and it seems I could even run the DebianDog at same time as the Pup!!! since that's what chroot with all these mount commands of /proc and so on should allow. I have actually since come across "James B" detailing how to run Slacko at same time as FatDog via chroot mechanisms here (not that this has anything to do with debootstrap idea...):
http://www.lightofdawn.org/wiki/wiki.cg ... koInFatdog
It is all very exciting stuff anyway. I can't help wondering what the future of Puppy itself is though since debootstrap can create such a small Debian, but I guess there is room for all and maybe a Puppy with a chroot Debian (or thus created debiandog) running alongside is also a useful possibility (or as with the FatDog example, but instead running Puppy inside a DebianDog via a chroot).
Main thing for me for now though is trying to get a mklive debiandog working via your script but using Puppy system as the host build system.
wiak
I've downloaded Puppy Slacko but probably won't have time to try debootstrap out with it until tomorrow (hope I can find chroot program for Slacko - otherwise I'll try XenialPup or similar). I am pretty confident it should work anyway and it seems I could even run the DebianDog at same time as the Pup!!! since that's what chroot with all these mount commands of /proc and so on should allow. I have actually since come across "James B" detailing how to run Slacko at same time as FatDog via chroot mechanisms here (not that this has anything to do with debootstrap idea...):
http://www.lightofdawn.org/wiki/wiki.cg ... koInFatdog
It is all very exciting stuff anyway. I can't help wondering what the future of Puppy itself is though since debootstrap can create such a small Debian, but I guess there is room for all and maybe a Puppy with a chroot Debian (or thus created debiandog) running alongside is also a useful possibility (or as with the FatDog example, but instead running Puppy inside a DebianDog via a chroot).
Main thing for me for now though is trying to get a mklive debiandog working via your script but using Puppy system as the host build system.
wiak
@Fred: Here is my test:
I booted Stretchdog32 off an ISObooter flash drive. I plugged in another flash drive with a big ext4 partition and ran the mklive script from there. It chugged away and eventually made the ISO. I copied it back to the ISObooter drive and rebooted. It worked!
But you quickly realize how many extra little things you need to make a practical OS.
BTW, in the middle of the process, a "Done" message appears with a pause. An impatient person would close the terminal window, assuming that they were done.
I booted Stretchdog32 off an ISObooter flash drive. I plugged in another flash drive with a big ext4 partition and ran the mklive script from there. It chugged away and eventually made the ISO. I copied it back to the ISObooter drive and rebooted. It worked!
But you quickly realize how many extra little things you need to make a practical OS.
BTW, in the middle of the process, a "Done" message appears with a pause. An impatient person would close the terminal window, assuming that they were done.
Hi Fred and All,
Still trying to get my head around this. As I understand it, the ISO is created in a chroot environment run from another OS. But which actually has to have access to the internet?
My two main computers are a desktop which can only access the internet via wifi, and a laptop, which being portable, can be ported sufficiently close to my router that I can use an ethernet cable.
I'd rather do my exploring of, to me, uncharted territory from my desktop. Is that possible?
Thanks,
mikesLr
Still trying to get my head around this. As I understand it, the ISO is created in a chroot environment run from another OS. But which actually has to have access to the internet?
My two main computers are a desktop which can only access the internet via wifi, and a laptop, which being portable, can be ported sufficiently close to my router that I can use an ethernet cable.
I'd rather do my exploring of, to me, uncharted territory from my desktop. Is that possible?
Thanks,
mikesLr
Built another one. I attempted to add all the DD specific programs and test a few.
This is the application list I used.
I installed Chrome with deb install program. Runs fine with --no-sandbox. Tested apt2sfs, load sfs, gtk youtube, dog radio and edit-sfs and they all worked.
Of course, there is no right click integration and there weren't any filetypes. I had to pick edit sfs and load sfs from the "open with" menu.
It seems when I use save2flash that it doesn't flush the memory like the newer version does. In other words, after I installed Chrome, it seemed like each time I used save2flash it was saving that whole huge amount rather than just what I'd added since the last time I used save2flash. Or I might just be imagining it?
Haven't tried a remaster yet. Maybe later.
edit: Just did a quick remaster. Seems successful. The "double mount" bug has returned though, i.e. when the script pauses to manually cleanout files, there are no files if you go directly to drive by clicking sda2, but there are files if you go by way of /mnt/sda2.
This is the application list I used.
Code: Select all
export INSTALL="live-boot wget net-tools ifupdown wireless-tools sysvinit-core xserver-xorg-core xserver-xorg psmisc fuse x11-utils x11-xserver-utils dbus-x11 busybox sudo mawk xinit xterm openbox obconf menu leafpad pcmanfm lxpanel pciutils usbutils gparted file rsync dosfstools parted nano pv synaptic volumeicon-alsa alsa-utils firefox-esr pup-volume-monitor pm-utils apt2sfs debdoginstallscripts debdogmountscripts desktop-drive-icons desktop-editor dogradio edit-sfs-pcmanfm filemnt-pcmanfm fixdepinstall gsu isotools makedebpackage mount-wizard mpv pavrecord pburn pfind portablesfs-loadsfs-fuse quick-remaster remaster-scripts sfsload upgrade-kernel youtube-get youtube-viewer"
Of course, there is no right click integration and there weren't any filetypes. I had to pick edit sfs and load sfs from the "open with" menu.
It seems when I use save2flash that it doesn't flush the memory like the newer version does. In other words, after I installed Chrome, it seemed like each time I used save2flash it was saving that whole huge amount rather than just what I'd added since the last time I used save2flash. Or I might just be imagining it?
Haven't tried a remaster yet. Maybe later.
edit: Just did a quick remaster. Seems successful. The "double mount" bug has returned though, i.e. when the script pauses to manually cleanout files, there are no files if you go directly to drive by clicking sda2, but there are files if you go by way of /mnt/sda2.