Create Debian 9 (Stretch) minimal ISO similar to DebianDog

[fredx181]

Hi Fred,

Well, I've spent the past few hours trying to get the build-script to build an xfce4 & xfce4-goodies debiandog, but each time the script failed to get through. I finally caught the error before it turns itself off in the middle of doing stuff. It had something to do with "libxklavier....". As soon as the script threw up the message that there is/was a "Fatal Error", this libxklavier..... flew by, and the script terminated itself very quickly. I am not sure how to work around this error in the original build script, so, for now, I cannot attempt an XFCE and/or Budgie desktop-environment build using the buildscript.

Anything that stays focused on openbox and lxde, you can build all you want and the script will get through to the end (and have made you a nice, bootable ISO or just use the files from it to set up a frugal install).

Hi Belham,

I didn't yet experiment with different desktop environments to build with, but about this I was curious (I like xfce )
Couldn't reproduce what you got (not a single error) but probably I did different than you.
Here's my setup (used the GUI):
# Base Apps
xfce4 menu leafpad gparted parted pv synaptic volumeicon-alsa alsa-utils firefox-esr=24.8.0esr-1~deb8u2 pm-utils xdotool wmctrl desktop-file-utils mime-support cryptsetup-bin squashfs-tools conky fakeroot xserver-xorg-input-evdev pfind

# Base Dog Apps
yad gtkdialog obshutdown pup-volume-monitor peasywifi edit-sfs-thunar filemnt-thunar remaster-scripts quick-remaster apt2sfs sfsload fixdepinstall greybird-theme-dd-stretch makedebpackage flashplayerchoice

It did boot fine, but didn't start xfce, so I installed slim login manager from console and ran it:

Code: Select all

apt-get update
apt-get install slim
slim

There came a warning message, but the slim screen showed, then I pressed F1 (for selecting DE), showed "xfce-session" typed my password and voila... xfce4

EDIT: The warning message about (login....) disappeared for me when I renamed ~/.xsession to ~/.xsession.bak (after reboot wasn't there anymore)

I then installed also xfce goodies without problems.

There are some problems, e.g. (using save on EXIT) Save or NoSave doesn't appear when shutdown from xfce (and save from console doesn't work in every case), but about that later maybe

Would be good to share your setup (also your successful lxde setup), what needed to be done afterwards etc.
Btw, in general it would be nice if people share in detail different experiments.
I think I will implement in the script a sort of log creation so that it's easy to look afterwards what has been the setup of packages installed.

fred

[rcrsn51]

Here is SaveFolderBackup for archiving your Changes folder. But it is also a general-purpose backup/restore system. Read here.

It auto-installs lzop compression as a dependency.

[dancytron]

As suggested, I pasted the addnewuser script from my Stretch64 into a new DD created with the latest non-gui script. I didn't change much from the stock script that created the distribution, nothing that should matter.

When I ran "addtouser" from the terminal, to add user "puppy" I got this.

Code: Select all

root@live:/usr/local/bin# ./addnewuser
Adding user `puppy' ...
Adding new group `puppy' (1000) ...
Adding new user `puppy' (1000) with group `puppy' ...
The home directory `/home/puppy' already exists.  Not copying from `/etc/skel'.
adduser: Warning: The home directory `/home/puppy' does not belong to the user you are currently creating.
usermod: group 'scanner' does not exist
usermod: group 'lpadmin' does not exist
usermod: group 'wheel' does not exist
usermod: group 'bluetooth' does not exist
usermod: group 'fuse' does not exist 

I exited X and did "login puppy", which worked, except that the xserver would not start. I have attached xorg log.

To see if it was just the name "puppy" that was the problem, I tried user "cat." It was a little different.

Code: Select all

root@live:/usr/local/bin# ./addnewuser
Adding user `cat' ...
Adding new group `cat' (1001) ...
Adding new user `cat' (1001) with group `cat' ...
Creating home directory `/home/cat' ...
Copying files from `/etc/skel' ...
usermod: group 'scanner' does not exist
usermod: group 'lpadmin' does not exist
usermod: group 'wheel' does not exist
usermod: group 'bluetooth' does not exist
usermod: group 'fuse' does not exist
root@live:/usr/local/bin# 

I exited X, Did "login cat". Pretty much the same as puppy. I attached that xorg log as well.

Let me know if there is any followup you'd like me to do.

Dan

[belham2]

Hi Fred,

Well, I've spent the past few hours trying to get the build-script to build an xfce4 & xfce4-goodies debiandog, but each time the script failed to get through. I finally caught the error before it turns itself off in the middle of doing stuff. It had something to do with "libxklavier....". As soon as the script threw up the message that there is/was a "Fatal Error", this libxklavier..... flew by, and the script terminated itself very quickly. I am not sure how to work around this error in the original build script, so, for now, I cannot attempt an XFCE and/or Budgie desktop-environment build using the buildscript.

Anything that stays focused on openbox and lxde, you can build all you want and the script will get through to the end (and have made you a nice, bootable ISO or just use the files from it to set up a frugal install).

Hi Belham,

I didn't yet experiment with different desktop environments to build with, but about this I was curious (I like xfce )
Couldn't reproduce what you got (not a single error) but probably I did different than you.
Here's my setup (used the GUI):
# Base Apps
xfce4 menu leafpad gparted parted pv synaptic volumeicon-alsa alsa-utils firefox-esr=24.8.0esr-1~deb8u2 pm-utils xdotool wmctrl desktop-file-utils mime-support cryptsetup-bin squashfs-tools conky fakeroot xserver-xorg-input-evdev pfind

# Base Dog Apps
yad gtkdialog obshutdown pup-volume-monitor peasywifi edit-sfs-thunar filemnt-thunar remaster-scripts quick-remaster apt2sfs sfsload fixdepinstall greybird-theme-dd-stretch makedebpackage flashplayerchoice

It did boot fine, but didn't start xfce, so I installed slim login manager from console and ran it:

Code: Select all

apt-get update
apt-get install slim
slim

There came a warning message, but the slim screen showed, then I pressed F1 (for selecting DE), showed "xfce-session" typed my password and voila... xfce4

EDIT: The warning message about (login....) disappeared for me when I renamed ~/.xsession to ~/.xsession.bak (after reboot wasn't there anymore)

I then installed also xfce goodies without problems.

There are some problems, e.g. (using save on EXIT) Save or NoSave doesn't appear when shutdown from xfce (and save from console doesn't work in every case), but about that later maybe

Would be good to share your setup (also your successful lxde setup), what needed to be done afterwards etc.
Btw, in general it would be nice if people share in detail different experiments.
I think I will implement in the script a sort of log creation so that it's easy to look afterwards what has been the setup of packages installed.

fred

Hi Fred,

Hmmm, looking at what you used, I think I definitely caused the problem by me specifying too much to be included into the buildscript. I've got to start trusting the buildscript more and let it pull ALL the dependencies in instead of me overdoing it and specifying too much stuff, haha. Going to try again here, see what happens. Thanks!

[dancytron]

Built another one. I attempted to add all the DD specific programs and test a few.

/snip

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?

/snip

I just built one with the new script. This issue appears to be fixed.

Well, sorry to report that my latest build is doing this again.

I didn't save the old build or my notes, so I don't know if there was any difference.

Dan

[fredx181]

Hi Dan,

Now you mention about X not starting I remember the same problem when making StretchDog.
It has to do with the "startx" method (logging in through a login manager is OK)
If I remember well the fix was to install xserver-xorg-legacy

Code: Select all

apt-get install xserver-xorg-legacy

Content of /etc/X11/Xwrapper.config should be:

Code: Select all

needs_root_rights=yes
allowed_users=anybody

And do in terminal:

Code: Select all

dpkg-reconfigure xserver-xorg-legacy

Reboot required maybe?

Also you need to copy some folders, e.g. /root/.config and the .xsession files to home/puppy
If you do that as root you need to give ownership to puppy, from terminal in /home :
chown -R puppy:puppy puppy

One of the first things I will work on is multiuser support, e.g. /etc/skel folder contain more so the manual copying isn't needed, but not sure yet what or how, this way of preparing is all new for me, making a DebianDog was easier !

Could be that adding new user e.g "cat" is more successful (since creating user puppy has failed already)

EDIT:

.....
Well, sorry to report that my latest build is doing this again.

okay, thanks, will have a look (thought also it was ok, but will test again)

Fred

[fredx181]

For Broadcom wireless users who need the vendor wl driver, I have built 32bit and 64bit packages.

The post-install scripts should blacklist the b43 and ssb drivers.

Thanks! Good to have. Is not in the official Debian repository AFAIK (people need to compile themselves), will add to dog repos soon.

@belham

Hmmm, looking at what you used, I think I definitely caused the problem by me specifying too much to be included into the buildscript.

Yes, could be, e.g. installing just xfce4 does install most (thunar, xfce-terminal etc..) btw, it's apt-get that does that, not a specific thing the build script does.

@rcrsn51
Re: Pet2Stretch
I'll wait a while with adding this to the repos, as you mentioned it should be tested and depending on feedback.

@peebee

Success - thanks to wiak....
wiak clarified that apt-get was not needed for mklive-stretch....

Fresh frugal install of LxPupSc
Made internet connection
Installed debootstrap_1.0.89.pet
Copied mklive-stretch.sh to /usr/bin
Opened a terminal and typed:
Code:
export LD_LIBRARY_PATH= && mklive-stretch.sh
Frugally installed the resulting /stretch/isodata/live successfully.....yippee

Nice! Don't really think so but just asking:
Was it required to place the script in /usr/bin first ?
I mean, would this also have worked from terminal in the directory where mklive-stretch is located:

Code: Select all

export LD_LIBRARY_PATH= && ./mklive-stretch.sh

@jd7654

GUI frontend is great choice. Just add a tick box for 32-bit or 64-bit, and maybe preload those three dialogs for language, root passwd and compression. I know...probably easier said than done, so just a dumb user request. Wink

From what wiak and I tested setting up debootstrap for a 64-bit build from 32-bit OS host is not possible.
But the other way around does work, so I'll see what I can do to implement building 32bit from 64bit host.
Some preloading might be possible, but seems to me not for the keyboard layout setup, I might be wrong though.

Fred

[wiak]

Nice! Don't really think so but just asking:
Was it required to place the script in /usr/bin first ?
I mean, would this also have worked from terminal in the directory where mklive-stretch is located:

Code: Select all

export LD_LIBRARY_PATH= && ./mklive-stretch.sh

Yes, that should also work.

wiak

[jd7654]

@jd7654

From what wiak and I tested setting up debootstrap for a 64-bit build from 32-bit OS host is not possible.
But the other way around does work, so I'll see what I can do to implement building 32bit from 64bit host.
Some preloading might be possible, but seems to me not for the keyboard layout setup, I might be wrong though.

Fred

That would be great! I would think the builder would be on a more powerful machine and 64-bit host, so having option for target 32-bit low end machine is sufficient. For dialog, would be nice to just click and walk away and come back to completed ISO. But any reduction is great, if just 1 dialog for keyboard, and other two can have entry box to preload. As was mentioned before, thats many fewer steps than woof.

[fredx181]

@jd7654

From what wiak and I tested setting up debootstrap for a 64-bit build from 32-bit OS host is not possible.
But the other way around does work, so I'll see what I can do to implement building 32bit from 64bit host.
Some preloading might be possible, but seems to me not for the keyboard layout setup, I might be wrong though.

Fred

That would be great! I would think the builder would be on a more powerful machine and 64-bit host, so having option for target 32-bit low end machine is sufficient. For dialog, would be nice to just click and walk away and come back to completed ISO. But any reduction is great, if just 1 dialog for keyboard, and other two can have entry box to preload. As was mentioned before, thats many fewer steps than woof.

May take some time until I make changes.
For if you'd like to try now to make a 32bit build on 64bit host, you can edit the script by adding on line 67: export ARCH="i386" , so becomes this:

Code: Select all

echo -e "\e[0;32mBuilding will be done in: $PWD/stretch\033[0m"
read -sp "Press ENTER to continue . . . "
echo
echo
export ARCH="i386" # this is a hack :)

Then the message still shows "building live system for 64-bit" but it will create 32bit build
Don't forget to remove on line 67 if you want to make 64bit build later.

In the GUI script it's line 75

I tested this hack and works!

Fred

[wiak]

It is sometimes useful to generate a logfile of the whole mklive-stretch run as well as watching progress in a terminal. The following command should do that I think:

Code: Select all

mklive-stretch 2>&1 | tee mklive-stretch.log

Might be nice to also have log as a gui checkbox option (harder to arrange though).

I do similar when running debootstrap on its own because the self-generated chroot/debootstrap/debootstrap.log only gets written when there are errors.

wiak

[jd7654]

For if you'd like to try now to make a 32bit build on 64bit host, you can edit the script by adding on line 67: export ARCH="i386" , so becomes this:

Code: Select all

echo -e "\e[0;32mBuilding will be done in: $PWD/stretch\033[0m"
read -sp "Press ENTER to continue . . . "
echo
echo
export ARCH="i386" # this is a hack :)

Then the message still shows "building live system for 64-bit" but it will create 32bit build
Don't forget to remove on line 67 if you want to make 64bit build later.

In the GUI script it's line 75

I tested this hack and works!

Excellent! Worked perfect from StretchDog64 creating i386 DebLive-Stretch.

Hmmm...that revealed a small issue I was chasing down:

I was mostly building 64-bit builds, and for some reason the resulting fonts were all ginormous, for desktop, logout dialog, conky, xterm, etc. Some off the screen or beyond the window.
It can be fixed, but I remember it being small/normal once before without me having to do any changes, and not sure if it was something with build.

Anyway, using same distro and same script except with ARCH specified for i386, the resulting fonts are normal. So is there something different for the 64-bit build that has the extra large font issue?


EDIT: Scratch that, ran again and commented out ARCH change, and fonts are normal again. So back to the drawing board, not sure what causes extra large fonts in 64-bit build sometimes.

[wiak]

Hi Fred (and Peebee),

Just want to tidy up a loose-end. Though best to run mklive-stretch directly in Puppy, if using that system, it would be good to know that mklive-stretch would also work from inside a debootstrap Debian chroot system as Peebee tried but failed.

Anyway, solution was simple - nothing wrong with the idea itself, problem is simply that debian stretch variant=minbase peebee used doesn't contain cpio program, which is a dependency of mklive-stretch. Simple fix if you don't mind is to include cpio here (I added cpio in here):

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 cpio -y --force-yes
 [ $? -eq 0 ] && echo -e "\e[0;32mOK\033[0m" || echo -e "\e[0;31mFAILED\033[0m"
fi

Alternatively in any debootstrap build you can --include=programs_separated_by_commas.

All works running mklive-stretch inside a chroot debian system once cpio is installed on that debian. Even the iso is correctly produced since above code installed xorriso.

Small Discovery perhaps of interest:

I created my debootstrapDebian system as an i386 (32bit) system even though I did so on XenialDog64 (64bit system). No particular reason, but interesting result discovered:

I then copied mklive-stretch into my chroot/usr/sbin folder and after chroot chroot command ran from chroot dir /:

Code: Select all

mklive-stretch 2>&1 | tee mklive-stretch.log

What I forgot about is that mklive-stretch detects the underlying kernel system is 64-bit so proceeds to build the new Debian Stretch as a 64-bit system (even though the debootstrapDebian I was running it in was 32-bit).

The accidental discovery is that the build in this case (a 64-bit target from a "32-bit" host) works because the kernel being used remains the 64-bit one of the real host XenialDog64 system. So the underlying kernel is the key, not the libs and so on. I note that Peebee has recently built a 32-bit LxPupSc system but with a 64-bit kernel driving that, so in that case that system would also be able to build i386 or amd64 mklive-stretch systems.

(Of course, the machine itself must be capable of running a 64-bit kernel)

wiak

[AndresC2]

Hello Fred!

from Wheezy run script in /root this happen:

/bin/bash: chroot_in:command not found

thanks.

[wiak]

Hello Fred!

from Wheezy run script in /root this happen:

/bin/bash: chroot_in:command not found

thanks.

EDIT: @AndresC2:

Just realised I had already used mklive-stretch in a debian (stretch) distribution that used dash as its default shell; there was no problem with function chroot_in. Let us know if you get that solved please.

I am wondering what your underlying system default shell is. Is it dash rather than bash. Maybe if you have dash as main shell, somehow the command in mklive-stretch: chroot chroot /bin/bash -c chroot_in loses the bash-required export function facility (export -f chroot_in). Not sure why that should be since the script itself starts with #!/bin/bash, but that's all I can think of. There are certainly such issues in bash/gtkdialog type scripts used in Puppy Linux because internally gtkdialog makes system shell commands so if system shell not bash then doesn't work as expected.

wiak

[AndresC2]

Hello wiak!

my scripts have #!/bin/bash and run fine, how to know my default shell?

i split the script and first part run fine but second part that begin with:

chroot_in () {

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

my another option willhaley.com/blog/create-a-custom-debian-live-environment/

work fine.

thanks.

[wiak]

Hello wiak!

my scripts have #!/bin/bash and run fine, how to know my default shell?

To check your default shell, in a terminal type command:

Code: Select all

echo $0

On second thoughts, maybe terminal used will muck that up, so alternative (better maybe) check would be:

Code: Select all

ls -al /bin/sh

That will show what /bin/sh is symbolically linking to (either bash or dash).

If result is not bash, you could temporarily try changing underlying system shell to bash and then running mklive-stretch from the beginning, to see if that fixes the error you've been getting. To change shell to bash in debian use command (need to be root user to do this):

Code: Select all

dpkg-reconfigure dash

or

sudo dpkg-reconfigure dash

and follow the instructions that appear.

If you later want to change default shell back to bash, again use:

Code: Select all

dpkg-reconfigure dash

wiak

[wiak]

May well be nothing to do with dash or bash as system shell admittedly.

What do you mean you split the script by the way?

The code:

Code: Select all

export -f chroot_in

is what exports the function to the bash environment but that export will probably be gone once script exits so you have to be careful the function is still exported if you are somehow modifying things to run the script in two parts.

wiak

[AndresC2]

thanks wiak!

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.

thanks.

Andresc2

[wiak]

Not sure about the umounting; my natural reaction is to exit the chroot and do the umounting outside.

But you didn't say if you resolved the export -f chroot_in problem you were having?

wiak

EDIT: Though I don't really understand your question, maybe this link will help you:

https://unix.stackexchange.com/question ... bind-mount