Bullseye build script

[fredx181]

Hi Fred !
Since upgrade via Synaptic ..something`s foul........things no longer will be saved.
I am using Porteus Boot Option plus copy2ram in menu,lst as boot Parameters.
Does anybody else encountered this ?
When desktop is booted after Startup my SSD Boot Drive Partition (where Bullseye is (frugally) installed ) is not mounted at startup.
Can no longer save via save2flash.....
Anybody else?

So far I couldn't reproduce that, but will investigate further.
Can you say some more about your setup ? e.g. squashfs modules loaded from "live" or/and by loading "on the fly"
EDIT: And which Desktop choice you build with?

"can no longer save via save2flash....."

Any error message when running it from terminal?

Fred

[Duprate]

Good morning, Fred! Without wanting to bother you too much, which application on DebianDog is used to control the time of the active monitor (equivalent to Pupx X on puppy linux)?

[fredx181]

Good morning, Fred! Without wanting to bother you too much, which application on DebianDog is used to control the time of the active monitor (equivalent to Pupx X on puppy linux)?

You mean screen blanking time ?
I can't think of an application atm, but you can add a "xset ...." line in ~/.xsession (before the last line), see also here:
https://shallowsky.com/linux/x-screen-blanking.html

They can also be set via xset. You can set the blank timeout with:

xset s blank
xset s 300

will tell X to use screen blanking after the system has been idle for 300 seconds (five minutes).

Fred

[fredx181]

...
I went add the 5.10 rt kernel but found the /usr/local/cr-initrd/ is not there. I borrowed the folder from sid and made a quick attempt but there were some errors and the resulting init files didn't boot. Not surprised but... (no harm to try;)
Is there adjustments that could be made to the sid mkintird/initramfs or I should just hang tight for the bullseye version? assuming you are planning to keep this feature going.
...

Hi puddlemoon, /usr/local/cr-initrd/ is part of the "upgrade-kernel" package, so install it and then the easiest way to install the rt kernel is to run:

Code: Select all

upgrade-kernel

Then first choose a partition (must be Linux filesystem) and select the rt kernel from list (unsigned should be OK I guess):
EDIT: There may come a message that 5.10 is already the kernel you booted, just continue then.

upgrade-kernel

upgrade-kernel.png (64.17 KiB) Viewed 983 times

At the end of the process there will be a folder containing:

created files by upgrade-kernel

2021-01-15-145343_376x173_scrot.png (16.68 KiB) Viewed 983 times

Then copy the files to your frugal install "live" folder (need to overwrite initrd.. vmlinuz1, better first make backup of these) and reboot.

Fred

[backi]

Double Post

.

[Duprate]

Good morning, Fred! Without wanting to bother you too much, which application on DebianDog is used to control the time of the active monitor (equivalent to Pupx X on puppy linux)?

You mean screen blanking time ?
I can't think of an application atm, but you can add a "xset ...." line in ~/.xsession (before the last line), see also here:
https://shallowsky.com/linux/x-screen-blanking.html

They can also be set via xset. You can set the blank timeout with:

xset s blank
xset s 300

will tell X to use screen blanking after the system has been idle for 300 seconds (five minutes).

Fred

Thank you, Fred! As I am testing, regularly using and betting all my chips on DebianDog, I will make one more report: In the November 2020 versions of DebianDog 25 (Sid) and 27 (Bullseye), after the clock settings for my time zone, when restarting with FatDog64 the time was correct. With this latest version, and with the same configuration, the new DebianDog Bulseye presents the correct time but changes the time on the PC by +3 hours. When I restart with FatDog64, the change appears. DebianDog is doing bad things, sticking his finger where it shouldn't be and is having a problem with living with other distros ... Educate that boy!

[backi]

Double Post

.

[backi]

Hi Fred !

Hi Fred !
Since upgrade via Synaptic ..something`s foul........things no longer will be saved.
I am using Porteus Boot Option plus copy2ram in menu,lst as boot Parameters.
Does anybody else encountered this ?
When desktop is booted after Startup my SSD Boot Drive Partition (where Bullseye is (frugally) installed ) is not mounted at startup.
Can no longer save via save2flash.....
Anybody else?

Started from scratch again, did a fresh Build, but Problems with Saving via save2flash still persist when using copy2ram in Kernel line Boot-option.

To make a long Story short.
So just try the following Fred:

Boot with above Porteus (save on Demand) Boot Option ....insert the copy2ram into Kernel line.....Boot into JWM Desktop place/import/copy -- "some File"--- to ~(root)---save with copy2ram.....look for yourself ..if saved or not......and see what happens.

More Details:
My Setup :

(Bullseye) live Folder in Directory named BULLSEYE64 on SSD Drive (sdb)
GRub4Dos on SSD (sdb)

Porteus Boot-Option --save on Demand.

My menu.lst:

title DebianDog Bullseye (sdb)
find --set-root /BULLSEYE64/live/vmlinuz1
kernel /BULLSEYE64/live/vmlinuz1 noauto intel_pstate=enable from=/BULLSEYE64 changes=EXIT:/BULLSEYE64/live/ copy2ram ramsize=100%
initrd /BULLSEYE64/live/initrd1.xz

When booting WITHOUT "copy2ram" Kernel line Boot-option no Problems so far when saving via save2flash--- it works flawless.
Also "Desktop-Drive-Icon" App showing my SSD (sdb) Drive Icon as fully mounted when booting WITHOUT "copy2ram" Kernel line Boot-option.-- ---Clicking with Roxfiler "Desktop-Drive-Icon"on my SSD (sdb) Drive Icon, it shows the whole Content of my SSD (sdb) immediately. SSD(sdb) is fully mounted. Everything is fine.

Things start getting different when booting into JWM with copy2ram in Kernel Line Boot-option and trying to save via save2flash when booted with "copy2ram" Mode:

Give you an Example:
when booted with "copy2ram" Mode:
I placed/copied "for Example" a mp3 file onto ~(root) then did >>>>save2flash ...is showing as "saving"....but it does not.
Also looked into /home/BULLSYEY64/live/changes/upperdir ...no mp3 file... after saving with save2flash.

When save2flash with Terminal:
root@live:~# save2flash
Not saved yet session data:
25M
Your save file/folder has free space:
2770 MB
Merging /mnt/live/memory/changes onto /mnt/live/memory/images/changes-exit...
root@live:~#
but no savings appear..changes upperdir is empty

Things are also working somehow dífferent for "Desktop-Drive-Icon" App when booting into JWM Desktop with "copy2ram" Option.
After first boot -- then clicking on " Desktop-Drive-Icon" App of my SSD (sdb) Drive Icon ---Roxfiler shows "upperdir" and "wordir".-----so SSD (sdb) is not fully mounted at Startup ,not showing whole Content of my SSD (sdb) on Startup and first Roxfiler Click on "Desktop-Drive-Icon" SSD (sdb) Drive Icon . ....in contrast when not using "copy2ram" Option.

To get full access now to the Content of my SSD (sdb) Drive i have to
1:left Mouse click "unmount" (sdb )SSD Drive Icon...
2.then right Mouse Click again on Desktop-Drive-Icon of my SSD(sdb) Drive Icon to (mount it )and then get fully Access to whole Content of my SSD (sdb) Drive.

To make a long Story short.
So just try the following Fred:

Boot with above Porteus (save on Demand) Boot Option ....insert the copy2ram into Kernel line.....Boot into JWM Desktop place/import/copy -- "some File"--- to ~(root)---save with copy2ram.....look for yourself ..if saved or not......and see what happens.

P.S:
Also when SSD (sdb) Drive not fully mounted ...when using "copy2ram" Option .....no Quick-Remaster is applicable.
Using "copy2ram" Option does work flawless in Fossa-Dog .No save Problems.

.

.

[fredx181]

@backi
Yes, you are right, the partition containing the frugal install is not mounted with the use of copy2ram (it should be when the changes folder is on the same partition , seems like the fix from here viewtopic.php?p=15127#p15127, created another problem.
So... some work to do, not sure yet if and how to fix...
Many thanks for the detailled report !

@Duprate Auto-timezone detection should be activated (but internet connection is required for that), probably something wrong with that, SIGH.. will look at that too in the next days, thanks.

Fred

[Kennel Dweller]

Chances are I have broken something again but this is my 3rd attempt at trying to create the iso.

Screenshot_2021-01-16_14-46-13.png (84.2 KiB) Viewed 888 times

[fredx181]

Chances are I have broken something again but this is my 3rd attempt at trying to create the iso.
Screenshot_2021-01-16_14-46-13.png

Looking at your screenshot, you probably need the "isolinux" package installed, should be installed as dependency at start by the script, but I forgot to add, sorry.

Code: Select all

apt install isolinux

Btw, if all the rest went well, the files required for a frugal install are in bullseye/isodata folder.

Fred

[Kennel Dweller]

You have nothing to be sorry for Fred, this is all a test for a future release and and you sir are a star in my eyes.
That worked perfectly thank you I will install from the iso and see what else I can break.

Screenshot_2021-01-16_22-26-55.png (134.64 KiB) Viewed 894 times

[Duprate]

Is this a trial version? Very good! It's the distro that I adapted to the fastest! Some time ago, I even spoke badly about Debian ... Fred made me change my mind. If I can still reassess my concepts ... it's not all lost for me!

[PipzDex]

Hi Fred
I try your script and explode in my face this error...

Screenshot(1).png (14.79 KiB) Viewed 869 times

I know, i'm not debian and not recent distro puppy but my programs are updated mostly to last version (Frisbee 1.4.9)

What i'm doing wrong or how i can fix this problem

I'm practically a tester of all about puppy are mentioned and learn everyday to help all i can do (that's the reason to try your script)

every comment are good

thanks and cheers!!

[fredx181]

Hi Fred
I try your script and explode in my face this error...

Screenshot(1).png

I know, i'm not debian and not recent distro puppy but my programs are updated mostly to last version (Frisbee 1.4.9)

What i'm doing wrong or how i can fix this problem

I'm practically a tester of all about puppy are mentioned and learn everyday to help all i can do (that's the reason to try your script)

every comment are good

thanks and cheers!!

The connection check depends on curl, do you have it installed? (probably yes, it's installed by default on most systems).
As I wrote in first post it's recommended to run from a Debian based system (although it may work on Puppy too with correct dependencies installed).
If you do have curl, there's a chance that trying again may work, if not, the check code seems not as reliable as I thought it was.
I think in next update I'll make it just as a warning message, so that it will continue then.

@backi and @Duprate
Still working on the issues you mentioned (copy2ram and hardwareclock/timezone), these are hard nuts to crack!
But probably will get there in time.

Fred

[backi]

Hi Fred !
I am not in a hurry ......so ....Don't PANIC !

Best Wishes !

[Duprate]

It worked well for me. When I created the ISO using Fred's script, I was using the DebianDog Bullseye, version of 27 November 2020. Testing and reporting is important, to help the developer. So we show that we value your work.

[rcrsn51]

Still working on the issues you mentioned (copy2ram and hardwareclock/timezone), these are hard nuts to crack!

Duprate's three-hour time difference suggests a problem with setting UTC vs LOCAL in /etc/adjtime.

[backi]

So we show that we value your work

Yes.....Fully agree..he really rocks .....he`s "The Man" .

[fredx181]

Still working on the issues you mentioned (copy2ram and hardwareclock/timezone), these are hard nuts to crack!

Duprate's three-hour time difference suggests a problem with setting UTC vs LOCAL in /etc/adjtime.

The file /etc/adjtime may not exist in Bullseye (it doesn't for me when doing a new build), but you can create it (and set to LOCAL):

Code: Select all

hwclock --localtime --adjust

@Duprate , can you try that and see if it solves your problem?

Fred

[rcrsn51]

The Bullseye Starter Kit has the file /etc/adjtime. It appears to be auto-created by the script /etc/init.d/hwclock.sh

[fredx181]

The Bullseye Starter Kit has the file /etc/adjtime. It appears to be auto-created by the script /etc/init.d/hwclock.sh

Can you check if the attached hwclock.sh is the same as yours ?
I see nothing inside that creates /etc/adjtime. And just made a new build, and no /etc/adjtime included.
Btw, what I'm missing is that it looks for HWCLOCKACCESS=... in /etc/default/hwclock
In Stretch and Buster, it was possible to completely disable touching the hardwareclock by setting it to HWCLOCKACCESS=no

Fred

[rcrsn51]

Here is my hwclock.sh.

BTW, I avoid this kind of problem by using PeasyClock to set the date/time.

[fredx181]

Here is my hwclock.sh.

BTW, I avoid this kind of problem by using PeasyClock to set the date/time.

Yours is very different, same as it was on Buster.
hwclock.sh is part of util-linux, I guess they made the change in the most recent package...

Fred

[rcrsn51]

hwclock.sh is part of util-linux, I guess they made the change in the most recent package...

Confirmed. However, I can still use PeasyClock to switch between UTF and LOCAL, and my /etc/adjtime file still appears to be doing something.

Code: Select all

0.000000 1610906721 0.000000
1610906721
UTC

[rcrsn51]

I am now using the newest util-linux package. I deleted my old /etc/adjtime file and rebooted. Something re-created it and it is still working OK.

[Duprate]

Hi Fred! It took me a long time to answer. I wanted to give you a real answer.
1st - Reported problem - "blank screen time". Her suggestion worked perfectly. In /root/.xsession-openbox, the modified text:
#! / bin / sh
setxkbmap -option terminate: ctrl_alt_bksp &
sleep 2
/ usr / local / bin / start-up &
export SESSION_MANAGER = / usr / bin / x-session-manager
xset s blank
xset s 9000
exec $ SESSION_MANAGER

2nd - Reported problem - "the damn watch". Reflecting on what you suggested, I ended up fixing it like this:

I copied the /etc/init.d/hwclock.sh file and the adjtime, localtime and timezone files in / etc from the filesystem.squashfs of the DebianDog Bullseye of 27 Nov 2020 and transferred them to the appropriate places in filesystem.squashfs of the DebianDog Bullseye of Jan 2021.

IT WORKED! ALL PROBLEMS SOLVED!

Thanks a lot for the help!

[fredx181]

....
I copied the /etc/init.d/hwclock.sh file and the adjtime, localtime and timezone files in / etc from the filesystem.squashfs of the DebianDog Bullseye of 27 Nov 2020 and transferred them to the appropriate places in filesystem.squashfs of the DebianDog Bullseye of Jan 2021.

IT WORKED! ALL PROBLEMS SOLVED!

Thanks a lot for the help!

Great!
For info,
Your (older) version of /etc/init.d/hwclock.sh probably disables touching the hardware clock (if HWCLOCKACCESS=no is set in /etc/default/hwclock)
/etc/init.d/hwclock.sh is part of package util-linux, if you do NOT upgrade util-linux in the future, it stays the same, but if you do upgrade it, the mechanism of disabling touching the hardware clock will be lost (because new /etc/init.d/hwclock.sh is very different).

Fred

[fredx181]

*** Updated mklive-bullseye ***
(new attached at first post)

Fixed that when using copy2ram the partition containing save wasn't mounted. When no save in use, the "boot" partition is unmounted with copy2ram.
See backi's report here: viewtopic.php?p=15216#p15216
And when network connection check says failed (it might happen sometimes while there IS in fact a network connection), the script doesn't exit, just a warning now.

When doing a new build, the above changes will be applied, to apply for an existing build will be a bit complicated (but probably no need if you don't use copy2ram), anyway for who is interested:
Some details about the changes required for the fix (not only modified the mklive-bullseye script):
- Changed dog-boot-bullseye-20201130.tar.gz to dog-boot-bullseye-20210118.tar.gz
(to be extracted in the chroot) change is modified "mountlink" script.
- Changed initrdport-bullseye.tar.gz (modified linuxrc, the init script for in initrd1.xz)
In repository:
- Updated "upgrade-kernel" to v1.1.0 (with modified linuxrc in /usr/local/cr-initrd/initramfs/)
- Updated "debdogmountscripts" to v1.0.7 (modified "mountlink" script)

Fred

[Duprate]

Hi Fred! I used the mklive-bullseye script (18Jan2021). The ISO was created successfully.
I would like to ask: I missed the network_tray.sh in / usr / bin and the icon on the tray. It was just a curiosity, about the peasywifi ...
Also in the menu, I didn't see the "Repository Configuration" icon anymore ... Is the program no longer needed?