Create Debian 9 (Stretch) minimal ISO similar to DebianDog

A home for all kinds of Puppy related projects
Post Reply
Message
Author
wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

#101 Post by wiak »

Hi Fred,

Just a simple request hopefully.

It would be relatively easy to arrange for a successful run of your build script inside any recent Puppy also if it were not for the apt-get required in this code section:

Code: Select all

echo -e "\e[0;36mUpdate the package lists...\033[0m"
apt-get update
echo -e "\e[0;36mInstall some required packages, e.g. debootstrap, squashfs-tools, etc...\033[0m"
apt-get install debootstrap wget xorriso isolinux xz-utils squashfs-tools -y --force-yes
[ $? -eq 0 ] && echo -e "\e[0;32mOK\033[0m" || echo -e "\e[0;31mFAILED\033[0m"
Prior to running your script in Puppy the Puppy user of the script would just need to pre-insure debootstrap, wget, xorriso, isolinuz, xz-utils and mksquashfs was present (much of that being the case already in recent Pups). And could maybe be arranged to not even need xorriso if just wanting the /live folder built, which is most useful bit really for grub4dos use.

I wonder if you could you kindly therefore arrange that this section of code is only run if a check for apt-get reveals its presence on the underlying system? So will be run in debian-based system and not in Puppy as required.

For example, this would do I think:

Code: Select all

if [ $(command -v apt-get 2>/dev/null) ];then
 echo -e "\e[0;36mUpdate the package lists...\033[0m"
 apt-get update
 echo -e "\e[0;36mInstall some required packages, e.g. debootstrap, squashfs-tools, etc...\033[0m"
 apt-get install debootstrap wget xorriso isolinux xz-utils squashfs-tools -y --force-yes
 [ $? -eq 0 ] && echo -e "\e[0;32mOK\033[0m" || echo -e "\e[0;31mFAILED\033[0m"
fi
Alternatively, the 'which' command could be used to check for apt-get being present (I've read 'command -v' is better though can't remember why...).

Better that than having to unnecessarily fork/modify the script for use in Puppy since hard to keep up with changes/developments if two versions. And would be lovely if a Puppy user could run your script without having to modify the script itself really.

cheers, wiak

EDIT: Note that the only problem I've had running debootstrap itself in Puppy is that some of them use LD_LIBRARY_PATH with /lib: as one of the entries and debootstrap program doesn't like that. The solution for such cases is to export LD_LIBRARY_PATH but with /lib: entry removed prior to running debootstrap or any script using it as I describe (badly) here:

http://www.murga-linux.com/puppy/viewto ... 323#963323

In all such Pups (doesn't effect Slacko64) the /lib: always seems to be at the very front of the LD_LIBRARY_PATH so would be nice if that could always be stripped out if present (using sed or bash var replacement tricks or whatever).

User avatar
fredx181
Posts: 4448
Joined: Wed 11 Dec 2013, 12:37
Location: holland

#102 Post by fredx181 »

Hi all,

Made some changes in mklive-stretch script (right-click > Save link as)

EDIT: One of the changes I added is (before actually apt-get install <list of packages> in chroot) do a simulation of the installing.
This checks if all is correct and if not: exit
rcrsn51 wrote:1. Some additional apps like pFind and pBurn are being installed, although they are not in the lists. How do I remove them?
Yes, fixed now, it was mistake I made by setting a wrong depencency in quick-remaster package, pburn won't be part of the build by default now.

Your wifi-firmware-stretchdog32 package had a problem installing (error)
Part of content is also in package linux-firmware-free, so added this to control file:

Code: Select all

Replaces: firmware-linux-free
Which means no more then: it's allowed to overwrite file(s) that also exist in other package.
Btw, it says "all" in control, but I assume it's for 32-bit only, right?
Now I'm curious. If this build system is NOT including firmware, then how are people getting their PCI network cards to work?
I thought the user could add to the list or when running the system install with Synaptic or apt.
Anyway, I added variable FIRMWARE to the user editable list on top, and a list to pick from (most firmware packages).

@wiak
if [ $(command -v apt-get 2>/dev/null) ];then
echo -e "\e[0;36mUpdate the package lists...\033[0m"
apt-get update
echo -e "\e[0;36mInstall some required packages, e.g. debootstrap, squashfs-tools, etc...\033[0m"
apt-get install debootstrap wget xorriso isolinux xz-utils squashfs-tools -y --force-yes
[ $? -eq 0 ] && echo -e "\e[0;32mOK\033[0m" || echo -e "\e[0;31mFAILED\033[0m"
fi
I changed to that, thanks!

@jd7654
As for the touchpad, I see that both evdev and libinput input drivers are in StretchDog, so I take it that the functionality will return once build is more complete?

Just curious: what would you say is the percentage of how close this script is to being the Dog equivalent of what WoofCE is to Puppy? In terms of being able to make a complete Debian Dog with all the bells and whistles. Roughly.
I have in StretchDog32 only xserver....evdev installed, not libinput, just the same as in the mklive-stretch build, so... don't know.

To be honest, I never used WoofCE, so can't compare.

@belham, you know more about WoofCE, is there something to learn from how it's setup, is it user-friendly, probably more advanced, e.g. choices ?

Fred
Last edited by fredx181 on Tue 08 Aug 2017, 12:34, edited 3 times in total.

zagreb999
Posts: 567
Joined: Fri 11 Apr 2014, 06:39
Location: Yugoslavija

ramsize=90%

#103 Post by zagreb999 »

thanks fred,
works great in xd and dd

but, is there any script
to change ramsize
in terminal???

regards.

User avatar
fredx181
Posts: 4448
Joined: Wed 11 Dec 2013, 12:37
Location: holland

#104 Post by fredx181 »

Hi zagreb,

Doesn't work for me on Xenialdog 32bit, on which XD you tested ?

At the end of the debootstrap build I get:

Code: Select all

W: Failure trying to run: chroot /mnt/sda5/stretch/chroot dpkg --force-depends --install /var/cache/apt/archives/dpkg_1.18.24_i386.deb
And apt-get is not found in chroot
but, is there any script
to change ramsize
in terminal???
Have to think about that, is it for when booting with porteus-boot style ?

Fred

User avatar
rcrsn51
Posts: 13096
Joined: Tue 05 Sep 2006, 13:50
Location: Stratford, Ontario

#105 Post by rcrsn51 »

Thanks Fred.

Now that you have added a FIRMWARE section to the build script, could you remove my wifi-firmware-stretchdog32.deb package from your repos?

It serves no purpose now that you can easily select the firmware you need at build-time.

My firmware package does contain one other firmware (8192du) found nowhere else, but I will decide how to deal with it later. Maybe a separate package for it.

Bill
Last edited by rcrsn51 on Tue 08 Aug 2017, 15:23, edited 1 time in total.

zagreb999
Posts: 567
Joined: Fri 11 Apr 2014, 06:39
Location: Yugoslavija

ramsize

#106 Post by zagreb999 »

hi fred
it is misunderstanding...

i do not use debootstrap

just i wish to test ramsize change in
regular xenialdog 32 bit and debiandog 32 bit
installed with unetbootin (xenialdog),
and dd installer (debiandog) on hard disk.

it works great.

but, i wish to know is there
any script to change ramsize
in regular iso's in terminal?

regards.

backi
Posts: 1922
Joined: Sun 27 Feb 2011, 22:00
Location: GERMANY

#107 Post by backi »

Hi everybody !

Tested new makelive-stretch script on Debian-Dog-Jessie .....works fine so far.
Put live folder on ext4 partition as a frugal install .
Grub4dos entry :

title Stretch-Dog from Script - porteus-boot - changes=/live/changes folder
find --set-root /live/vmlinuz1
kernel /live/vmlinuz1 from=/ noauto changes=EXIT:/live/
initrd /live/initrd1.xz

Just removed firefox-esr and did a "Quick Remaster".
Rebooted and posting now from it with Firefox-portable .

Very low on ram ....just 59 Mib Ram usage

Supercool!!! :D
Last edited by backi on Tue 08 Aug 2017, 15:59, edited 2 times in total.

zagreb999
Posts: 567
Joined: Fri 11 Apr 2014, 06:39
Location: Yugoslavija

ramsize

#108 Post by zagreb999 »

hi fred,
excuse me, i did not answered
to your question...

Quote:
but, is there any script
to change ramsize
in terminal???


Have to think about that, is it for when booting with porteus-boot style ?
------
yes,yes... porteus boot!!!

User avatar
rcrsn51
Posts: 13096
Joined: Tue 05 Sep 2006, 13:50
Location: Stratford, Ontario

#109 Post by rcrsn51 »

@Fred:

I ran a build with the new FIRMWARE selection and it works perfectly.

User avatar
peebee
Posts: 4370
Joined: Sun 21 Sep 2008, 12:31
Location: Worcestershire, UK
Contact:

#110 Post by peebee »

Hi Fred

Scenario = running latest version of mklive-stretch.sh from within wiak's debootstrapDebian within LxPupSc Puppy.....so a chroot has already been done....probably being too ambitious / hopeful.....

An error message about chroot flashes by but too quickly to capture....then finally get:

Code: Select all

...................
initrdport/porteus/
initrdport/etc/
initrdport/etc/mtab
initrdport/tmp/
initrdport/run/
Copy scripts, required for porteus-boot, to the chroot...
OK
Sorry, apt-get not found, cannot continue
Exiting . . .
Unmounting mount binds in chroot
Removed chroot
==========================
but apt-get is available in debootstrapDebian within Puppy:

root@puppypc17204:/usr/local/bin# which apt-get
/usr/bin/apt-get
root@puppypc17204:/usr/local/bin# 
ImageLxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64

belham2
Posts: 1715
Joined: Mon 15 Aug 2016, 22:47

#111 Post by belham2 »

fredx181 wrote:
To be honest, I never used WoofCE, so can't compare.

@belham, you know more about WoofCE, is there something to learn from how it's setup, is it user-friendly, probably more advanced, e.g. choices ?

Fred
Hi Fred & all,

I've done so many woof-CE builds that I can't even begin to guess at the number, but that makes so far from an expert with it that it isn't even funny. The real masters with woof-CE are Billtoo and Sailor....wish I could convince them to give your build script a go. Here is what I will say though:

1) Your build script, Fred, and how to set it up, is significantly farther ahead in terms of ease as compared to the woof-CE setup process. I use my wife (since she's willing) to give the woof-CE process a go, and she still can't make it all the way through with any of the generic builds offered---all because she gets stuck on the 8 steps it takes going from "git clone..." to "./builddistro-Z". I always have to step in and guide her despite her trying/attempting reading various threads & the woof-CE git page how to do it. But, Fred, I made her read this first page of this thread, and after once doing it, I walked away, and about 40 mins she called me upstairs beaming away at her newly created DebianDog32. I was quite the proud husband. And she hates computers...and still asks me every now & then why "root" and not as "user", and what's the difference again??.....lololol :lol:

2) But, that said, what woof-CE (and Barry's woof process) excels at is once you get those 8 steps down, the 1st four-five steps become easy:

1. git clone puppylinux-woof_CE into an empty EXT4-formatted 8GB or larger partition
2. cd woof-CE on your system to this directory
3. run "./merge2out" there
4. cd ../woof-out* (to get into the specific folder you need for building purposes)
5. run "./0setup" (here's where the general questions begin, like choose your build type (32 or 64 bit), choose which of the branch builds you want to do----for example, like Slacko, Ubuntu (xenial, tahr), etc, a one or two other simple, general things I'm forgetting right now

...but here, in my opinion, is where woof breaks down with steps 6 - 8 in terms of ease of use, and also allowing mods to the build process

6. run "./1download"
7. run "./2createpackages"
8. run "./3builddistro-Z"

Where the problems come in for woof-CE is in 6 - 8 above. You're presented with some questions & popups with choosing kernel, for example, choosing a few basic things that are specific to that build, but there is no real customization (like adding the desktop of your choice, adding a browser, adding an email client, etc). You've got to take what is brought with your choices in ./0setup. You can customize things, but adding pets and/or your own choices to the build, is honestly, way too complex for most people to even attempt this. I only learned through countless trial and error, and even then, I am banging my head against the wall struggling to understand why something did not get set up correctly or woof-process built an ISO without the specific changes I incorporated. Here is where your script, Fred, and this build process, can leapfrog woof-CE (to be fair, the woof-CE process is handling many different types of builds, so......)

But what can be done with your script arranging for dialog popups asking about browser choice, desktop choice, email client, etc, etc.....heck only our imagination limits us here is something within reach! And it would be easy as clicking the mouse. No constant fiddling and adding stuff to numerous folders and files, like in the woof-CE build process. In woof-CE's current build structure, I just don't see how (user customization) is ever going to happen, or how it would be attempted/set up. They want the build process generic, then you customize afterwards and run constant remasters. With woof-CE, jilst is already overwhelmed in his usually solo efforts at keeping woof-CE building on the rails so we can build from it without getting constant failures and/or problems.

Sum up, my opinion, is since this build script here focuses on one type of build (32-bit), with no real worry of kernel choices (something the woof process gives you numerous choices of), maybe try to focus on where it can excel at what I mentioned above. I know dancytron is worried, possibly rightly, about offering too many options, but honestly this is where this build script could shine, explode, and begin something that is addictive.

It is approaching what the porteus-home-build-page used to be, and that I discussed here in response to mavrothal's posts about what is happening to the puppy-universe:
http://www.murga-linux.com/puppy/viewtopic.php?t=111195

So, with all due respect to dancytron, I say we explode in this direction. My wife already asked me if this "Fred" person is going to let her choose a browser the next time I ask her to try the build script again. That's saying something, as she usually throws the woof-CE hatred-thing look me and asks me to get it off her desktop and out of her pup she sometimes uses (a custom Xenialpup build I did for her). But since she succeeded 1st try making a debdog32, she is kinda intrigued & hooked a bit :wink:

User avatar
Billtoo
Posts: 3720
Joined: Tue 07 Apr 2009, 13:47
Location: Ontario Canada

#112 Post by Billtoo »

belham2 wrote:
I've done so many woof-CE builds that I can't even begin to guess at the number, but that makes so far from an expert with it that it isn't even funny. The real masters with woof-CE are Billtoo and Sailor....wish I could convince them to give your build script a go. Here is what I will say though:
Hi,

I'm certainly no woof-CE master, you know more about woof-CE than I do,

As for Debian Stretch, I have several 64 bit Stretch installs that I
did with the net install cd, it's working well.

bill@office:~$ inxi -bw
System: Host: office Kernel: 4.9.0-3-amd64 x86_64 (64 bit) Desktop: Xfce 4.12.3
Distro: Debian GNU/Linux 9 (stretch)
Machine: Device: desktop Mobo: Acer model: Aspire X3950 BIOS: American Megatrends v: P01-A3 date: 05/05/2010
CPU: Dual core Intel Core i3 540 (-HT-MCP-) speed/max: 1200/3067 MHz
Graphics: Card: Intel Core Processor Integrated Graphics Controller
Display Server: X.Org 1.19.2 driver: N/A Resolution: 1920x1080@60.00hz, 1920x1080@60.00hz
GLX Renderer: Mesa DRI Intel Ironlake Desktop GLX Version: 2.1 Mesa 13.0.6
Network: Card: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller driver: r8169
Drives: HDD Total Size: 500.1GB (2.7% used)
Weather: Conditions: 73 F (23 C) - Partly Cloudy Time: August 8, 1:06 PM EDT
Info: Processes: 203 Uptime: 11 min Memory: 650.8/5898.7MB Client: Shell (bash) inxi: 2.3.5
bill@office:~$

I use slacko 14.2 (32 bit mostly) from woof-CE and it works well,

Bill
Attachments
screenshot.jpg
(53.51 KiB) Downloaded 522 times

jd7654
Posts: 296
Joined: Mon 06 Apr 2015, 16:10

#113 Post by jd7654 »

fredx181 wrote:@jd7654

I have in StretchDog32 only xserver....evdev installed, not libinput, just the same as in the mklive-stretch build, so... don't know.

To be honest, I never used WoofCE, so can't compare.
I was using StretchDog64 to run script, it says it has both evdev and libinput installed, maybe it only says that or I'm checking wrong:

Code: Select all

root@stretch64:~# uname -a
Linux stretch64 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u1 (2017-06-18) x86_64 GNU/Linux
root@stretch64:~# apt-cache search xserver-xorg-input
xserver-xorg-input-all - X.Org X server -- input driver metapackage
xserver-xorg-input-mouse - X.Org X server -- mouse input driver
xserver-xorg-input-evdev - X.Org X server -- evdev input driver
xserver-xorg-input-libinput - X.Org X server -- libinput input driver
xserver-xorg-input-synaptics - Synaptics TouchPad driver for X.Org server
root@stretch64:~# 
Anyway, I did try again and swapped xserver-xorg-input-evdev for xserver-xorg-input-libinput and then touchpad functionality was restored for both laptop touchpads.

As for WoofCE, wasn't really asking you to compare the two programs, they are different beasts. Just trying to get a feel for how close your script is to being able to create a complete DD or StretchDog with all the bells and whistles. It looks like it is getting close?

Only request I would have is make it less dependent on the machine it is run on and more target oriented. Like I'm running it here on a more beefy 64-bit machine with lots of space, but my target is an older 32-bit machine with no space or capability to run the script.

User avatar
fredx181
Posts: 4448
Joined: Wed 11 Dec 2013, 12:37
Location: holland

#114 Post by fredx181 »

Hi All,
rcrsn51 wrote:Now that you have added a FIRMWARE section to the build script, could you remove my wifi-firmware-stretchdog32.deb package from your repos?
Ok, done.

Just in case there's confusion about why the separate sections for installing e.g.BASE EXTRA FIRMWARE :
It's only to get better overview what sort of packages are installed.
In fact a firmware package can be added to the BASE_INSTALL or any other section also.

@zagreb
it is misunderstanding...
i do not use debootstrap
Ah, yes, misunderstood..
For increasing the size of tmpfs from default 60% to 90% in directory /mnt/live/memory/changes do:

Code: Select all

mount -t tmpfs -o "remount,size=90%" tmpfs /mnt/live/memory/changes
That works only if /mnt/live/memory/changes is tmpfs, check if true:
root@stretch:~# mount | grep tmpfs
tmpfs on /mnt/live type tmpfs (rw,relatime,mode=755)
none on /mnt/live/dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=217142,mode=755)
tmpfs on /mnt/live/memory/changes type tmpfs (rw,relatime,size=1853448k)


@peebee
Scenario = running latest version of mklive-stretch.sh from within wiak's debootstrapDebian within LxPupSc Puppy.....so a chroot has already been done....probably being too ambitious / hopeful.....
And on LxPupSc Puppy the debootstrap itself build well ? (with wiak's pet and advices ?)
Anyway, did you do the "remove /lib trick" from the $LD_LIBRARY_PATH just before running ./mklive-stretch ?
If not, that might explain why it didn't work. I had first the same result as you on X-tahr, but when I did the remove /lib trick it worked well.

@belham
Thanks very much for your detailed info, I'll try to digest and probably have some questions later about it.

Fred

User avatar
fredx181
Posts: 4448
Joined: Wed 11 Dec 2013, 12:37
Location: holland

#115 Post by fredx181 »

jd7654 wrote:As for WoofCE, wasn't really asking you to compare the two programs, they are different beasts. Just trying to get a feel for how close your script is to being able to create a complete DD or StretchDog with all the bells and whistles. It looks like it is getting close?

Only request I would have is make it less dependent on the machine it is run on and more target oriented. Like I'm running it here on a more beefy 64-bit machine with lots of space, but my target is an older 32-bit machine with no space or capability to run the script.
Ah, well, I really don't know yet, I'm not sure if the target should be a full featured DD.
I think flexibilty should be the goal, I experimented also now with a GUI version:
mklive-stretch GUI (right-click > Save link as)
Requires yad installed, probably not a too old version (like some puppies still have)
A bit more user-friendly if it goes about choice which packages to install, I guess.
Doesn't need to run from terminal, just click on the script (after making executable), the output will run in a Xterm window.

Fred
Attachments
mklive-stretchgui.png
mklive-stretch GUI
(183.37 KiB) Downloaded 491 times

dancytron
Posts: 1519
Joined: Wed 18 Jul 2012, 19:20

#116 Post by dancytron »

Maybe separate the applications that create the desktop and menu bar from the other base applications so it would be easier to create one with a different desktop setup. I assume that would be openbox, obconf, and some of the lx* applications.

Also, what would I need to add to get the "add user" wizard to work?

Great job!!!!!!!!

User avatar
fredx181
Posts: 4448
Joined: Wed 11 Dec 2013, 12:37
Location: holland

#117 Post by fredx181 »

dancytron wrote:Maybe separate the applications that create the desktop and menu bar from the other base applications so it would be easier to create one with a different desktop setup. I assume that would be openbox, obconf, and some of the lx* applications.

Also, what would I need to add to get the "add user" wizard to work?

Great job!!!!!!!!
Ok, I see what you mean.

If you mean the script to add a new user, it's in /usr/local/bin "addnewuser" There's also "addusertogroups"
Or, you mean what's required for it to make it work, I think yad only, not sure.
Didn't test these sort of apps yet.

Fred

dancytron
Posts: 1519
Joined: Wed 18 Jul 2012, 19:20

#118 Post by dancytron »

On adduser, I'm not sure. The *.desktop file in my stretch just says "exec=addnewuser."

Maybe it works and just the *.desktop file is missing. I am making another one right now (trying out lxqt) and will test it when it finishes.

Dan

wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

#119 Post by wiak »

fredx181 wrote: @peebee
Scenario = running latest version of mklive-stretch.sh from within wiak's debootstrapDebian within LxPupSc Puppy.....so a chroot has already been done....probably being too ambitious / hopeful.....
And on LxPupSc Puppy the debootstrap itself build well ? (with wiak's pet and advices ?)
Anyway, did you do the "remove /lib trick" from the $LD_LIBRARY_PATH just before running ./mklive-stretch ?
If not, that might explain why it didn't work. I had first the same result as you on X-tahr, but when I did the remove /lib trick it worked well.
Maybe, but I note the same error report when trying to run mklive-stretch from XenialDog32. I haven't tried any /lib trick there yet though.

wiak

User avatar
fredx181
Posts: 4448
Joined: Wed 11 Dec 2013, 12:37
Location: holland

#120 Post by fredx181 »

Dan,

Maybe there's misunderstanding.
The script addnewuser is not included in the mklive-stretch build (yet)
You can copy it from an existing DD to /usr/local/bin in the built system (while running it) and see if if works properly.

Post Reply