BusterDog + build system (no-systemd)

[enrique]

@fredx181

I been having fun with BusterDog. I really like it so far. I got no trouble running all my windows ( x86 & x86_64). I mean all 64/32/16 bits programs and even old dos games. Only had small issue when I install wine/winetricks, where debian apt refuse to download due to systemd missing. So I did use a different changes.dat where I activated systemd a downloaded the missing wine/winetricks the saved to a wine.squashfs module. See as I said earlier, if we can get the solution we like, at least there is always an alternative way.

But now I guess I should move forward and study how I can build my special modules/drivers for v4l-dvb. Good news is that the kernel seems to have media_build in. As I can see "/lib/modules/4.19.0-6-amd64/kernel/drivers/media/dvb-frontends" etc. I will be testing it soon. And determine the current status using my USB PCSAT Card. But normally I need to compile at least my drivers as it requires patch and rebuild so that I can do Blind Scan. I will not detail this any more to prevent further confusion.

Point Is I need Kernel Sources used and any special method/script you guys do to make the kernel compatible with DebianDog, if any. The mklive-buster seems to download already build kernel from https://debiandog.github.io/MakeLive/ke ... d64.tar.gz And uname -a shows

Code: Select all

Linux live 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2 (2019-08-28) x86_64 GNU/Linux

I need it with PAE.

Can you help me find the kernel sources? Thanks in advance.

[dancytron]

@fredx181

/snip

Point Is I need Kernel Sources used and any special method/script you guys do to make the kernel compatible with DebianDog, if any. The mklive-buster seems to download already build kernel from https://debiandog.github.io/MakeLive/ke ... d64.tar.gz And uname -a shows

Code: Select all

Linux live 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2 (2019-08-28) x86_64 GNU/Linux

I need it with PAE.

Can you help me find the kernel sources? Thanks in advance.

This is the command I used to install the kernel sources to compile my nvidia driver.

apt install linux-headers-$(uname -r|sed 's/[^-]*-[^-]*-//')

When I was done, I searched for "linux-headers" in synaptic to delete them.

This was the output from synaptic when I was deleting them, which should tell you the names of the individual files.

linux-headers-4.19.0-6-amd64 will be removed
linux-headers-4.19.0-6-common will be removed
linux-headers-amd64 will be removed

[enrique]

dancytron 1rst as always THANK YOU for your response. That is the default method to compile drivers for a regular Linux Kernel. Please forgive me as I can be wrong. I am under the assumption that BusterDog as any other of the debiandogs do not just used a regular kernel from main stream. I am under the impression that the kernel is manipulated in some way to allow us to do the porteus-boot See description: Choice of Boot Methods: porteus-boot and live-boot v3 (see for options Here)

In Porteus (operating system) I thnink they use Porteus Kernel Builder. It is my expectation that we use something similar.

I have a feeling that the goodies are found inside the initrd1.xz. Maybe they add a "1" to identify that initrd as porteous. But I can be wrong!!

But I am newbie and my lack of experience makes me wonder.

[dancytron]

Fred will come by and tell us for sure, but I think Fred just adds the aufs module to allow the layered file system. I don't think that effects the headers.

I was able to compile the nvidia drivers with the headers I described.

[fredx181]

Fred will come by and tell us for sure, but I think Fred just adds the aufs module to allow the layered file system. I don't think that effects the headers.

I was able to compile the nvidia drivers with the headers I described.

Yes, that's right, it's the Debian kernel with only aufs module added in /lib/modules (and in initrd1.xz), so if the linux-headers version you install corresponds with the kernel version (4.19.0-6) it's OK.

Fred

[rcrsn51]

apt install linux-headers-$(uname -r|sed 's/[^-]*-[^-]*-//')

Why all the 'sed' stuff?

[fredx181]

Why all the 'sed' stuff?

It will give you the name of the metapackage (which will always install the newest version)

Code: Select all

root@live:~# echo linux-headers-$(uname -r|sed 's/[^-]*-[^-]*-//')
linux-headers-686-pae

(this is on Stretch)

EDIT: But I'd recommend to search for linux-headers package corresponding with the kernel version installed, (not using metapackage), e.g. linux-headers-4.19.0-6-amd64

Fred

[enrique]

Let me explain myself 1rst. I consider all of you our expert masters. If I ask if because my need to understand. Please in no way consider my questioning as a contradiction to you as an expert. I am asking questiions before I start to prevent wasting my time. I had not even connect my device yet to the computer. Maybe it will work as is!

Yes, that's right, it's the Debian kernel with only aufs module added in /lib/modules (and in initrd1.xz), so if the linux-headers version you install corresponds with the kernel version (4.19.0-6) it's OK.

Fred

This answer confuse me. Let me explain. If I go to a regular puppy kernel config: woof-CE/kernel-kit/configs_x86_64/DOTconfig-4.9.30-x86_64 I will find CONFIG_AUFS_FS included.

Code: Select all

...
# Pseudo filesystems
...
CONFIG_AUFS_FS=y
CONFIG_AUFS_BRANCH_MAX_127=y
# CONFIG_AUFS_BRANCH_MAX_511 is not set
# CONFIG_AUFS_BRANCH_MAX_1023 is not set
# CONFIG_AUFS_BRANCH_MAX_32767 is not set
CONFIG_AUFS_SBILIST=y
CONFIG_AUFS_HNOTIFY=y
CONFIG_AUFS_HFSNOTIFY=y
CONFIG_AUFS_EXPORT=y
CONFIG_AUFS_INO_T_64=y
CONFIG_AUFS_XATTR=y
CONFIG_AUFS_FHSM=y
CONFIG_AUFS_RDU=y
CONFIG_AUFS_SHWH=y
CONFIG_AUFS_BR_RAMFS=y
CONFIG_AUFS_BR_FUSE=y
CONFIG_AUFS_POLL=y
CONFIG_AUFS_BR_HFSPLUS=y
CONFIG_AUFS_BDEV_LOOP=y
# CONFIG_AUFS_DEBUG is not set
...

Now if I go and read our BusterDog config /boot/config-4.19.0-6-amd64 I wlll not find CONFIG_AUFS_FS=y. I can even look at the downloaded kernel: https://debiandog.github.io/MakeLive/ke ... d64.tar.gz Then extract what is inside to get k-4.19.0-6-amd64.squashfs. The extract that to... Then again ints /boot/config-4.19.0-6-amd64 I will not find CONFIG_AUFS_FS=y.

How is that possible? I guess you could added the AUFS & any other porteous modules binary manually.

Also I have not been able to find how the initrd1.xz & vmlinuz1 where created? Even a simple explanation as why we need 1 on it? And I have a feeling there is more in this 1. BusterDog 'boot style Porteus' - porteus initrd1.xz made for debian kernel and firmware. + encrypted save file option.

Best I had found is Porteus boot

Again and most important, please see that I do not try to contradict you. Nor I am trying to force you to provide any secrete recipe. May be the answer is that, it is your special recipe that you want to keep for yourself. If that the case just let me know. Please forgive me if this sound strange. I know some time I cause misunderstandings for been too direct. As always THANK YOU for your help and dedication. I am a fan of yours. God Save the BusterDog, Long Live BusterDog.

[fredx181]

This answer confuse me. Let me explain. If I go to a regular puppy kernel config: woof-CE/kernel-kit/configs_x86_64/DOTconfig-4.9.30-x86_64 I will find CONFIG_AUFS_FS included.
...
...
Now if I go and read our BusterDog config /boot/config-4.19.0-6-amd64 I wlll not find CONFIG_AUFS_FS=y. I can even look at the downloaded kernel: https://debiandog.github.io/MakeLive/ke ... d64.tar.gz Then extract what is inside to get k-4.19.0-6-amd64.squashfs. The extract that to... Then again ints /boot/config-4.19.0-6-amd64 I will not find CONFIG_AUFS_FS=y.

Hi, enrique, first of all, no need to say that your intention is not to contradict, I understand that you just like to understand things.
Second: there is absolutely nothing to be kept secret, and please understand that the DebianDog project started at almost 6 years ago and developed step by step, so I cannot explain all that's done in that period (many discussions were in the past about porteus-boot setup, initrd1.xz and aufs).
See also links here: https://debiandog.github.io/doglinux/zz07about.html

About porteus-boot and aufs:
Yes, the official Debian kernel is compiled without aufs (as you noticed in the config).
So what we had to do to make use of aufs is simply adding it to the kernel as extra module in /lib/modules and to the initrd (using aufs-dkms to build aufs module)
Btw, note that the porteus-boot method is just the way porteus uses for a layered system (init script in initrd1.xz) and boot options (like from=... changes=...) for the rest Busterdog has no connection with Porteus.
About the "1" in initrd1.xz, it's just a name, there was a reason, but I can' t remember which, anyway, not important, I guess.

Hopefully this makes things a bit more clear for you, otherwise you can always ask for more details of course

EDIT:

Also I have not been able to find how the initrd1.xz & vmlinuz1 where created?

How initrd1.xz is created is a (too) long story (but again, not secret), vmlinuz1 is just renamed vmlinuz-..... as it will be in /boot when installing linux-image-.... from Debian package manager, not modified.

EDIT2: You may be interested to install and try "upgrade-kernel"
In the past I did these things manually but not anymore now, it automates the process of creating initrd, <kernel>.squashfs and building aufs module (runs in chroot, so doesn't install anything in the system)

Fred

[enrique]

I ask for help thinking It will better be prepare with info before proceeding to build kernel or special medial utils for dvb. Starting to search between historical archives will be insane. I guess I should start like any other user. Hooking my device. Setting up my PC just to know that I need to build kernel for my special drivers needed for Blind Scan.

Our kernel version is at 4.19.0-6. See normally I download v4l-updatelee kernel sources. From
https://bitbucket.org/updatelee/v4l-updatelee or
https://bitbucket.org/majortom/v4l-updatelee or
https://bitbucket.org/bluzee/linux-udl

Then I build my kernel. In puppy I use woof-CE/kernel-kit

But up to know, from what you said build same kernel then just

Code: Select all

.. make use of aufs is simply adding it to the kernel as extra module in /lib/modules and to the initrd (using aufs-dkms to build aufs module) 

I have a strong feeling that will be not enough. Future experiment will show the result. See you guys latter. I will be doing my assignment.

[dancytron]

apt install linux-headers-$(uname -r|sed 's/[^-]*-[^-]*-//')

Why all the 'sed' stuff?

I lifted it straight out of the instructions to install the nvidia drivers in stretch.

I assume it is to make it automatically know which version to download, but it worked so I didn't question it.

https://wiki.debian.org/NvidiaGraphicsD ... Stretch.22

[enrique]

@dancytron
Just in case I am listening you ( reading), not ignoring. I will definitely use your method under other circumstances where I have a costume driver source to build.

But at the moment it is not.
1) This guy updatelee build a full costume kernel that allow what will be impossible to do under the original manufacturer driver and application. Yes is a hack, where not only he modify a few drivers, add some of his libs, then add to it his special application that allow a $100 USB device function like a $500-$1000 professional device.

2) The real truth is that even if I could follow that road I think I would not need it. As it seems that 1-DEVX-Buster-k4.19.0-6_amd64.squashfs has all thos headers allredy included. If you extract "1-DEVX-Buster-k4.19.0-6_amd64.squashfs.extracted/usr/src" You will find

Code: Select all

linux-headers-4.19.0-6-amd64
linux-headers-4.19.0-6-common
linux-kbuild-4.19

So it seems devx has the headers. Thanks. Keep the good work, sharing with us all those wonderful hints and experience.

@fredx181
Do not know when you edit it but just saw

Code: Select all

EDIT2: You may be interested to install and try "upgrade-kernel"
In the past I did these things manually but not anymore now, it automates the process of creating initrd, <kernel>.squashfs and building aufs module (runs in chroot, so doesn't install anything in the system)

Will be looking into that soon. Hope to find what I need. Thanks again.

[fredx181]

But up to know, from what you said build same kernel then just
Code:
.. make use of aufs is simply adding it to the kernel as extra module in /lib/modules and to the initrd (using aufs-dkms to build aufs module)

I have a strong feeling that will be not enough. Future experiment will show the result. See you guys latter. I will be doing my assignment.

Not sure what you mean by "not enough". quote above about aufs is not meant as how-to, just saying briefly what we did and it works.
BusterDog is aimed to be "pure" Debian as much as possible, that's why using the stock Debian kernel. (that's also what "upgrade-kernel" does install/upgrade, btw)
Of course it's possible to use a self compiled kernel (or a kernel taken from e.g. Fatdog or Puppy), but then you must know exactly how to make it work, which can be rather complicated.
So... why would you want that anyway ? (need of newer kernel or ... ?)
Also, when using a different kernel, some special documented Debian features won't work anymore (e.g. using "dkms" packages).

Fred

[rcrsn51]

@enrique: When I was using Stretch with k4.9.0, I occasionally needed a kernel upgrade to support new hardware.

I would take a Puppy "huge" kernel and drop it into my Porteus "live" folder.

I would rename the Puppy vmlinuz as vmlinuz1 and rename the zdrv.sfs file with a .squashfs extension.

Maybe you can do the same thing with the custom v4l kernel that you build in the Puppy kernel-kit.

[enrique]

@fredx181
I been given a lot of suggestion by many puppy users here. For the most part they seems to suggest me to stop trying to understand things. And instead just use Puppy as every else do. I do understand their point of view. And this makes me realize that if I was a regular Puppy user I will not continue be here in this post. They are in fact right. I need to open a new thread Asking for help where I can express my personal needs. Building/Adapting a new kernel.

See it is not fair to BusterDog + build system (no-systemd) as in that term BusterDog has FULLY fulfill my needs. I have a perfect Puppy Debian Dog running at home. And the build system work 100% all the time.

Regards your suggestion on "upgrade-kernel". I stop building, so I have not look in to that file. Instead I pent the time installing BusterDog in a different PC. Then Install all my setups to have Linux TV running my Satellite and Terrestrial TV adapters. It took away all the time I had. My intention is to verify my real need for that special kernel. Who knows may be I can live without it.

Regards "not enough", PLEASE do not misunderstand me, it was not you. I was frustrated with myself. It is funny as I wrote some where else woof-CE Kernel Kit used to build updaelee kernel.

...I would take a Puppy "huge" kernel and drop it into my Porteus "live" folder....

Exactly, I know. I did thought on giving this a try. Building the kernel with woof-CE Kernel Build. And hooping it do boot and execute v4l-updateleel. I do not need it to be perfect, just to allow me to scan the Satellites while hunting for new channels to show up. So it will be just another extra kernel in the folder + a new menu in grub4dos. No need to change the name. Similar as Ubuntu boot from different kernels.

I will conduct my offtopic issues at:Help build custom BusterDog.


BusterDog + build system (no-systemd) is a hit. I am not only trying it, but I see me using it for a long time. Long live BusterDog.

[rcrsn51]

Why all the 'sed' stuff?

I lifted it straight out of the instructions to install the nvidia drivers in stretch. I assume it is to make it automatically know which version to download, but it worked so I didn't question it.

The simpler way is just

Code: Select all

apt install linux-headers-$(uname -r)

which would be less confusing to newcomers.

[dancytron]

Why all the 'sed' stuff?

I lifted it straight out of the instructions to install the nvidia drivers in stretch. I assume it is to make it automatically know which version to download, but it worked so I didn't question it.

The simpler way is just

Code: Select all

apt install linux-headers-$(uname -r)

which would be less confusing to newcomers.

Thanks

dan

[fredx181]

apt install linux-headers-$(uname -r)

which would be less confusing to newcomers.

Yes, and not only that, it also makes sure you install the correct headers version corresponding with the running kernel version.
The command "apt install linux-headers-$(uname -r|sed 's/[^-]*-[^-]*-//')" will install the newest version, which may be newer than running kernel version, and may result in build failures.

Fred

[mauros]

JWM is an excellent choice for building a stable lightweight desktop, as it's written in c lang and uses a minimal amount of RAM.
That's why it's the default WM for compact linux/BSD distros/OSes, like Puppy and DebianDog.
The problem occurs with its menu construction. JWM configuration provides static only menus, unable to update automatically when installing/uninstalling menu applications.
Some third-party solutions such as lxde menu data bridging or using xdgmenumaker (https://github.com/gapan/xdgmenumaker) could cover it, but the installation of extra packages and the use of python libs is not exactly what we are looking for when using and building such compact distros.

Working around that, i couldn't escape writing from scratch a menu maker bash script. It's based on /usr/share/applications .desktop files reading with some improvements in compatibility and menu construction.
It's a script written with a k.i.s.s. principal for being understandable and configurable by users with a basic bash experience.

How to test/use it:
1. Download or git clone the file: https://github.com/maurosh/SparkyBonsai ... numaker.sh

2. Make it executable

Code: Select all

# chmod +x /path/to/sparkybonsai_jwm_menumaker.sh

3. Put an XML tag in your .jwmrc file:

<include>exec:sh /path/to/sparkybonsai_jwm_menumaker.sh</include>

After that, the menu will auto-update everytime the JWM reloads.

Note1: Categories menu icons are hardcoded inside the script according to sparky bonsai icons filenames. For use with different icon themes you have to manually edit the categories icon names. The applications icon names updates dynamically from the .desktop files.
Note2: Academically it is compatible with zsh too but i haven't test it yet.

[enrique]

@mauros I see you love JWM. I do not. Rox, I do not like it neither. Thanks God he created colors to chose from. I am a fan of LXDE, I know I came from lame Win.

I have a question for Fred. I do have various disk on some PC and/or at least various partitions. When I install BusterDog64 with change.dat at boot time, I had only mounted Home drive where BusterDog reside. But If instead, I chose a ext Linux partition to mount a change folder, then a weird thing happen! It boot with ALL my partitions mounted... Why this behavior? Thanks ahead.

Long live BusterDog.