Create Debian 9 (Stretch) minimal ISO similar to DebianDog

[fredx181]

Hi Dan,

You didn't solve the save2flash mystery yet ?

@all
Can anyone confirm please? output of:

Code: Select all

ls -l /usr/bin/save2flash

From running the live build, or from terminal in the chroot folder:

Code: Select all

ls -l usr/bin/save2flash

It is for me (and should be):

Code: Select all

-rwxr-xr-x 1 root root 3597 Jun 28 19:34 /usr/bin/save2flash

Thanks,

Fred

[fredx181]

If left idle for a period, the screen turns dark grey and there is no way to reactivate the system - a hard switch off and reboot is the only way out of jail. Suggestions at what needs to be added to enable resume from sleep please?

You mean when running the built live system?
I cannot reproduce that, when the screen goes black after 10 minutes, I touch the mouse and the screen lights up again

Yes - running the built live system.....on my desktop with nvidia graphics....
My mouse is usb wireless so maybe something is missing from the Debian kernel to support that in sleep mode?
But I have a ps2 keyboard plugged in as well as the usb wireless one and pressing keys on that also does not wakeup the system.....
Can I lengthen the timeout period??
Thanks

Sorry, no idea, maybe needs another xserver-xorg-video-* or xserver-xorg-input-* package installed.
To search you can do:

Code: Select all

apt-get update # if required
apt-cache search xserver-xorg-video

Or:

Code: Select all

apt-cache search xserver-xorg-input

Maybe someone else has other ideas.

Fred

[dancytron]

Hi Dan,

You didn't solve the save2flash mystery yet ?

/snip

Fred

I ran one last night with the new script. To change things up, I did it from Debian Dog Jessie 64. The save2flash and snapmergepuppy were the correct June version. I'll try one later from the DD Stretch 64 I was using before to see what happens.

I tested the create new user to create a user puppy without sudo. It worked fine. Also tested including Chrome and gksu and my little scripts worked fine.

[jd7654]

If left idle for a period, the screen turns dark grey and there is no way to reactivate the system - a hard switch off and reboot is the only way out of jail.

I noticed a sleep issue too, but have not dug in to troubleshoot yet,

One laptop with AMD chipset works fine. The other with Intel chipset hangs hard when wakes up from sleep.

EDIT: That same laptop works fine in DD64 being put to sleep and waking back up.

[jd7654]

@all
Can anyone confirm please? output of:

Code: Select all

ls -l /usr/bin/save2flash

From running the live build, or from terminal in the chroot folder:

Code: Select all

ls -l usr/bin/save2flash

It is for me (and should be):

Code: Select all

-rwxr-xr-x 1 root root 3597 Jun 28 19:34 /usr/bin/save2flash

From my DebLive64:

Code: Select all

root@live:/usr/bin# ls -l save2* snap*
-rwxr-xr-x 1 root root 3597 Jun 28 19:34 save2flash
-rwxr-xr-x 1 root root 7183 Jun 30 11:15 snapmergepuppy

[dancytron]

btw - it is running much faster now that you changed the repositories to automatically choose the best mirror. Thanks for that.

Dan

[fredx181]

Comparing Stretchdog and Stretch-live build for xserver-xorg-input-* and xserver-xorg-video-*

Installed in Stretchdog (32):
xserver-xorg-input-evdev
xserver-xorg-input-mouse
xserver-xorg-input-synaptics
xserver-xorg-legacy
xserver-xorg-video-ati
xserver-xorg-video-cirrus
xserver-xorg-video-fbdev
xserver-xorg-video-intel
xserver-xorg-video-mach64
xserver-xorg-video-mga
xserver-xorg-video-neomagic
xserver-xorg-video-nouveau
xserver-xorg-video-openchrome
xserver-xorg-video-r128
xserver-xorg-video-radeon
xserver-xorg-video-savage
xserver-xorg-video-sisusb
xserver-xorg-video-tdfx
xserver-xorg-video-trident
xserver-xorg-video-vesa

Installed in Live build:
xserver-xorg-input-evdev
xserver-xorg-input-synaptics
xserver-xorg-legacy
xserver-xorg-video-amdgpu
xserver-xorg-video-ati
xserver-xorg-video-fbdev
xserver-xorg-video-nouveau
xserver-xorg-video-radeon
xserver-xorg-video-vesa

To install what's missing in Live build (compared to Stretchdog) (takes 7MB space uncompressed):

Code: Select all

apt-get install xserver-xorg-input-mouse xserver-xorg-video-cirrus xserver-xorg-video-intel xserver-xorg-video-mach64 xserver-xorg-video-mga xserver-xorg-video-neomagic xserver-xorg-video-openchrome xserver-xorg-video-r128 xserver-xorg-video-savage xserver-xorg-video-sisusb xserver-xorg-video-tdfx xserver-xorg-video-trident

Stretchdog is built from a full netinstall, that could explain the difference.

Fred

[jd7654]

I noticed a sleep issue too, but have not dug in to troubleshoot yet,

One laptop with AMD chipset works fine. The other with Intel chipset hangs hard when wakes up from sleep.

EDIT: That same laptop works fine in DD64 being put to sleep and waking back up.

Update: Just did a quick test from a live USB on a few Dogs.
On this Intel laptop which failed suspend/resume: (echo mem > /sys/power/state)
DebLive-Stretch64
StretchDog64
StretchDog32
DebianDog-Stretch

DebianDog64-Jessie had no problem, and did suspend/resume OK.

So maybe an issue just with Stretch itself, not necessarily DebLive-Stretch.

But also Puppy Stretch 7.0.0a1 worked fine with suspend/resume. But that is kernel 4.1.38, so maybe a newer Debian kernel issue.

Also working OK with suspend on this laptop is newest kernels 4.11 in Quirky 8.3 and 4.12 in Arch, and just about other Linux and Puppies for that matter.

[dancytron]

I almost didn't post this and thought I'd just say, "Never mind, it's fixed,", but here it goes.

The version of Stretch 64 I've been using is the one that I remastered from the one that Ruwoof and Fred created so long ago. It has the old versions of save2flash and snapmerge puppy in it. It is somehow defective and the cause of this issue.

The following are the results of my several attempts to run this down.

1. Create with my Jessie 64. - new files
2. Created with my Stretch 64 save on exit - old files
3. Boot with my Stretch with no changes. Paste new save2flash and snapmergepuppy into it. Run script. Old files!!!
4. Boot my Stretch 64 save on exit. Paste updated save2flash and snapmergepuppy into it. Save2flash. Run script. Old files!!!!
5. Copy my stretch 64, paste in new files, remaster it. Check files updated. run script. New files!!!

I don't know what to make of this and I am not sure it is worth pursuing anymore. I am perfectly willing to just delete all my versions of Stretch 64, install Trinity Dog, and pretend this never happened.

Anyway, it is obviously pulling the old save2flash and snapmerge puppy from my Stretch 64 somehow. How or why makes no sense to me.

Dan

[jd7654]

I agree with both, so that made me decide to make new version
Removed checkbox 'Use xz compression' and dialog for keyboard layout should show again now
(depending on what you install, there could be other programs dialogs also , how it was, it suppressed all dialogs, which isn't right)
(the choice for xz or gzip comes at the end now, just after "Make any changes to chroot and then Press ENTER to continue")

EDIT: And added 'xserver-xorg-input-synaptics' to the Base install field

Tried the new gui script, build looks good here. Thanks for adding synaptics in default. That brings me back to the issue:

I noticed you put the synaptics in the Base section. I usually put it after the evdev in the Base Applications section. But these sections are just for visual organizational/educational anyway because ultimately they are all combined into one apt-get line, correct? (even though two different repos: Debian and Dog)

So referring back my my previous post about the Porteus sections based on Base, Xorg, Desktop, Apps, etc. Instead of the current default package groupings:

Code: Select all

Base Install:
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 xserver-xorg-input-synaptics

Base Applications Install:
leafpad gparted parted pv synaptic volumeicon-alsa alsa-utils viewnior firefox-esr pm-utils xdotool wmctrl desktop-file-utils mime-support cryptsetup-bin squashfs-tools fakeroot xserver-xorg-input-evdev pfind conky

Desktop Apps:
openbox obconf pcmanfm lxpanel lxrandr lxinput lxappearance

Might instead group them more like this:

Code: Select all

Base Install:
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 volumeicon-alsa alsa-utils pm-utils xdotool wmctrl desktop-file-utils mime-support cryptsetup-bin squashfs-tools fakeroot xserver-xorg-input-evdev xserver-xorg-input-synaptics

Base Applications Install:
gparted parted pv synaptic viewnior firefox-esr pfind conky

Desktop Environment Install:
openbox obconf pcmanfm lxpanel lxrandr lxinput lxappearance leafpad

Anyway, this is just minor stylistic changes, not functional as far as I can tell. Just an example, I might have a few in the wrong place, and an xorg section could also be broken out. Dog apps kept separate makes sense.

[wiak]

- 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)

But editing the script itself is kind of crude and improper. Better to use a separate config file. In fact, I would guess Fred is already heading that way with the build_setup.txt config file? Future script could take input fromt the output, like
./mklive-stretchgui -i build_setup.txt
And then that would suppress the Yad dialog. Then everyone will be happy!

Yes, and I guess most people don't want to mess with editing a script
Probably something like config file indeed will be best in the future, sort of a template file that can be edited and sourced in the script. Not sure how yet, checking if there exist config already, if not, download standard config.
Or make it a package (script + standard config)

Exactly, as I suggested earlier (10Aug):

One way is to use a plugin type system, that gets sourced by the main script after check for existence, as I noted used often inside the bash/gtkdialog program wex:

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).

The disadvantage of above (source into main script, method) is that the plug-in remains a tiny piece of valid shell code. A simpler less general-purpose alternative, which is similar to what I use in my own personal more modularised commandline version of the mklive-stretch build script, is to pull in a simple chunk of text config file, when required, via what is basically a cat statement:

Code: Select all

#!/bin/bash

# fredx181 2017-07-31, 'MakeLive' for Stretch (Debian 9), creates a minimal live system
# with aufs support and porteus-boot style included
# 2017-08-05, fixed support for Jessie host (previously worked only from Stretch)
# and removed install of linux-headers and aufs-dkms (build time gets shorter)
# instead copy aufs.ko for kernel 4.9.3 to /lib/modules/<kernel_version>/kernel/fs/aufs
# and execute "depmod <kernel_version>" and create new initrd.img-<kernel_version> in /boot
# 2017-08-14 GUI version using yad, but should be run from terminal
# wiak 2017-08-12, using external config file for the applications to install

# set to yes if you want to keep the locale files in /usr/share/locale
export KEEP_LOCALES="no"

# Set the standard 
# wiak, cat in from text config files method:
#   can put an: "if [ -s "${HOME}/.mklive_stretch/xxxxxxx.conf" ];then " check for config file existence around each of the following if you want more robust:

BASE="$(<${HOME}/.mklive_stretch/base.conf)" # cat(s) the conf file into variable BASE (wiak)
APPS="$(<${HOME}/.mklive_stretch/apps.conf)" # same like APPS="`cat ${HOME}/.mklive_stretch/apps.conf`"
DESKAPPS="$(<${HOME}/.mklive_stretch/deskapps.conf)"
DOG_APPS="$(<${HOME}/.mklive_stretch/dog_apps.conf)"
FIRMWARE="$(<${HOME}/.mklive_stretch/firmware.conf)"
EXTRA_DOG_APPS="$(<${HOME}/.mklive_stretch/extra_dog_apps.conf)"

where, for example, base.conf is a simple text file containing: 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 xserver-xorg-input-synaptics

and similarly for apps.conf, deskapps.conf, dog_apps.conf, firmware.conf and extra_dog_apps.conf

Personally, I'd also have the GUI (yad or whatever) as a commandline selected option such that the same script could be used from the commandline only if wished. But none of this is a big deal, anyone who can bash script can modify to their own wishes - main thing is that your script gives the recipe how to build these DebianDogs without having the rest of us having to do a lot of own research into howto DebianLive systems or debootstrap for that matter!

wiak

[dancytron]

Just my opinion and whatever Fred wants is fine, but all those config files just seem like a lot of unnecessary complexity to keep track of to me.

I've got 5 or 6 versions of the mklive-gui script I've put different packages into as I've tried things and modified them. It is easy to track them by renaming them mklive-gui-v1, makelive-gui-v2, makelive-gui-v3small, etc. Multiply that by 4 or 5 times to track little text files with lists of packages in them would make that a lot harder to keep organized.

[jd7654]

Just my opinion and whatever Fred want is fine, but all those config files just seem like a lot of unnecessary complexity to keep track of to me.

I agree, one config file is fine, its not that big. Woofce has that one big messy package file. This small sectional package lists works for me.

I prefer maximum flexibility, while keeping it simple. And yeah, this is all icing on the cake as I said before.

Leave the defaults in the script, which populates the gui, and then maybe add the option of feeding the config output to the input so people can pass their recipes around. Done.

As Fred said before, he's not intending this to be a complete Dog builder with all the bells and whistles, like Woofce is a complete Puppy builder. And I can think of many reasons that you may not want to have it be a Dog builder. It's more like a Debian Dog-like construction set, which may be able to create something like a Dog, but that is not the goal.

[dancytron]

Personally, I don't even really see the need for a config file (or the gui for that matter).

I prefer to list the packages inside the script, make comments with notes about what I've added or removed and why, give that version of the script a name to keep track of what it is (e.g. mklive-gui-v5chrome), and then run it.

But, whatever Fred wants. . .

[wiak]

Yes, I agree that adding config files increases complexity in the sense of there being more separate parts (most Puppy util dotpets are built like that) - just some thought that having separate config or configs would be a good idea in the sense that users may not want to modify actual bash script. Also others (such as peebee) also suggested it and Fred asked for suggestion of method to do it:

@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?

I was just supplying that request to the best of my own limited knowledge. In practice, I would also just go for one config file plus the main script arrangement using something like the method(s) I posted. I use my own builder script anyway, for my own use, so don't mind how Fred builds his main one.

wiak

EDIT: In view of the other comments, I think no config file (just keep a single script) is probably best for most people - easier to share around and use as one simple file with people's preferences in that anyway.

[peebee]

Oh Dear!!.....

Keypad and arrow keys do not work in locale selection.....

Ended up in live system with a keyboard typing rubbish....

;qbyurso.6
-kcdtheaz
'xgvwni

[belham2]

Personally, I don't even really see the need for a config file (or the gui for that matter).

I prefer to list the packages inside the script, make comments with notes about what I've added or removed and why, give that version of the script a name to keep track of what it is (e.g. mklive-gui-v5chrome), and then run it.

But, whatever Fred wants. . .

I just feel like you all are "splitting hairs" here, so to speak. Some want this, some want that. Rcrsn51 reinforced that to me in how he'd like to keep things. The beauty of the script is its up to user how they want to do things. Dancytron saves different scripts, mklive-stretchgui-v1, mklive-stretchv2, etc, etc. For me, I think that is crazy and introduces not only added tracking but unecessary complexity. I personally have one mklive-stretchgui that is accompanied by a leafpad.txt file. In that leafpad.txt file is every configuration of every build I've done, organized by 'category' or 'entry' location, thus allowing me to look at it all builds at once instead of opening up many diff scripts to look at what I did on various builds. From this leafpad.txt file, I can just simply highlight & copy for placement into my one mklive-stretchgui when I want to try a new variation and/or version of a build. And this .txt file, I can share easily to anyone showing all different types of build. But, Dancytron's method works just as well. What am I trying to say is you all are "splitting hairs" here over something uneccessary. How about let's focus energies, i.e. discussions, on helping Fred find bugs, find oversights, rather than how we approach a script whose beauty lies in its ability to be approached & adapted however a person who is using it wants. Just a suggestion.


@peebee---interesting about the keyboard thing---I have only used the selection of "English (US) - English (US, with euro on 5)" (I'm up to about ~15 builds now, endlessly trying variations on what works and what doesn't). I will try a build today with what you chose and see if it does the same thing for me. Can I ask what you used to do the build? Was it on a ddog or trinity or tahr or your lxpupsc or lxpupxenial? Since I keep all them up to date in a dedicated external hard drive that I plug in to whatever I am using, I just want to make sure to use the same OS as you did for the build to see if I can reproduce the same error on either the laptop and/or the desktop systems.

[sc02f]

Hi Fredx181 and all,

How can I build Stretch Live with google chrome as my default browser?
I try to push google-chrome/chromium but I got error "unlocated package".

Can I have something like cpufreq to control cpu speed (like debiandog have a script on init.d to control that thing).

Can I change the kernel to 4.10 or 4.12?

Sorry about my English. Thanks in advanced.

[wiak]

Actually, making yad a dependency of the script is also 'unnecessary'. It is not splitting hairs to wish the script was kept as simple as possible in terms of needed dependencies. Having yad is nice (when available) but better is use of commandline switches to activate that part of the code and only when yad is on the system. But for me it makes no big deal since like most of us used to scripting we adopt and adapt anyway. Most non-scripting users probably like having the GUI and using leafpad to store configs is a perfectly good approach to keeping different configs for cutting and pasting I feel.

More important is indeed finding and fixing bugs and trying to write the script in a way that makes it easy to expand when needed and easy to maintain - these are the issues I'd address. For example, better not to have hard-coded variables much of the time - might want xenial rather than stretch so that should be a variable.

Also modularisation into smaller specific functions makes maintenance and expansion easier (all still in one script fine). It is basically working now so I do feel most energy should go into making it more general purpose (xenial not just stretch and so on) so replace hard-coded names and make them variables.

But not my script and I'm sure in time Fred will come to address such matters anyway. No script is ever perfect or finished for that matter... and that is why how the script is organised is ultimately very important indeed.

wiak

[dancytron]

Hi Fredx181 and all,

How can I build Stretch Live with google chrome as my default browser?
I try to push google-chrome/chromium but I got error "unlocated package".

Can I have something like cpufreq to control cpu speed (like debiandog have a script on init.d to control that thing).

Can I change the kernel to 4.10 or 4.12?

Sorry about my English. Thanks in advanced.

I am the unofficial Chrome guy so I'll answer the Chrome question.

Remove the firefox-esr-* entry and in its place put "google-chrome-stable" that should install the correct chrome package.

Boot it up after it is built. If you pick Chrome from the menu, you will get the "Chrome won't run as boot" error. You have a couple of choices.

1. In /user/local/bin, there are two little scripts. One is called chrome-root.sh. Select it, go to edit-create link and put the link on the desktop. When you click on it then Chrome will run with a nasty message saying you shouldn't be running with -no--sandbox. But it runs fine. If you want to get fancy, you can create a *.desktop file for the script to put it in the menu and give it an icon, but it isn't necessary.
2. Install gksu (or put it in the build to start with). Use the add user function to add a user called "puppy". There is a little script in /usr/local/bin called chrome-puppy.sh. It will run Chrome from root as the user puppy. You can create a *.desktop for it if you want.
3. Create a new user called whatever you want to call it. Log in as that user. Run Chrome normally from there.