Puppy Linux Discussion Forum

fredx181 wrote: ↑Sun Dec 27, 2020 4:53 pm

Yes, v1.0.4 from Sid Dog repo:
https://github.com/doglinux/sidog/raw/m ... .4_all.deb

Thanks. That worked with one small problem.

On the first boot, it stops at the prompt and can't find any hardware. But when I run

depmod -a
modprobe i915 r8169
startx

it starts up OK and is good on subsequent boots.

Can I put this depmod command somewhere in the mkinitrd process? Or is this a quirk of this "trunk" kernel. I didn't have the problem with your "-rc6" kernel.

[Edit] I fixed this by using "depmod -b" as part of building the kernel squashfs module.

I was also able to build a mini-devx out of the Experimental repo that works fine.

Bill

Hi Bill, nothing special I needed to do with the rc6 kernel from Experimental, so could indeed be a quirk of the "trunk" kernel.

On the first boot, it stops at the prompt and can't find any hardware. But when I run

Code: Select all

depmod -a
modprobe i915 r8169
startx

I guess that's at the login stage ?

[Edit] I fixed this by using "depmod -b" as part of building the kernel squashfs module.

What exactly you did then before creating .squashfs ?
EDIT: The way I did was install the kernel by "dpkg -i <linux-image>.deb", then ran the mkinitrd script by pointing to the kernel and made squashfs from /libmodules/<kernel>, maybe you did different.

Fred

When I'm building the squashfs module for the kernel, I have a folder named k-5.10.0-trunk-amd64/.

Inside, it has /lib/modules/5.10.0-trunk-amd64/kernel with all the kernel stuff.
There are also some files in /lib/modules/5.10.0-trunk-amd64/, but it's missing the file modules.dep.

So I ran: depmod -b k-5.10.0-trunk-amd64 5.10.0-trunk-amd64 # the target directory and the target kernel name
That created the missing files.
Then I squashed it.

[Edit] I did it again with "dpkg -i" and the missing files showed up automatically.

Hi Fred:

This 5.10.0-trunk-amd64 kernel is working fine now that I understand the procedure. I have combined it with an 01-filesystem.squashfs from Buster and my-squash-loader. For my needs, this completely replaces all the aufs-related stuff.

I even got a live-boot-3 bootup to work just by removing "union=aufs" from the GRUB menu.

I can't see the point of hand-compiling kernels anymore when you can get ready-made versions built by experts. And making a mini-devx is routine - it's just a matter of determining which repos to enable.

Thanks.

Hello, Fred! Now, I am more familiar with DebianDog and do some experiments! Just to let you know: the FatDog 32-bit compatibility package works well on DebianDog. I made a combination with Wine and it resulted in this:

32bit-fd64_811.sfs + Wine-3.3-V.2.1 = 07-wine32.squashfs

Now with DebianDog, I can do everything I do with FatDog64. Windows programs: games, PortableApps, PhotoShop, Stellarium; Linux programs: LibreOffice, Gimp, Vivaldi 3.5.2115.81, Firefox 84.0.1 and Seamonkey 2.53.5.1 (with sound). I removed Firefox ESR. I have not yet installed Clamav-0.103.0.

Your work was great and I feel at home! Thank you!
I wish you a happy New Year!

Thanks Bill & Duprate, good to hear !
Best wishes for 2021 !

Fred

Hello people, recently I've switched from DogStretch to this DogSid.
Everything works fine, just one minor thing: this PC (Acer Aspire 3950) has two disks, well one it's not a disk, it's an SSD.
The thing is that, across different boots, one day the SSD is in /dev/sda but next day can be in /dev/sdb. Something that didn't happen with DogStretch.

Not a big deal really, but I'd like to always have the SSD as /dev/sda.

I have read about it, but what I found it's too much complicated, Is there a simple way to fix the SSD to sda?

I've added root=PARTUUID=3abe9eh5-01 to the kernel line in menu.lst, but doesn't work.

Any idea?

Thnx and Happy New Year !!!

galbi wrote: ↑Wed Dec 30, 2020 3:50 pm

Hello people, recently I've switched from DogStretch to this DogSid.
Everything works fine, just one minor thing: this PC (Acer Aspire 3950) has two disks, well one it's not a disk, it's an SSD.
The thing is that, across different boots, one day the SSD is in /dev/sda but next day can be in /dev/sdb. Something that didn't happen with DogStretch.

Does your Sid system not have the directory /dev/disk/by-uuid?

Then check in /lib/udev/rules.d. Is there a file named xx-persistent-storage-rules?

Finally, check that udev is running with the command: /etc/init.d/udev status

rcrsn51 wrote: ↑Wed Dec 30, 2020 4:22 pm

Does your Sid system not have the directory /dev/disk/by-uuid?

Then check in /lib/udev/rules.d. Is there a file named xx-persistent-storage-rules?

Finally, check that udev is running with the command: /etc/init.d/udev status

Thanks for answering.
1 - Yes
2 - Yes
3 - udevd is running.

Not sure what to do next.

In /dev/disk/by-uuid, are there entries for both drives?

If you right-click on the links and check Properties, do the links point to the correct drives sda/sdb?

Maybe the solution will be to use /etc/fstab, which I know nothing about.

rcrsn51 wrote: ↑Wed Dec 30, 2020 8:50 pm

In /dev/disk/by-uuid, are there entries for both drives?

If you right-click on the links and check Properties, do the links point to the correct drives sda/sdb?

Again,
- Yes
- Yes

Later, with time, I'll boot DogStretch and compare to see if something gives any clue.

galbi wrote:

Everything works fine, just one minor thing: this PC (Acer Aspire 3950) has two disks, well one it's not a disk, it's an SSD.
The thing is that, across different boots, one day the SSD is in /dev/sda but next day can be in /dev/sdb. Something that didn't happen with DogStretch.

Similar problem I have (on Buster and Sid), when booting from hard-disk and have an USB drive plugged in, the USB shows as sda and my hard-disk as sdb.
Same as for you, with Stretch that didn't happen.
Did a test by booting Busterdog with the Stretch kernel (4.9) (and the USB plugged in) and it was fine (hard-disk being sda).
So, I'd say that it should be because of the newer kernel that this problem occurs.
A quick websearch showed me that it should be possible to have a disk permanently assigned to sda, by creating a udev rule, but that's complicated stuff...

Fred

I have a DELL INSPIRON E1505 that will attempt to boot a USB drive if plugged in at machine start up. The hard drive is second in the boot order. In the case of the USB drive being plugged in, the USB will be assigned sda1 and the HDD sdb1.
If I switch the boot order in the BIOS settings to allow the HDD to be the default boot device, the order is HDD = sda1 and the USB drive sdb1. Even in this case the USB can be booted by pressing F12 during the boot cycle to reach the boot manager.

Hello, Fred! I downloaded "DebianDog-Bullseye-20201127-overlay_amd64-UEFI.iso".
I noticed that his filesystem.squashfs is smaller (less 91Mb) than that of "DebianDog-Sid-full-20201125-overlay_amd64-UEFI.iso".
So, I replaced the filesystem for the "DebianDog-Sid" installation with the "DebianDog-Bullseye". As it worked perfectly at first, I would like to know your opinion about the exchange. It is my compulsion for new experiments, which can be reversed easily ...

Duprate wrote: ↑Fri Jan 01, 2021 9:41 pm

Hello, Fred! I downloaded "DebianDog-Bullseye-20201127-overlay_amd64-UEFI.iso".
I noticed that his filesystem.squashfs is smaller (less 91Mb) than that of "DebianDog-Sid-full-20201125-overlay_amd64-UEFI.iso".
So, I replaced the filesystem for the "DebianDog-Sid" installation with the "DebianDog-Bullseye". As it worked perfectly at first, I would like to know your opinion about the exchange. It is my compulsion for new experiments, which can be reversed easily ...

They are practically the same because -at this point in time- Sid(unstable) and Bullseye(testing) have almost the same software versions (Sid just a little newer in most cases).
That will change when Bullseye becomes the new "stable" (probably this summer), then they will grow apart (Sid evolving, as a rolling release, and Bullseye more like "static").
So, upgrading packages frequently in Bullseye will lead in time that you are in fact running "stable" instead of "testing" (what it is now).
More about "testing" here: https://wiki.debian.org/DebianTesting

Fred

Thank you Fred! You are a good developer, responding to users and meeting their expectations ... Succeed in your work!

Fixed a bug in the loadmodule script. New attachment and info (see EDIT 2021-01-06) here: viewtopic.php?p=11354#p11354
Newest .deb package sfsload v1.0.8: https://github.com/doglinux/sidog/raw/m ... .8_all.deb
Should have tested better earlier , but did now.

Fred

how to install driver for Radeon R7 370 or R9 270-370?

Please describe your problem. Are you getting any video at all? Can you get to the desktop? Do you want to install a driver with better performance?

Default monitor setting 1920x1080, but just way too big for my monitor.
There are two alternative resolutions 1360x768 and 640x480. By choosing either one the color change to 8 bit (blurred).

I am late to the party but running this on the above Lapop. Running beautifully - thanks Fred.

*** DebianDog Sid Build Script and Appimages ***

Instead of updating everytime DebianDog Sid I thought it would be nice to share a script to self build it.
Download, see First Post
Modified from Bullseye build script viewtopic.php?p=14736#p14736, Bullseye will become 'stable' soon (now still Debian 'testing' branch) .
Sid will stay forever Sid 'unstable' branch being a rolling release.

Fred

Fred, was hoping that a sid build script might eventuate. Thank you.

Updated packages (for Sid too):
viewtopic.php?p=24980#p24980

Hi Fred
all works fine (XFCE). Happy to have it now. Now experimenting. Found out that for my Asus system I can use the firmware from Stretch Dog, which is only 4,5 MB.
Thank You so much for the work you have invested to create Debian Dog SID.

Have a nice fathers (Ascension) day.

Payoon

*** Updated mklive-sid ***
Re-attached at first post.
Info: viewtopic.php?p=26114#p26114

*** Sfs-Load 'on-the-fly' continued ***

Continue from here: viewtopic.php?p=11354#p11354

Did some more exploring the possibilities loading sfs module using symlinks.
I wasn't really satisfied with the way it's loading: symlinking from a read-only source. (.squashfs module mounted RO)
It would be much better IMO if the symlinking is done from a writable source, so then e.g. a program or the user can modify files that are included in the SFS module. For example config files or update files/binaries.
So after mounting the .squashfs (RO), make (by using overlay) extra mountpoint <module-mnt-RW> read-write, being the source to symlink from: (and make upperdir= <modified-files-write>)
Something like:
mount -t overlay -o lowerdir=<module-mnt-RO>,upperdir=<modified-files-write>,workdir=work overl <module-mnt-RW>
For Info; the mountpoints should be in a tmpfs location, it will fail if on e.g. /, /mnt or /media.
Where <module-mnt-RO> is the read-only mountpoint from the .squashfs, <module-mnt-RW> is read-write.
In <modified-files-write> come only the files that are (possibly) modified, to be moved to the system at de-activating the module.
De-activating may be a bit slower, depending on the amount of files in <modified-files-write>

As I see it, this way it's more close to the situation when the module is already activated at boot (by placing it in the "live" folder)
(and more close to previous method using "aufs" in e.g. Stretch and Buster)

Probably later I will update sfsload to v2.0.0 in the repository, now for testing sfsload_2.0.0_all.deb including this change in "NoRepo" (for Bullseye and Sid):
https://github.com/doglinux/bulldog/raw ... .0_all.deb

EDIT: Added now sfsload_2.0.0 to the repositories for Bullseye and Sid, along with updated versions of the packages "porteusbootscripts" and "quick-remaster".

Fred

Hi folks
after updating and upgrading dd-bullseye and rebooting I made a module from changes and copied it to the live folder During that module making I get "Access to /mnt/sda1/mychanges/var/cache/apt/lists not possible file or directory not found".
After rebboting without changes and testing with <apt update> again, I found that dd-bullseye wants to upgrade the same files again. That means the before updated and upgraded files are not included in the changes.squashfs file.The odd thing is that any program that I have additionally installed with synaptic e.g. isomaster are properly installed. When I return to booting with changes and do apt update dd-bullseye tells my I am up to date and all the formerly upgraded files are there.
Can anyone explain this?

P.S. sorry I mistakenly posted in dd-sid. It was supposed for dd-bullseye, but all the above is the same for dd-sid also

Payoon wrote: ↑Fri Jun 18, 2021 5:42 am

Hi folks
after updating and upgrading dd-bullseye and rebooting I made a module from changes and copied it to the live folder During that module making I get "Access to /mnt/sda1/mychanges/var/cache/apt/lists not possible file or directory not found".
After rebboting without changes and testing with <apt update> again, I found that dd-bullseye wants to upgrade the same files again. That means the before updated and upgraded files are not included in the changes.squashfs file.The odd thing is that any program that I have additionally installed with synaptic e.g. isomaster are properly installed. When I return to booting with changes and do apt update dd-bullseye tells my I am up to date and all the formerly upgraded files are there.
Can anyone explain this?

Hi Payoon, it looks like you ran it with "Disable dpkg registration" checked (default).
If so:
That way the package management doesn't "know" about the upgrading/installing you've done (but the new files from the upgrades are probably there).
You may want to run it again with unchecked "Disable dpkg registration" but that can be tricky, see the info about dpkg registration (click button).
EDIT: Personally I wouldn't like to use it for changes that contain software upgrades/additions, more for manual configuration changes, e.g. wallpaper change or any other simple user changes, otherwise remastering is the better way IMHO .

Fred

Hi Fred ,
thanks for the quick response. Every day a new lesson. I will do as You recommended and experiment a little bit.

P.S. Problem was solved by above answer.