Moderator: fredx181
fredx181 wrote: Fri Aug 12, 2022 3:47 pmAh, I see now, probably "image" in /mnt/live/memory/images/changes-exit/upperdir/live/ is a symlink to your sda1 partition, nothing to worry about, edit the grub.cfg on sda1 and should be OK.
Taking a break now "too darn hot here'"
OK thx Fred
Should look like this (with the arrow on the folder icon, meaning it's a symlink (to sda1) which is allright)
Let me know how it goes after reboot please.
fredx181 wrote: Fri Aug 12, 2022 3:47 pmAh, I see now, probably "image" in /mnt/live/memory/images/changes-exit/upperdir/live/ is a symlink to your sda1 partition, nothing to worry about, edit the grub.cfg on sda1 and should be OK.
Taking a break now "too darn hot here'"
done! ( on the image folder there is an arrow)
I restarted and for now everything works as usual.
I am happy to have solved this problem so I can save everything I deem essential without worrying about space.
thank you very much Fred and sorry for all the inconvenience I cause you.
your s hip hip hooray !
soniabu wrote: Fri Aug 12, 2022 4:01 pmfredx181 wrote: Fri Aug 12, 2022 3:47 pmAh, I see now, probably "image" in /mnt/live/memory/images/changes-exit/upperdir/live/ is a symlink to your sda1 partition, nothing to worry about, edit the grub.cfg on sda1 and should be OK.
Taking a break now "too darn hot here'"done! ( on the image folder there is an arrow)
I restarted and for now everything works as usual.
I am happy to have solved this problem so I can save everything I deem essential without worrying about space.
thank you very much Fred and sorry for all the inconvenience I cause you.
your s
OK Great !! 
EDIT: Actually there should be more and better documentation about DebianDog and FAQ including e.g. "How to transfer savefile content to save folder"
But time and energy doesn't permit that for me, anyway, people reading this thread can learn more about the ins-and-outs of it.
Fred, I wanted to start over as you suggest (not only for Kodi; but also to run tests without exogenous errors (caused by sonia 
)
but after executing the instructions (mkdir, gurb) on reboot it gives me the message that it cannot find mnt / sda2 / B_worm-new.
The attached pictures illustrate the situation. I cannot find the error.
If you can help me when you have time I will be grateful. Sonia
ADDENDUM:
the AppImage Apprepo.de https://apprepo.de/ that I have tested so far and work with Bookworm are:
GMPI, PHOTOCollage,PDFStudioViewer (free version), AUDACITY,VueScan, Knips, ScreenCloud, Calibre, VLC,
PDFStudio, ImageMagick, Knips, Kazam, Avidemux,Exifcleane, Cryptomator, ...
@soniabu Replied to your PM about this issue, please keep this public by continuing here.
Fred wrote:
I took a very good look at your screenshots and couldn't find anything wrong with what you did, so ... weird that it doesn't work for changes (if changes = / mnt / sda2 / B_worm works, why not with changes = / mnt / sda2 / B_worm-new:?:, again, I can't explain. I assume you created the directory / mnt / sda2 / B_worm-new before booting with the new entry in grub.cfg ? EDIT: I just checked with changes = / mnt / sda2 / B_worm-new and it works fine for me. The only thing I can think of why not for you is that your folder name B_worm-new maybe has a space at the end. If not, it's very mysterious. You can maybe try another name (it must match the name in grub.cfg).
thanks Fred, tonight I will try with another name and verify the sequence with which I did the job.
Well see you later
sonia
P.S.
other AppImage Apprepo.de that work in Bookworm I added to the previous post.
Firefox 102.2.0 esr anomaly:
when you close and reopen the system - even if you save the contents in the previous session -
among all the Firefox settings only the default zoom set is not maintained at the next system re-initialization;
zoom setting which is reset to 100%.
This only happens when I re-initialize the system; during the session I can close and reopen firefox
and the zoom is maintained at the magnification set by the user.
Updated mklive-bookworm script, see attachment at first post .
Change is: Download and install newest debootstrap that really supports the (legacy) --no-merged-usroption., see also viewtopic.php?p=68558#p68558
See about usrmerge (which we are trying to avoid because of several reasons, e.g. sfs-load won't work properly as is): https://packages.debian.org/unstable/main/usrmerge
Updated mklive-bookworm, attached at First Post
Change is similar as mklive-sid see info, specially about usrmerge (avoid or not 
): viewtopic.php?p=69247#p69247
Not sure about bookworm since Debian seems to argue a lot!
Overall however it is clear that all modern Linux distros have taken Fedora lead (actually it was Sun Solaris UNIX who started it and lead the way) and moved towards usrmerge situation.
Somewhat annoyingly to me, Void Linux does implement usrmerge situation but with some minor differences to Fedora and others following Fedora lead:
In Void filesystem (and thus KLV), /usr/sbin is symbolic link to /bin, which itself is symbolic link to /usr/bin, whereas in Fedora (and recent Pups), /usr/sbin is a real directory that /sbin is a symbolic link to.
Similarly, /usr/lib64 is a symbolic link to /lib, which itself is a symbolic link to /usr/lib, whereas in Fedora /usr/lib64 is a real directory that /lib64 is a symbolic link to.
In other words, Void Linux takes usrmerge to the extreme where all binaries end up pointing to /usr/bin and all libs point to /usr/lib. One exception, that may or may not be true now was /lib32 that pointed to real directory /usr/lib32 (why that exception?!!!... must be something to do with way their legacy 32bit packages worked I suppose).
I find it annoying, because simple little differences like that are what tends to make packages from one distribution incompatible with another even in cases where all else about a package (in terms of compatibility) might be fine. Just shows why earlier Puppy filesystem hierarchy was such a design mess/nightmare though - dimkr correctly addressed that rubbish situation.
I do kind of like Void's more 'everything' to /usr/bin and /usr/lib approach since never have to wonder where things might be, but... Fedora (RedHat's development distro really) rules the waves when it comes to such matters and probably best to just go with the flow. Hence why I'm happy to have been able to include Fedora Rawhide (most leading-edge Fedora dev distro) in previous weedogit.sh (now firstribit.sh) since I can check what Fedora are moving towards. Yes, I know, people don't like being told what to do by the likes of Lennart Poettering..., but overall, in such matters I go with the flow and works for me thus far.
https://www.tinylinux.info/
DOWNLOAD wd_multi for hundreds of 'distros' at your fingertips: viewtopic.php?p=99154#p99154
Αξίζει να μεταφραστεί;
wiak wrote:... whereas in Fedora (and recent Pups), /usr/sbin is a real directory that /sbin is a symbolic link to
In Debian usr-merged system /usr/sbin is a real directory too.
... go with the flow ...
Well, easier said than done, however it turns out less complicated than I expected.
Did some experimenting with a usr-merged system (by building with mklive-bookworm without the debootstrap --no-merged-usr option), lots of changes required, but works okay as far as I tested now.
One complication is that .squashfs modules containing e.g. /lib as a real directory will not work (system won't boot then), so compatibility with old .squashfs modules is problematic.
Packages (.deb) containing e.g. /bin or /lib as a real directory still install ok, so that's a relief (seems dpkg/apt is smart enough to handle that well).
EDIT: Here's modified mklive-bookworm (experimental) that creates a usr-merged system, in case someone wants to test.
Re: merged-usr
As I'm having trouble to understand what the usr-merged thing can be good for, here's some explanation (some people are really against it to make it "standard", I'm not happy with it too btw):
https://groups.google.com/g/linux.debia ... T8MheUAgAJ
EDIT: Seems to be concluded that it becomes the standard for Bookworm and later:
https://bugs.debian.org/cgi-bin/bugrepo ... 978636#178
dancytron wrote: Thu Oct 13, 2022 8:47 pmI ran the mklive-bookworm-mod script. It produced a Debian Dog that booted.
Anything else in particular to test?
Thanks, yes, new quick-remaster v1.3.1 (I just changed trying to be compatible with usr-merged system) https://github.com/doglinux/bookworm/ra ... .1_all.deb
The upgrade-kernel script should be modified too, will look at that later.
For the rest I didn't think much yet about what problems could occur with this usr-merged system.
But for sure it breaks the system when loading squashfs modules (from live) containing /bin, /lib or /sbin as a real directory.
(and affects as in quick-remaster the checking for separate kernel squashfs) .
For example the kernel squashfs (in live) in this setup has now /usr/lib/modules/<kernel-version> instead of just /lib/modules/<kernel-version> .
Switched repository to static because of the time zone induced apt-get repository errors.
I'm in it now. "Pupmode 13" save on exit mode.
Installed firefox-esr and some other stuff. Also used apt2sfs to create a libreoffice .squashfs file.
Loaded, tested, and unloaded the 22- libreoffice.squashfs file. Then did a quick remaster. Everything seemed to work fine. Tested libreoffice squashfs file again. All worked as expected.
Speed was noticeably better than the Buster version I usually run on this computer.
--Dan
edit: Also tested after adding "00" to the beginning of /live/00-k-5.19.0-2-amd64.squashfs and loading 22- libreoffice.squashfs from /live on boot. All worked as expected.
Hi Dan, thanks, sure looks good overall.
Switched repository to static because of the time zone induced apt-get repository errors.
If I understand well, your timezone and time was wrong and caused the error ?
Installing the package tzupdate should handle that automatically, but needed a fix, I updated it (as ntpdate didn't work anymore on Bookworm (at least for me), fixed it by using curl to sync the time in the start-ntpdate script).
Also used apt2sfs to create a libreoffice .squashfs file
Installing packages from Debian repositories work fine with the merged-usr system, so also with apt2sfs, I guess.
What it does is, if any package contains files in e.g. /lib, it will automatically installed to /usr/lib (same for /bin > /usr/bin) .
But I found some problematic packages (that refused to install) in the custom repository, frisbee and pburn (which I fixed now, added new versions in custom bookworm repo).
fredx181 wrote: Sat Oct 15, 2022 6:39 pmHi Dan, thanks, sure looks good overall.
Switched repository to static because of the time zone induced apt-get repository errors.
If I understand well, your timezone and time was wrong and caused the error ?
Installing the packagetzupdateshould handle that automatically, but needed a fix, I updated it (as ntpdate didn't work anymore on Bookworm (at least for me), fixed it by using curl to sync the time in the start-ntpdate script).
Yes, it gave the repo time in the future error and there were missing dependencies for stuff. I've seen it before and fixed it with /etc/adjtime , but I think that got obsoleted too. It was a very minimal install, so I kind of assumed I was missing stuff.
Then I saw the app for making the repo static and used that, which fixed it.
Okay, did "bite the bullet" to 'go with the flow', mklive-bookworm will create now a 'usr-merged' system (which becomes the standard more and more, not that I like it, but it would be asking for trouble not to go with it) .
New "mklive-bookworm" script attached at first post.
Some required package upgrades in the custom repository are made for making this possible to work.
EDIT:
Note that a downside of this is that .squashfs modules (to be loaded at boot) cannot contain some *real* directories such as /bin, /lib and /sbin (the system fails to boot then).
For example the kernel .squashfs (e.g. k-5.19.0-2-amd64.squashfs) contains /usr/lib/modules (instead of before /lib/modules) as in the system /lib is a symlink to /usr/lib in this new setup.
------------------------------------------------------------------------------------------------------------------------------------------------------
Also updated the "Test ISO" (link and info at bottom of first post), including this usr-merged change.
DebLive_bookworm-tint2-2022-10-26-amd64-UEFI-merged-usr.iso / md5
I built a minimal no browser version, booted in to it, set the repo to snapshot, and installed a few things. Everything seemed okay.
I'll try to do a remaster etc tomorrow or the next day.
I installed synaptic, bleachbit, lxterminal, and some other stuff. Tried to install Palemoon, but it didnt' ask for any dependencies and failed. I'm going to chalk that up to a Palemoon packaging bug. Firefox-esr installed fine. Did a quick remaster and I am posting from it now. All seems to work.
I assume /lib* all being links now is what all the fuss is about????
I did get an error installing mtPaint.
Code: Select all
root@live:~# mtpaint
mtpaint: error while loading shared libraries: libjpeg.so.8: cannot open shared object file: No such file or directory
root@live:~# Installing libjpeg8 manually fixed it. There was a different libjpeg6.2 in pfind. I guess that kind of stuff is to be expected with unstable.
Thanks Dan,
The mtpaint is from the custom Dog repository, included years ago (from the Stretch area), cannot remember TBH why, anyway added dependency libjpeg8 to newer version now, which should fix it.
I assume /lib* all being links now is what all the fuss is about????
Not sure to understand what you mean to say exactly, can you explain ?
EDIT: Re; Palemoon, yes that package probably wont work anymore, will soon remove it from custom repo
*** mklive-bookworm updated ***
Attached new version at first post
Fixed some things that caused the build to fail because of some changes in the Debian repository (e.g: debootstrap newer version, fuse is deprecated, now called fuse3).
fredx181 wrote: Fri Nov 04, 2022 3:47 pm*** mklive-bookworm updated ***
Attached new version at first postFixed some things that caused the build to fail because of some changes in the Debian repository (e.g: debootstrap newer version, fuse is deprecated, now called fuse3).
I ran it and built an xfce minimal.
It booted fine. Nothing obvious amiss.
Hi folks,
in my case after creating xfce distro with bookworm buils script it hangs during boot with the following error message:
"exec line 587 /usr/sbin/chroot: not found". But chroot not supposed to be in live folder. What could that be? Some month ago with an older build script bookworm booted flawlessly.
Regards Payoon
@Payoon
Well just tested mklive-bookworm > XFCE and it booted fine, did you use the newest script from first post ? (appimages are not maintained including the newest dev. atm).
Also you cannot use save storage from earlier bookworm install (and using older .sfs modules may cause the failure, the usr-merged system is a major change, see above)
Hi Fred,
thanks for the answer. We are coming closer. The reason for that "exec line 587 /usr/sbin/chroot: not found" message is indeed my firmware squashfs module.
I have so far use on an oldone (From jessie) and it worked for buster, bullseye, old bookworm and old SID. Now I removed it from live folder and the error message doesn't appear. The whole boot process goes much further until (I think) when X starts. Then stops ( supposedly because no graphics driver). I remember when running the build script I saw a lot of messages about missing firmware ( mostly radeon and that is the card that I have) These messages did not appear when I did the old bookworm script ( I am sure).
I have tried with a squash file I created from bookworm debian file firmware-amd-graphics_20221012-1_all.deb but when running it in the live folder the error message is the same.
How can I get the firmware into the booting system?
BTW all said above is valid for SID Build script also.
Payoon
Hi Payoon, these sort of problems that you have is exactly the reason why I tried to avoid a "usr-merged" system for years by using workarounds.
But nowadays it's close to impossible avoiding it, so the new build has symlinks e.g. /bin /lib /sbin now, not real directories in any loaded .squashfs (otherwise booting will fail).
So a .squashfs module cannot contain e.g. /lib as real directory, instead it must be /usr/lib (for example location of firmware: /usr/lib/firmware) .
Here's a new firmware .squashfs module for bookworm that will match with the new setup (contains /usr/lib/firmware) : https://github.com/DebianDog/MakeLive/r ... e.squashfs
EDIT:
I have tried with a squash file I created from bookworm debian file firmware-amd-graphics_20221012-1_all.deb but when running it in the live folder the error message is the same
The .deb packages still may contain e.g. /lib as real directory, when installing, the package manager (apt, dpkg) does handle that by moving contents of /lib to /usr/lib .
But for to create a squashfs module from .deb manually you need to move /lib to /usr . (create /usr first if not exist)
Other way is to include in the build by adding the firmware-amd-graphics to the install list (at the GUI "Extra Install" tab):
Hi Fred,
thank so much.Both ways that you recommended did the trick. Bookworm works fine now. The method no. 2 gives a smaller footprint.
Still have to check how to modify and adapt my legacy sfs files and squashfs files to use, but that should be the smaller problem.
Main problem is solved.
Thanks again.
Payoon