Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Thu 19 Sep 2019, 08:39
All times are UTC - 4
 Forum index » Advanced Topics » Puppy Projects
FirstRib default WeeDog Linux build system
Moderators: Flash, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 33 of 36 [540 Posts]   Goto page: Previous 1, 2, 3, ..., 31, 32, 33, 34, 35, 36 Next
Author Message
wiak

Joined: 11 Dec 2007
Posts: 1719
Location: not Bulgaria

PostPosted: Tue 10 Sep 2019, 01:15    Post subject:  

rufwoof wrote:
If you look at the isomaster script in my firstrib00.plug that pulls down the source code for isomaster and compiles that. Not a great example, but works. I also remove gcc and make afterwards as once compiled they're no longer needed (in the clearxbpscache script).


It is a useful example that one though. Both techniques could be rewarding though of course I also want to learn the xbps-src approach.

wiak

_________________
Tiny Linux Blog: http://www.tinylinux.info/
Check Firmware: www.murga-linux.com/puppy/viewtopic.php?p=1022797
tinycore/slitaz: http://www.murga-linux.com/puppy/viewtopic.php?p=990130#990130
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 1719
Location: not Bulgaria

PostPosted: Tue 10 Sep 2019, 01:29    Post subject:  

rufwoof wrote:
In that zramctl line the --find has it find and use the next available free device (so that will be /dev/zram0), the streams sets the number of compression streams the device is allocated which typically you want to set to the number of cores you have; The size sets the size of the virtual device and the algorithm sets the compression method to use.


Nice report on zram performance etc, thanks.

Yes, as you know, you can alternatively adjust all the zram parameters via /sys/block/zramX files as described:

https://www.kernel.org/doc/html/latest/admin-guide/blockdev/zram.html

Quote:
Note that zram uses about 0.1% of the size of the disk when not in use so a huge zram is wasteful.


However, zramctl is part of util-linux and since that is usually installed as part of main root filesystem anyway, that becomes a much more convenient method of adjustinging zram operation.

Like I mentioned, when using copy2ram the files copied in also get temp stored in cache/buffers (which system later frees up automatically or can be released immediately with command: sync && echo 3 >/proc/sys/vm/drop_caches).

EDIT: I notice that there is a void linux template for managing zram swap space (once util-linux and several other dependencies are installed):

https://github.com/atweiden/zramen

Related bash script: https://github.com/atweiden/zramen/blob/master/zramen

Installation:

Code:
xbps-install zramen


wiak

_________________
Tiny Linux Blog: http://www.tinylinux.info/
Check Firmware: www.murga-linux.com/puppy/viewtopic.php?p=1022797
tinycore/slitaz: http://www.murga-linux.com/puppy/viewtopic.php?p=990130#990130

Last edited by wiak on Tue 10 Sep 2019, 04:49; edited 2 times in total
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 1719
Location: not Bulgaria

PostPosted: Tue 10 Sep 2019, 02:13    Post subject:  

Since Void is a rolling distro, I feel that most firstrib00.plug files for FirstRib void builds would sensibly:

Code:
rm -rf "/var/cache/xbps/*" 2>/dev/null


to save some space since most cached install files will grow old as Void updates. In fact the whole of /var/cache/* could likely be safely removed.

Okay, relaxing evening so just opening browser page...: https://wiki.voidlinux.org/Xbps-src

EDIT: I'm planning to follow how to use xbps-src from within a chroot of firstrib_rootfs (via ./mount_chrootverXXX.sh) that contains install of base-devel template, and git, amongst other base bits and pieces.

I presume no bugs have been discovered as yet in the newest build_weedog_initramfs05 script? It has worked fine on all I have tried, but I only tried a few of the option combinations (one thing I'm not sure of, since not looked/tried that for a long time) is the hybrid builds code (i.e. using say BionicPup kernel and 00firstrib_firmware_modules.sfs) - not so important for me since I prefer using default Void components but I'd still like to have that option available since handy for making smaller systems (since Puppy kernels have so many module drivers inbuilt).

wiak

_________________
Tiny Linux Blog: http://www.tinylinux.info/
Check Firmware: www.murga-linux.com/puppy/viewtopic.php?p=1022797
tinycore/slitaz: http://www.murga-linux.com/puppy/viewtopic.php?p=990130#990130
Back to top
View user's profile Send private message 
rockedge


Joined: 11 Apr 2012
Posts: 1230
Location: Connecticut, United States

PostPosted: Tue 10 Sep 2019, 08:39    Post subject:  

Quote:
I presume no bugs have been discovered as yet in the newest build_weedog_initramfs05 script?


ran it multiple times testing my firstrib00.plug and booted fine and ran almost 100% the build zoneminder script as well.

I am seeing good overall performance and low cpu loads and temps....

my latest version of the desktop includes retrovol and pmcputemp which really gives the desktop a familiar look. These I am downloading from my host server prepared as tar.gz from the PET file versions with wget

-
Back to top
View user's profile Send private message Visit poster's website 
rufwoof


Joined: 24 Feb 2014
Posts: 3440

PostPosted: Tue 10 Sep 2019, 08:53    Post subject:  

Hitting problems with building a void kernel based build. Looks like for whatever reason its pulling down two kernels, both a 4 series and a 5 series. build_weedog.... script then fails around the kernel1 test line as that does a ls for firstrib/boot/vmlinuz* and then tests existence of that, but is comparing a ls output of two files ... and fails.

EDIT: Ah! Looks like the 5 series is now the voidlinux --current, and I was specifically xbps-install linux4.19 as part of my build script. Changing that to just linux (meta package) should fix it.

_________________
( ͡° ͜ʖ ͡°) :wq
Fatdog multi-session usb

echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 1719
Location: not Bulgaria

PostPosted: Tue 10 Sep 2019, 17:57    Post subject:  

rufwoof wrote:
Hitting problems with building a void kernel based build. Looks like for whatever reason its pulling down two kernels, both a 4 series and a 5 series. build_weedog.... script then fails around the kernel1 test line as that does a ls for firstrib/boot/vmlinuz* and then tests existence of that, but is comparing a ls output of two files ... and fails.

EDIT: Ah! Looks like the 5 series is now the voidlinux --current, and I was specifically xbps-install linux4.19 as part of my build script. Changing that to just linux (meta package) should fix it.


Yes, as I posted some time back, you maybe missed it and I should draw more attention to the case:

http://www.murga-linux.com/puppy/viewtopic.php?p=1034845&ppage=2000#1034845

wiak 20 Aug wrote:
I then tried:

./build_firstrib_initramfs04_s102.sh kernel=void

and it refuses to do it saying:

Quote:
firstrib_rootfs needs to at least include xbps-install:\nlinuxX.XX, ncurses-base, and linux-firmware-network


But, I know why... there are now two kernels in my firstrib_rootfs: 4.19 (since I had that from before) and 4.14. So I just renamed (mv) the vmlinuz4.19 one to NOvmlinuz4.19 and tried build initramfs kernel=void again, and it has now copied out the 4.14 kernel (as it should) and created the initramfs04.gz for that. I'll try to boot it now and report back...


I could put an extra check in to allow user to chose which kernel they wish to use if more than one. I'll think about that later.

wiak

_________________
Tiny Linux Blog: http://www.tinylinux.info/
Check Firmware: www.murga-linux.com/puppy/viewtopic.php?p=1022797
tinycore/slitaz: http://www.murga-linux.com/puppy/viewtopic.php?p=990130#990130
Back to top
View user's profile Send private message 
rufwoof


Joined: 24 Feb 2014
Posts: 3440

PostPosted: Tue 10 Sep 2019, 18:41    Post subject:  

Did miss that Embarassed Thanks wiak.

I've just move my firstrib00.plug over to google as its grown to a 5MB filesize as I'm including the source code (and binary) for a ncurses front end for tilda. Along with being able to cut and paste easily and click to follow links when using tilda (and navigate using the mouse within mc), that ncurses menu helps pull it together better. That along with skippy and xlunch and the learning curve is relatively light (mostly mc takes the effort to learn). Good for whether you are predominately mouse or predominately keyboard. Once you're familiar with mc its great as its commonly available on servers so 'feels' much the same whether you're running it locally or remotely.

F1 to show/hide toggle tilda
alt-space - show programs (launcher i.e. xlunch) or mouse into top left corner.
win-space - show windows (skippy-xy) or mouse into bottom left corner.
When in mc use mouse (double clicks to open/execute) or keyboard.
In both xlunch or skippy-xd arrow keys to move around, enter to select, or use the mouse and click items.
If you add additional programs, then /etc/xlunch/entries.dsv is the file to edit, three semicolon separated entries per line (program), description (text underneath icon);image file for icon;command to run when selected.

I've stripped down the firstrib00.plug to remove libreoffice, audacity, kdenlive ..etc. as they're easily installed if desired using xbps-install. Having seen how they work now making it optional whether they're installed or not. If you boot and then install, running save.sh adds whatever you install as a 02 (03, 04 ...etc) changes.sfs file. Which is nice as you can opt to load or not those sfs's simply by renaming without the NN numerical prefix filename digits.

In tilda, running demoapp.sh shows the ncurses menu system. That's still a work in progress. Within firstrib00.plug if you extract the scripts then the source for demoapp is contained within a folder alongside the scripts.

As you say, as/when each firstrib00.plug matures, a separate dedicated Puppy forum thread will be appropriate.
s.png
 Description   demoapp.sh ncurses program launcher
 Filesize   16.86 KB
 Viewed   166 Time(s)

s.png


_________________
( ͡° ͜ʖ ͡°) :wq
Fatdog multi-session usb

echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh
Back to top
View user's profile Send private message 
rockedge


Joined: 11 Apr 2012
Posts: 1230
Location: Connecticut, United States

PostPosted: Tue 10 Sep 2019, 21:25    Post subject:  

some more improvements to the firstrib00.plug creating a WeeDog with the latest Void Linux kernel with jwm and rox --pinboard supplying the desktop window and file manager.

firstrib00.plug is here ->
http://murga-linux.com/puppy/viewtopic.php?p=1035969#1035969
2019-09-11-034638_400px.png
 Description   
 Filesize   17.54 KB
 Viewed   137 Time(s)

2019-09-11-034638_400px.png

Back to top
View user's profile Send private message Visit poster's website 
AndresC2

Joined: 08 Jul 2017
Posts: 70

PostPosted: Wed 11 Sep 2019, 00:14    Post subject:  

Hi wiak

build with will haley manual
dell gx240 512 mg ram

run in fat 32

syslinux.cfg

LABEL Debian Buster Runit 4.19.0-5-686
kernel /Buster-runit/live/vmlinuz-4.19.0-5-686
append initrd=/Buster-runit/live/initrd.img-4.19.0-5-686 noprompt boot=live live-media-path=/Buster-runit/live/ union= init=/sbin/runit vga=791 quiet

apt-get install apt-utils whiptail dbus procps --yes && \
dbus-uuidgen > /var/lib/dbus/machine-id

apt-get install linux-image-4.19.0-5-686 --yes

apt-get install live-boot init runit runit-init udhcpc --yes

initrd.img size 23 mb

boot # OK
udhcpc -i eth0 # OK

Buster run Fine

**************************************************************

Important NO live-boot

dell gx240 512 mg ram

./build_firstrib_rootfs_101.sh debian buster i386 firstrib00.plug
./build_weedog_initramfs05_s101.sh debian

firstrib00.plug:

apt-get install apt-utils whiptail dbus procps --yes && \
dbus-uuidgen > /var/lib/dbus/machine-id

apt-get install linux-image-4.19.0-5-686 --yes

apt-get install init runit runit-init busybox udhcpc --yes

run in fat 32

syslinux.cfg

LABEL WeeDog Debian 4.19.0-5-686
kernel /WeeDog/vmlinuz-4.19.0-5-686 usbwait=15 bootfrom=/mnt/sdb1/WeeDog changes=RAM
initrd /WeeDog/initramfs05.gz

vmlinuz-4.19.0-5-686 # OK
initramfs05.gz # Ok but size is huge 50 mb and slow loading

boot Kernel panic! after usbwait=15

I try several times usbwait=60 but Kernel panic!

maybe initramfs05.gz 50 mb fill all my 512 ram

Please try the same in fat 32 with debian buster

very cool Projects Wiak

thanks!
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 1719
Location: not Bulgaria

PostPosted: Wed 11 Sep 2019, 00:32    Post subject:  

AndresC2 wrote:
vmlinuz-4.19.0-5-686 # OK
initramfs05.gz # Ok but size is huge 50 mb and slow loading

boot Kernel panic! after usbwait=15

I try several times usbwait=60 but Kernel panic!

maybe initramfs05.gz 50 mb fill all my 512 ram

Please try the same in fat 32 with debian buster

very cool Projects Wiak

thanks!


Hi AndresC2, nice and interesting attempt. I've lost touch with debian, and busy with Void Linux since that's my main interest at the moment, but good you tried this, despite not working on your system. I will keep this example in mind and try it sometime though. In debiandogs (which is all I know about Debian-wise) the initramfs is only smaller (I've looked) because the modules are internally not 'individually' compressed at all but the whole set of them are then heavily compressed resulting in quite a small initramfs. That heavy compression doesn't work if the individual modules are themselves already compressed.

However, that DD-type small initramfs all has to be uncompressed into space reserved by kernel anyway, so I'm surprised it is any quicker loading in (well...not really surprises since slow disk I/O might be the issue on your machine so small initramfs better speedwise - otherwise, not a major issue) and actually in RAM I'd expect it to take up more space than any WeeDog-created one (since WeeDog keeps any individually compressed modules compressed in RAM whereas, DD method stored them uncompressed in RAM). Anyway, your will haley methods may result in difference I don't know about until testing myself sometime. Or maybe someone else will make WeeDog Buster build attempt beyond what I have started with. You've certainly tempted me to try Wink

and also I'm thinking of producing an example stripped down Void version (i.e. stripped libs, removing docs/man pages/locales etc - just to see how small the end-result actually could be; nice for copy2ram use, but having said that, original iso-size is not particularly important for me and updates will soon bloat system again (though continually stripping docs/man-pages/locales could still be auto-done of course, as in DD).

Yes, I'll try it sometime.

EDIT: Okay, I'm too curious. No one has really tried the Debian build before you Andres (aside from my early check) so I'll give your example a go on my machine using WeeDog method.

EDIT2: Building now. Off the top of my head I'm wondering if this is the problem for you (can maybe solve if so, but have to check):

Quote:
USB: The GX240 uses the Intel 845 chipset (no additional letters). It only has 1.1 support


Cheers,

wiak

_________________
Tiny Linux Blog: http://www.tinylinux.info/
Check Firmware: www.murga-linux.com/puppy/viewtopic.php?p=1022797
tinycore/slitaz: http://www.murga-linux.com/puppy/viewtopic.php?p=990130#990130
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 1719
Location: not Bulgaria

PostPosted: Wed 11 Sep 2019, 08:16    Post subject:  

Hello AndresC2

My machine is HP elitebook 2530p and I currently have 4GB RAM in it (its usb ports are version usb2).
So best I could do was use mem=512M kernel boot parameter to try and simulate 512MB system (but that method is not foolproof...). System booted with WeeDog Debian Buster OK. You will see results from free, uname -a, cat /etc/debian_version, and mount | head -n3, taken after booting below.


Code:
# free
              total        used        free      shared  buff/cache   available
Mem:         507584       32936      384572         904       90076      461032
Swap:             0           0           0

# uname -a
Linux (none) 4.19.0-6-686 #1 SMP Debian 4.19.67-2 (2019-08-28) i686 GNU/Linux

# cat /etc/debian_version
10.1

# mount | head -n3
inram on /mnt/layers/RAM type tmpfs (rw,nosuid,nodev,relatime,size=507584k)
/dev/sdb1 on /mnt/sdb1 type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
overlay_result on / type overlay (rw,relatime,lowerdir=01,upperdir=/mnt/layers/RAM/upper_changes,workdir=/mnt/layers/RAM/work)


As you can see from mount command above, I used usb stick type vfat (fat32) /dev/sdb1.

I also booted using syslinux with syslinux.cfg stanza:

Code:
label WeeDog
kernel /WeeDog/vmlinuz
append initrd=/WeeDog/initramfs05.gz bootfrom=/mnt/sdb1/WeeDog usbwait=12 inram_sz=100% rdsh3 changes=RAM mem=512M


NOTE WELL:

I used latest: build_weedog_initramfs05_s103u.sh to create the initramfs05.gz (which needs that inram_sz=100% put in the syslinux.cfg line as shown). Please always use latest scripts when sending in results if you can. Notice from above syslinux.cfg that I put in a temporary shell break at rdsh3 just so I could check things at that point in the initramfs/init script (exit from there to complete the boot up).

To build the system I used:

Code:
./build_firstrib_rootfs_101.sh debian buster i386 firstrib00.plug

where firstrib00.plug contained:

Code:
apt-get install apt-utils whiptail dbus procps --yes && \
dbus-uuidgen > /var/lib/dbus/machine-id

apt-get install linux-image-4.19.0-6-686 --yes

apt-get install init runit runit-init udhcpc --yes


Note that Debian has changed the kernel revision number.

I forgot to try and set root password in there, so I used ./mount_chrootver007.sh to allow me to use "passwd root" command in that chroot, followed by exit and ./umount_chrootver007.sh.

I then created the initramfs05.gz using command:

Code:
./build_weedog_initramfs05_s103u.sh debian


Once vmlinuz4.19xxxxxx was created I renamed it to vmlinuz (to save me some typing...) and
then copied the three files: vmlinuz, initramfs05.gz and 01firstrib_rootfs.sfs to /mnt/sdb1/WeeDog directory, which as I said had been formatted fat32 and had syslinux put onto it.

Maybe you could try another build with that exact syslinux label and if it reaches the rdsh3 break point okay that will tell us that the initramfs has successfully loaded into RAM. In any case I can then try and help you to get it all to boot successfully, as it has done in my own test above.

I have an older laptop, with around 512MB RAM, lying 'somewhere' gathering dust. I'll try and find it and if I manage I'll check to see if it will boot with same usb stick.

Cheers

wiak

_________________
Tiny Linux Blog: http://www.tinylinux.info/
Check Firmware: www.murga-linux.com/puppy/viewtopic.php?p=1022797
tinycore/slitaz: http://www.murga-linux.com/puppy/viewtopic.php?p=990130#990130
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 1719
Location: not Bulgaria

PostPosted: Wed 11 Sep 2019, 16:24    Post subject:  

Hello again AndresC2,

If the problem is that your laptop only uses usb1.1 protocol it may be that you need to add a module to the big list at line 48 in build_weedog_initramfs05_s103u.sh script, which ends with:

Code:
ehci-pci ohci-hcd uhci-hcd xhci-pci xhci-hcd usb-storage xts uas;do


anywhere in there put in module name: ohci-pci

and modify line 289 from:

Code:
   modprobe -r `lsmod | cut -d' ' -f1 | grep -Ev 'ehci|xhci|sdhci|uas|usbhid'` 2>/dev/null  # keep ehci,xhci,sdhci,uas,usbhid


to

Code:
   modprobe -r `lsmod | cut -d' ' -f1 | grep -Ev 'ehci|xhci|sdhci|uas|usbhid|ohci'` 2>/dev/null


(i.e. added |ohci to the list of modules not to remove).

and then do a new run of ./build_weedog_initramfs05_s103u.sh debian

Note that if this work, you can save some RAM in the end by rebuilding again later but removing ehci|xhci|uas and probably usbhid from that modules remove list since these modules probably aren't needed for usb1.1 (I'd have to check)

Cheers, wiak

_________________
Tiny Linux Blog: http://www.tinylinux.info/
Check Firmware: www.murga-linux.com/puppy/viewtopic.php?p=1022797
tinycore/slitaz: http://www.murga-linux.com/puppy/viewtopic.php?p=990130#990130
Back to top
View user's profile Send private message 
AndresC2

Joined: 08 Jul 2017
Posts: 70

PostPosted: Wed 11 Sep 2019, 19:37    Post subject:  

HI wiak

rdsh3 load fine

bootfrom is /mnt/sdb1/WeeDog etc...

then tipe exit but kernel panic

later try your fix ohci-pci in new build

but kernel panic

my pc dell gx240 usb1.1 year 2000, too old i guess.

thank you wiak for all

see you Smile
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 1719
Location: not Bulgaria

PostPosted: Wed 11 Sep 2019, 20:58    Post subject:  

AndresC2 wrote:
HI wiak

rdsh3 load fine

bootfrom is /mnt/sdb1/WeeDog etc...

then tipe exit but kernel panic

later try your fix ohci-pci in new build

but kernel panic

my pc dell gx240 usb1.1 year 2000, too old i guess


Well, no, AndresC2... since rdsh3 loaded fine that means initramfs/init started fine and kernel thus loaded fine. Only issue is the real root filesystem not loading correctly at the switch_root. Since you said will haley install did boot fine, then so should WeeDog - almost sure to simply be a module still needing loaded since boots fine on my own system so everything else (runit etc) working fine.

One last thing I suggest to try, if you wish, is to simply create a blank file called modules_remove.plug and put that in directory /mnt/sdb1/WeeDog and then try booting again. The effect of that blank file is that it tells the WeeDog initramfs/init script not to remove ANY of the early-loaded modules, hence if module missing is in the initramfs/init list then it will be loaded. If that works can later find out which module needs kept (since loading them all does use more RAM). But certainly, from you report about will haley method then WeeDog would certainly work on your old Dell (and work well since it uses less RAM and runs more efficiently than most alternative systems I've tested against.

Anyway, I'll run it on an old machine of my own (older than yours probably) and report back once I've tried that - personally I'm sure I can get it to work okay.

EDIT: Actually, when it is booted with will haley tutorial method, if you open a terminal and type command lsmod, you should be able to see which modules (relating to usb boot) that are being used, and then you just need to make sure same is available and loading in WeeDog. Anyway, up to you what you want to try or not! Smile The other thing to try, from your will haley configured boot are the commands: lsusb and lspci -v (not the busybox ones but util-linux (I think) ones - they will tell you what kernel drivers are being used/needed by your usb port. By the way, rdsh3 breakpoint should include message that is the result of the following initramfs/init script code:

Code:
echo -e "\e[95mbootfrom is $bootfrom\e[0m" >/dev/console
echo -e "\e[95mmountfrom is $mountfrom\e[0m" >/dev/console
echo -e "\e[95mlower is $lower\e[0m" >/dev/console
echo -e "\e[95mupper_work is ${upper_work:-readonly}\e[0m" >/dev/console


If all is well at that stage, you should see message:

bootfrom is /mnt/sdb1/WeeDog
mountfrom is /mnt/sdb1/WeeDog

and most important:

lower is 01

and check that there is no error message about init not being able to mount something. If all the above is fine, then should be easy to fix. If the 01 is missing then the initramfs/init hasn't been able to find 01firstrib_rootfs.sfs and the overlay merged result won't be correct so kernel panic will definitely happen... that would be the case if module to see the usb stick isn't loaded...

EDIT2: I think the module you need is probably the old module uhci-hcd, that is already in the main module list (hence your boot gets to rdsh3 okay) but then it gets auto-removed thereafter (hence kernel panic at switch-root). You can fix by adding uhci to the modprobe -r line as follows:

Code:
modprobe -r `lsmod | cut -d' ' -f1 | grep -Ev 'ehci|xhci|sdhci|uas|usbhid|ohci|uhci'` 2>/dev/null


But you don't need to rebuild. That line can just be put in the file modules_remove.plug since whatever is in there gets used instead of what the buildscript puts into initramfs/init. So first try an empty modules_remove.plug as I previously suggested, and if that works, try putting the above line in there, and rebooting. If that works, you can save further RAM probably by shortening it to not include modules not needed, to:

Code:
modprobe -r `lsmod | cut -d' ' -f1 | grep -Ev 'sdhci|uhci'` 2>/dev/null


And you only need sdhci if you are planning to boot from sd card as an alternative...

wiak

_________________
Tiny Linux Blog: http://www.tinylinux.info/
Check Firmware: www.murga-linux.com/puppy/viewtopic.php?p=1022797
tinycore/slitaz: http://www.murga-linux.com/puppy/viewtopic.php?p=990130#990130
Back to top
View user's profile Send private message 
AndresC2

Joined: 08 Jul 2017
Posts: 70

PostPosted: Thu 12 Sep 2019, 01:01    Post subject:  

Hi Wiak Very Happy

Can you see lsmod-lspci-lsusb.log first

and later I apply the fix

thanks wiak
lsmod-lspci-lsusb.log.gz
Description  remove gz
gz

 Download 
Filename  lsmod-lspci-lsusb.log.gz 
Filesize  2.11 KB 
Downloaded  3 Time(s) 
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 33 of 36 [540 Posts]   Goto page: Previous 1, 2, 3, ..., 31, 32, 33, 34, 35, 36 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Puppy Projects
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1889s ][ Queries: 13 (0.0701s) ][ GZIP on ]