Create Debian 9 (Stretch) minimal ISO similar to DebianDog

[belham2]

Here is another practical tool for extracting a folder of debs. (for further converting).
http://smokey01.com/pemasu/pet_packages ... -0.0.1.pet

Thanks, Backi. I just went back to the old trusted way I know: uextract, then terminal mksquashfs. I just get tired sometimes of having to bend my lazy butt out of the chair and start typing in the terminal to mksquashfs with parameters commands. Guess I'm not only getting old, but terribly lazy. Anyway, had a productive session here.....told myself that this XFCE I built cannot go over 280mb max without a major browser, and cannot go over 400mb max when a major browser sfs is loaded. The browser is firefox-45.9, and I made an SFS of it just an hr ago. This sfs sits in the frugal install XFCE folder waiting to be punched alive with SFS-Load GUI. Here's everything I've got included in this XFCE build:

-QtWeb 3.8.5 (build 108---mike's version on murga here, you cannot use qtweb from debian repos otherwise https will be non-functional)
-Redshift
-htop
-pupmd5sum
-conky everything + toggle.desktop control
-pulseaudio + pavucontrol (had problems with alsa & xfce)
-mtpaint
-themes package for xfce
-icons package for xfce
-uextract
-evince
-dog radio
-gnome player
-vlc player
-all of rcrsn51's scripts
-all of Fred's scripts
-claws email client
-gedit + leafpad
-about ~5mb of various libs needed for various things
-and then, finally, everything that xfce4 and xfce4-gooodies brings in, which is a lot

So when booted up frugally, I'm at ~280mb. When the firefox-45.9.sfs gets loaded, for heavy duty work (Youtube, etc), it all comes in at 396mb.....right under my limit. This build version is moving up into my top 3 or 4 rotation of all frugal installs on this 250GB external drive I use. And that is saying something since I keep up-to-date 21 frugal installs of various DDogs & many diff Pup versions. It's a little nuts, but I can think of worse hobbies----besides, I have melded (and got running stably) so many things from the puppy world into the DDog world that I think Dr. Frankenstein himself would be proud

Now, my Frankenstein tendency is going to focus the rest of the evening on the budgie-desktop ddog build, most of it sitting lonely & neglected in its frugal folder. Booting to desktop is almost there, just have to make a few tweaks in the build-setup.

[belham2]

Hi all,

Just wanted to give a headsup for ddog-script builders, if you need a lightfast, blazing fast speadshet, puppy's dependable "mtcelledit" works like crazy. At less than 200kb install, for most simple spreadsheet purposes, you can't beat it.

[fredx181]

Hi all,

@ Andres and wiak

Code: Select all

chroot_in () {

give me this /bin/bash: chroot_in:command not found.

Indeed on Wheezy it got stuck on that for me also.
I suspect that the chroot version from wheezy is too old, doesn't understand: /bin/bash -c <function>

How it's done is like this:

Code: Select all

chroot_in () {
do this
do that
}
export -f chroot_in

chroot chroot /bin/bash -c chroot_in # no go in wheezy

So I tested to change to:

Code: Select all

cat << "EOF" | chroot chroot
do this
do that
EOF

That works in Wheezy but the downside is that no user input is possible in chroot, e.g. got stuck on keyboard config dialog or to set root password.
So modified a little (experimental) to make it run without the user input for the above. (only at the end for compression choice, but that's already out of the chroot)
End result is that the keyboard layout is set to US English by default and the root password is not set (recommended to do so afterwards, btw, when you have booted the live system)
Attached mklive-stretch-mod.gz (remove fake.gz and make executable) so this works on Wheezy also.
(this is at the same time learning experience for my plan to run the script with minimum of user input, at the beginning is OK, but rather not during running)

@ wiak
Very weird indeed the fact that debootstrap does work on (most newer?) puppies and not on Xenialdog.
I've spend a lot of time googling to search for solution, but couldn't find.
I will add cpio to the install commands at the start of script when I make new release.

@zagreb

after quick remaster it does not
remain...
what is solution?
regards.

mount -t tmpfs -o "remount,size=130%" tmpfs /mnt/live/memory/changes

One option is to add the line in /etc/rc.local, before the "exit 0"

Fred

[fredx181]

Hi Belham,

Good to see your enthusiasm !
Besides adding some checkboxes to the GUI and making user input during run as less as possible, I'm not sure what can be done more.
I had in mind a while back to implement different choices for pre-configured desktop environments but that (if possible) will be very complicated and will never be even close to perfect, I guess.
On the other hand, how it is now, the install choices, doesn't work well in all cases, just as example: your xfce setup, it needs fixes that an average user may not know about.

About deb to sfs, I think it's not a good idea, because most .deb packages require dependencies, and people might think easily that creating an sfs from deb will just work, which is not in most cases.
Apt2sfs however does handle dependencies well (but not what you're looking for, i think).

Fred

[wiak]

Hi Fred and others,

In case you missed my debootstrapDebian project post, you might also like to check out the 'crouton' project murga forum member jd7654 informed me of (and also look at his nice debootstrapDebian-xfce early build attempt within Quirky). Crouton is for chroot Linux inside Chromium OS but the crouton target scripts (for xfce, xfce-desktop, lxde etc) look interesting for extracting build-script additional ideas:

http://www.murga-linux.com/puppy/viewto ... 830#963830

http://www.murga-linux.com/puppy/viewto ... 838#963838

wiak

[dancytron]

Hi Belham,

Good to see your enthusiasm !
Besides adding some checkboxes to the GUI and making user input during run as less as possible, I'm not sure what can be done more.
I had in mind a while back to implement different choices for pre-configured desktop environments but that (if possible) will be very complicated and will never be even close to perfect, I guess.
On the other hand, how it is now, the install choices, doesn't work well in all cases, just as example: your xfce setup, it needs fixes that an average user may not know about.

About deb to sfs, I think it's not a good idea, because most .deb packages require dependencies, and people might think easily that creating an sfs from deb will just work, which is not in most cases.
Apt2sfs however does handle dependencies well (but not what you're looking for, i think).

Fred

I agree with you on the pre-configured desktops. If you do that, you'll multiply the number of little bugs that people will expect you to track down. It will hold the whole thing back. Your script shouldn't try to do that for people. That's what people should do with the script (if that makes sense) and then they can report back what worked.

Two ideas that might make that easier.

First, a log file that shows exactly what the input was for the distribution you just created that someone can post, another person can download, and then paste the exact same choices in to reproduce the other person's build. It might even be a readme.txt file that automatically gets copied to /root/documents that says something like, "This distribution was built with mklive-stretch script revision mm-dd-yyyy with the following [32/64] bit packages: x, y, z etc"

Second, my idea from before, to separate the app's that build the desktop into a separate field so it is easy for people to (for example) delete all the openbox stuff and put lxde, xfce or whatever in its place.

Keep up the great work. This is the most interesting thing I've seen in a long time.

Dan

[wiak]

I agree with you on the pre-configured desktops. If you do that, you'll multiply the number of little bugs that people will expect you to track down. It will hold the whole thing back. Your script shouldn't try to do that for people. That's what people should do with the script (if that makes sense) and then they can report back what worked.

Two ideas that might make that easier.

First, a log file that shows exactly what the input was for the distribution you just created that someone can post

As I also said earlier, a log file generating capability would be VERY useful.

As for the likes of offering the possibility of pre-configured desktops, one way round that is to use two scripts (the second being an entirely optional plugin, so not even needed by default) - the second script (code plugin) simply being sourced as I note done inside the bash/gtkdialog program wex. Uses very simple code-plugin constructs like:

Code: Select all

   if [ -s "${PROGRAMTMPHOME}/plugins/mp3.plug" ];then
    . "${PROGRAMTMPHOME}/plugins/mp3.plug"
   else
    acodec="libmp3lame"
    avformat="mp3"
   fi # mp3.plug

For example, you could have similar construct like:

Code: Select all

   if [ -s "${HOME}/.mklive/plugins/windowmanager.plug" ];then
    . "${HOME}/.mklive/plugins/windowmanager.plug"
   else
     export BASE_APPS_INSTALL="openbox obconf menu leafpad pcmanfm lxpanel gparted parted pv synaptic volumeicon-alsa alsa-utils viewnior firefox-esr=24.8.0esr-1~deb8u2 pm-utils xdotool wmctrl desktop-file-utils mime-support cryptsetup-bin squashfs-tools conky lxrandr lxinput lxappearance fakeroot xserver-xorg-input-evdev pfind"
   fi # windowmanager.plug

The advantage of doing it that way is that you can still provide your original code after the 'else' statement, but also provide plugin alternatives if you so wished (and let the user do their own support of that if you wish).

wiak

[jd7654]

Second, my idea from before, to separate the app's that build the desktop into a separate field so it is easy for people to (for example) delete all the openbox stuff and put lxde, xfce or whatever in its place.

Keep up the great work. This is the most interesting thing I've seen in a long time.

I second your second. You could kinda follow the modules of porteus for the sections of customization:
000-kernel.xzm
001-core.xzm
002-xorg.xzm
003-mate.xzm
04-firefox.xzm
Separate sections for core, xwin, desktop, apps, and DD and Puppy customizations/scripts.

I think that's what belham was referring to also, their custom iso builder, which just mixed and matched those modules.

Great little project, fulfilled its purpose and more. Anything else is icing on the cake.

[belham2]

Hi Belham,

Good to see your enthusiasm !
Besides adding some checkboxes to the GUI and making user input during run as less as possible, I'm not sure what can be done more.
I had in mind a while back to implement different choices for pre-configured desktop environments but that (if possible) will be very complicated and will never be even close to perfect, I guess.
On the other hand, how it is now, the install choices, doesn't work well in all cases, just as example: your xfce setup, it needs fixes that an average user may not know about.

About deb to sfs, I think it's not a good idea, because most .deb packages require dependencies, and people might think easily that creating an sfs from deb will just work, which is not in most cases.
Apt2sfs however does handle dependencies well (but not what you're looking for, i think).

Fred

Hi Fred,

Understood......I guess I was getting too enthusiastic, sorry for posting so much here. I just see much potential in this, as something that could approach the genuis of what Porteus used to do (as I've discussed before). Oh well, I've hit a brick wall these past two hours----I cannot get budgie to boot. The build script puts together a nice, ~176mg budgie-desktop ISO with the basic budgie core stuff there, but booting is stuck at the command prompt & for the life of me I cannot figure out why. There's no errors listed anywhere up to that point, and even when I get in and check /var/logs, nothing is there indicating a problem. Yet, stuck I am at the command prompt, lol. I got so frustrated, I did a new buld using lumina-desktop, and interestingly, the exact same thing happened. Oh well, it's no big deal....by far the openbox/lxde/flubox and xfce are the nicest builds, and they work. Lastly, plz consider what dancytron, jd7654 and myself are saying about how this script could be a build process somewhat like what Porteus used to be. Before Porteus lost its driving founder, and subsequently went all Slacko & removing the ability of people to simply customize right on their home page with a clickable-build-process, where you literally were watching & waiting a few minutes as your build choices were put together, they were on the track that you & your script are on right now. That's why this is so interesting to me, and why I've been so enthusiastic. So, ok, I'll shutup now and let you scripting geniuses hash stuff out, and I'll lurk in the background for when a new update (if it happens) comes to the buildscript. Then I'll jump back in and be a willing build tester for all. Thanks so much for all your hard work regarding this....first time in a few years, outside of Barry's interesting Easy Linux work, that I've actually been excited about the buildprocess. Woof-CE was grinding me down, the hassles--mostly all needless and pointless---had just become too much. General (not specific) build ustomization in today's age should be a fairly easily process, and your script is doing this.

[fredx181]

Thanks guys for the hints and tips.

The separate field for specific Desktop apps and log creation I will surely implement.
About the comparison with Porteus website, that were really choices for a ful pre-configured complete system
As I said earlier, the fields in the GUI are separated only to give a better overview of what the different kind of packages are for basically.

@belham
I say "Good to see your enthusiasm !"
And you say "So, ok, I'll shutup now"
No comprendo
If you share details about what happens when you try to run e.g. Budgie or whatever you tested it can be valuable and solutions can possibly be found.
That's what this thread should be for also IMHO !

EDIT: Stuck at the command prompt happend to me also when I did build with XFCE without slim (or any other login-manager e.g. lightdm) so a login manager can solve the problem for Budgie also.
(press F1 once or twice in Slim screen for selecting window-manager or DE)
The point may be that ~/.xsession is still in /root and has inside "exec openbox-session", so possibly conflicts with installed DE

Fred

[AndresC2]

Hello Fred!

thanks for your mklive-stretch-mod.

I'm not in linux, try later your script.

Is possible continue from previus downloaded build and not

start fresh? beacause, I have for example, jessie-build with debootstrap

so is not necesary download and build jessie again with debootstrap.

this is optional.
Do you want start fresh build Stretch.
Do you want continue install from previus downloaded Stretch.

by the way:

For lost internet connetion.

#sorry my bad code fix for me please.

apt-get update
[ $? -eq 0 ] && echo -e "\e[0;32mOK\033[0m" || echo -e "\e[0;31mFAILED\033[0m"
if [ $? -eq 0 ]|echo -e "\e[0;31mFAILED\033[0m"; then
read -p "Apt-get FAILED!,do you want try again? ? (Enter=yes) (Y/n)?" choice
case "$choice" in
y|Y|"")
fi

the same for apt-get upgrade and apt-get install, please.

Thanks Fred for all!
very cool project!

AndresC2.

[rcrsn51]

Here is PeasyScale updated to v2.0.

Update: The binary tool get-image-size has been added to the package. It is now used by other apps that have PeasyScale as a dependency.

Remove the fake .gz extension.

----------------

[anikin]

. . . some question about this:

proc:device is busy,
dev:device is busy

this happen when not umount binds correctly.

that is better umount binds inside of chroot or outside?

how stop proc:device is busy or
dev:device is busy, after of a bad umount binds?
in console show, try lsof 8 or fuser(1) something like that. . .

I've had so many "dead" mounts . . . I don't have them anymore.

Rule #1: Once you've finished the work in chroot and done the unmounting stuff, * close * all/any terminal windows - very important!

Rule #2: (this step isn't required, but I always do it just to be on the safe side) Drop out of x and do startx again. Go to the chroot directory and if, for some reason there are still any mounted directories, right-click and unmount them manually. Follow these simple steps and you will never have "dead" mounts again. As for unmounting from inside or outside, I just follow to the letter Will Haley's howto.

[peebee]

I've made my first altered config build - configs below - ....some comments and questions arise:

- would be nice if the configs could be external to the shell-script mklive-stretch.sh (e.g. like DISTRO_PKGS_SPECS in woof-ce)

- can I only include packages from the debian and StretchDog repositories? I'd like to have a local personal repository to pull packages in from (I think)

- how do I add some needed firmware to the build? (may do this using a squashfs in /live/modules rather than in the build....)

- how do I configure the desktop? I've deleted firefox from my build as I want to provide the browser as a squashfs in /live/modules, however the desktop and the panel still have redundant entries

- is the Debian kernel the only one available? what needs to be changed to use other kernels?

Sorry if a lot of questions - the script works fine - just trying to understand how I might use it.

Cheers & thanks
peebee

Code: Select all

export BASE_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 pciutils usbutils file rsync dosfstools"

export BASE_APPS_INSTALL="lxde openbox obconf menu gparted parted pv synaptic volumeicon-alsa alsa-utils ffmpeg mtpaint pm-utils xdotool wmctrl desktop-file-utils mime-support cryptsetup-bin squashfs-tools conky fakeroot xserver-xorg-input-evdev pfind"

export BASE_DOG_APPS_INSTALL="yad gtkdialog obshutdown pup-volume-monitor frisbee edit-sfs-pcmanfm filemnt-pcmanfm remaster-scripts quick-remaster apt2sfs sfsload fixdepinstall greybird-theme-dd-stretch makedebpackage flashplayerchoice"

[rufwoof]

- is the Debian kernel the only one available? what needs to be changed to use other kernels?

Hi peebee. It is useful to better understand the Debian model. Debian "Stable" reflects unchanging ... and not necessarily solid (especially after a new version of 'Stable' is released). In effect a big freeze where the choice of kernel + 50,000 other programs/libs etc. are selected as comprising the set, after which only changes to fix critical errors/security issues are applied to those programs/files.

Debian also have tight entry policies for permitting entrance of programs into their Stable MAIN repositories, as once in Debian maintain that software (fix critical bugs/security issues). You might say 'own' it ... except of course that its open source.

When you understand that you're more inclined to just stick with the core release i.e. Debian "Main" repository for that release. Debian however do cater for "Contrib" and "Non-free" repositories, where contrib contains programs that can have dependencies not inside Debian Main and non-free includes stuff with very little if any Debian control over that.

Personally I've opted to track Debian "OldStable", that a debian stable falls into after a new stable is released. For instance Jessie has recently entered oldstable as Stretch was released. For me running a older desktop PC (approx 9 years old), Jessie is well aligned to that and I can run everything using just Jessie Main repositories. Jessie has been through extensive testing and a further 2 years in general release ... so all 50,000 programs are pretty solid and work well with each other. Debian continue to provide patches for oldstable so lack of security updates isn't a issue. And even whilst a old kernel version ... you have to remember that Debian will have maintained that kernel such that it can be more a case of the kernel being nothing like what its version number suggests it is ... and can be quite 'modern'.

Basically, be mindful before just switching a 'old debian kernel' out for something 'newer'. If you drift from the core set of debian programs like that, debian call it a FrankenDebian and the debian users forum will tend to not support that as it induces instability that sooner or later could break.

Debian oldstable suits me and its unrivalled. For around 2 years I can use a extensive program set provided and maintained by a single provider, receiving updates, and where the collective set of 50,000 repository programs all work well with each other due to in effect having been 'tested' by millions for a couple of years (general release) . Then in 2 years time, I might upgrade to the next oldstable i.e. Stretch, once that has been out in general release for a couple of years and has been superseded by the next general release.

The downside of running oldstable is that oldstable might not work with newer hardware, however you can often pull back versions of programs from later releases that may very well work with newer hardware ... which they call 'backporting'. That could however induce instability as you're running a bit of a Frankendebian in doing that, however this is where Puppy like structure can fit in nicely ... as the backports could be stored as SFS's that can be easily unloaded to leave a core/main sfs (like puppy_xxx.sfs) of perhaps just debian jessie content.

[rcrsn51]

PeasyPort scans your network for open ports.

Your network consists of a variety of devices - computers, routers, LAN printers, NAS fileservers. "Normal" speed should work in general, but some devices like printers or wireless connections may need "Slow". If your network has only high-speed devices, try "Fast". Scanning Windows machines may require slower speeds.

The packages below contain the binary busybox-pscan. The dependency is arp-scan.

Update: The MAC function now scans over the selected IP range, not the entire subnet.

Remove the fake .gz extension.

-------------------------

[belham2]

@belham
I say "Good to see your enthusiasm !"
And you say "So, ok, I'll shutup now"
No comprendo

Fred

Hi Fred,

Wrong choice of words, shutup was not meant in the literal sense. All is good, you said nothing wrong. What I was trying to convey was for me to quiet my over-enthusiasm so the real brains here (you, Dancytron, jd, wiak and my Lord Commander Backi : ) can work on the hard stuff....like making the script better.

I am just a tester, my scripting skills are too simplistic to help, haha Was just giving myself a verbal reminder to quit pouring gasoline on the already burning fire, if that makes any sense.

I could never get budgie to boot. I'd get to the command line prompt (only thing, besides the normal stuff, I put in the script was "budgie-desktop", and apt pulled in ~380mb---gulp! ---building it). I had tried your slim trick, slim installed, but once trying to boot, the system keep throwing up that white screen that says "Oh no, something has went wrong. Please click here and REBOOT." Hit that darn message everytime no matter what I tried. I even did a build with NO desktop, just to get me to the command prompt, then tried to install "budgie-desktop" again straight from the command prompt like I do on all my Debian minimal builds. This time apt pulled in 410mb, and I thought, hmmmm, that's it, it will boot now as it must have missed something. But, alas, no, the exact same thing and exact same message happened again. So, in my opinion, it isn't worth trouble anyways. As things stand, openbox, fluxbox, LXDE and XFCE run circles around budgie---it was just a curious fascination on my part seeing if debian-stretch would build with budgie.


On a completely different note, I gotta tell you my family loves dogradio. My wife has it playing on her computer when she's working out, and my littlest one, I walked into her room yesterday, and she had it on her laptop playing tunes from stations she had set up and saved. She now calls you "Mr." Fred

[belham2]

Here is PeasyScale updated to v2.0.

Remove the fake .gz extension.

rcrsn51, thanks for the peasyscale .debs! I installed it in this XFCE build, it installed no problems and I was immediately resizing some images. Thanks again (also for the 64-bit version)

[fredx181]

@Andres, I have added your suggestions to my list of possible options
(it grows and grows )

There is a network connection check at the start, is your request because of suddenly connection drop out, or... ?

@peebee

- would be nice if the configs could be external to the shell-script mklive-stretch.sh (e.g. like DISTRO_PKGS_SPECS in woof-ce)

I assume you mean with configs the BASE_APPS_INSTALL="..." etc.. to have them better outside the script.
Yes, might be good, any suggestion how exactly to handle?

- can I only include packages from the debian and StretchDog repositories? I'd like to have a local personal repository to pull packages in from (I think)

At the moment, indeed only from Debian and Stretchdog, but you can always install a single deb doing:

Code: Select all

dpkg -i <deb-package>

EDIT: Above not at building time, I meant when you've booted the system

- how do I add some needed firmware to the build? (may do this using a squashfs in /live/modules rather than in the build....)

Maybe you don't use latest script, it has:

Code: Select all

export FIRMWARE="firmware-linux-free" 
##### Below a selection of firmware packages available (mostly for wireless) #####  
##### atmel-firmware firmware-realtek bluez-firmware firmware-atheros firmware-linux-free firmware-linux-nonfree firmware-netxen firmware-ti-connectivity firmware-b43legacy-installer firmware-iwlwifi firmware-ipw2x00 firmware-libertas firmware-intelwimax firmware-brcm80211 firmware-b43-installer firmware-qlogic firmware-bnx2 firmware-misc-nonfree firmware-bnx2x firmware-zd1211

To create a .squashfs module for firmware (or anything), apt2sfs can be used.

- how do I configure the desktop? I've deleted firefox from my build as I want to provide the browser as a squashfs in /live/modules, however the desktop and the panel still have redundant entries

Configuring the desktop is not possible from building point, if that's what you mean.
Some config files are copied by the script from github to the filesystem.
Better in next release I make the config for e.g. lxpanel more basic (no firefox launcher)

- is the Debian kernel the only one available? what needs to be changed to use other kernels?

Yes, at the moment only Debian kernel supported. Maybe later in time I might include choices, not sure, it will be very complicated to do becaues of the two boot methods, (porteus-boot and live-boot)

About gpicview, I don't see it in your list, anyway, for me it shows in menu in Accessories > "image viewer" after install

@belham
Ah,relief. Ok, thanks for explaning your point of view.
Just wanna say more, If scripting is not your thing, doesn't mean you can't have ideas or opinion.
______________________________
@ daughter of belham
Give your father a big HUG and enjoy the radio!
Mr. Fred
______________________________

Fred

[belham2]

Hi all,

I couldn't resist doing a fvwm-crystal with the buildscript, mainly because I've never used it before. Took ~19 mins to complete. FVWM-crystal is quite interesting, fast but with a bit of a learning curve, lol. Above all it is (imho) the most beautiful of all lightweight desktop environments I have seen. It is gorgeous, and the user ability of desktop theme & icon customization built into it puts most everything else to shame. Here's some pics (what I used in the buildscript is in the first pic's title---just takeout all the lx-related stuff when the buildscript pops up---my ISO build came in at 293mb; also know that fvwm-crystal will pull in pcmanfm, despite me wanting only spacefm, so be aware of that). Hope you enjoy the pics and happy building! [Edit: the last pic is what I assigned to the mtpaint icon, and when I click on it, that is what I see. You can add & prioritize anything you want, in your icon submenu, simply by bringing the .desktop file over to jvwm root's folder and assigning a number of importance to it]