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 Sat 14 Dec 2019, 23:41
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 19 of 49 [722 Posts]   Goto page: Previous 1, 2, 3, ..., 17, 18, 19, 20, 21, ..., 47, 48, 49 Next
Author Message
wiak

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

PostPosted: Fri 16 Aug 2019, 04:54    Post subject:  

rufwoof wrote:
I did do one run where .plug included installation of xorg, chromium ...etc. straight off, but that resulted in a .sfs file of nearly 1GB that wouldn't boot.


But this is odd. I have just attempted to repeat same installation (though I ran out of space during creation of 01firstrib_rootfs.sfs) and can confirm switch_root causing kernel panic (I used uncompressed 01firstrib_rootfs since I didn't have the sfs). I am looking into the issue at this exact moment.

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: 1842
Location: not Bulgaria

PostPosted: Fri 16 Aug 2019, 07:20    Post subject:  

@rufwoof: If I'm correct that test above that failed with large 01firstrib_rootfs.sfs was on a usb drive? Could you please confirm that?

The successful chromium test you did was on hard drive from what you write. I have found bug on similar test, but on usb stick boot only (all booted fine when same files on my hard drive instead) where my simple routine for removing modules to save memory has proved to be a bit too aggressive (I need to tell it not to remove module ehci_pci, which usb stick needs but is not being marked as in active use somehow - hence able to be removed). At the moment, simple workaround for me will be to have simple list of modules I definitely don't want moved (currently being that ehci_pic module, but there may be one or two other modules related to SD card booting I have to definitely force keep).

EDIT: testing my workaround/fix now.

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 Fri 16 Aug 2019, 08:46; edited 1 time in total
Back to top
View user's profile Send private message 
rockedge


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

PostPosted: Fri 16 Aug 2019, 07:44    Post subject:  

I am getting a kernel panic and have not yet built a successful system using model s100.

working on using the Void kernel with this build because up to now I have been using the Bionic kernels
Back to top
View user's profile Send private message Visit poster's website 
wiak

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

PostPosted: Fri 16 Aug 2019, 09:27    Post subject:  

rockedge wrote:
I am getting a kernel panic and have not yet built a successful system using model s100.

working on using the Void kernel with this build because up to now I have been using the Bionic kernels


Is this with a usb connected drive of some sort? If so, which sort. Problem is probably the one I am addressing with bug-fix this very moment.

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: 3681

PostPosted: Fri 16 Aug 2019, 09:28    Post subject:  

wiak wrote:
@rufwoof: If I'm correct that test above that failed with large 01firstrib_rootfs.sfs was on a usb drive? Could you please confirm that?

No. My hdd is pretty much empty so I've been using that as the test-bed (installed grub4dos to boot - where my otherwise usb based regular desktop boot usb isn't connected (BIOS set to boot usb before hdd)).

_________________
( ͡° ͜ʖ ͡°) :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: 1842
Location: not Bulgaria

PostPosted: Fri 16 Aug 2019, 09:52    Post subject:  

rufwoof wrote:
wiak wrote:
@rufwoof: If I'm correct that test above that failed with large 01firstrib_rootfs.sfs was on a usb drive? Could you please confirm that?

No. My hdd is pretty much empty so I've been using that as the test-bed (installed grub4dos to boot - where my otherwise usb based regular desktop boot usb isn't connected (BIOS set to boot usb before hdd)).


@rockedge and rufwoof:

Could you try with Revision s101, which I've just uploaded. It fixes the kernel panic issue on my machine - but that panic was only happening for usb boot on my machine - booting from my ata harddrive was fine. My test was with your (rufwoof) big chromium build all built at once into big 01firstrib_rootfs.

Even if that doesn't work on your machine, I've now included a modules_remove.plug plugin that can be altered to address alternative issues of this sort. Late here now though, so I have to go, but please send in feedback to see is all okay now, and if not, try and find out what driver/module your boot media needs and we can fix it from that info tomorrow.

EDIT: Even if issue on your machine is different than it was on mine, you may be able to sort it out with modules_remove.plug inbetween times anyway if you check how the relevant code used (extract below) works (note how I now, in Revision s101, prevent modules name-matching ehci, xhci and sdhci being removed - same could be done for any module regular expression match):

Code:
if [ -s "\${mountfrom}"/modules_remove.plug ]; then  # source modules_remove plugin
   . "\${mountfrom}"/modules_remove.plug
else
   # Remove unused modules to save memory
   modprobe -r \`lsmod | cut -d' ' -f1 | grep -Ev 'ehci|xhci|sdhci'\` 2>/dev/null  # keep ehci,xhci,sdhci
fi


To be honest, rufwoof, it doesn't make sense to me that smaller build booted on your machine, but bigger build didn't (unless you were also using copy2ram with the smaller build, since that would not run into any modules removed issue) - if it were a module issue, would occur for small or big firstrib_rootfs booting. On my machine, module ehci_pci was being removed on s100 revision - not allowing that to be removed fixed the usb boot for me (as I said boot from hd with your big firstrib00.plug build worked fine anyway).

Note that revision s101 is hot off the press and only given one brief test by myself thus far. But I'm releasing ultra-early since the quick test worked as my theory imagined it would... it may indeed need some further tweaks for some systems. I'm pretty sure it will be a similar module removed issue though.

EDIT2: If worst comes to the worst you can just comment out that whole block of code though and your system should boot since all modules will remain loaded. But uses more RAM that way. Actually Porteus boot in DebianDog does that; there are far more media driver modules loaded by DD Porteus boot than need to be (as lsmod shows). Puppy kernel, on the otherhand, has majority of these media drivers built permanently into the kernel (hence such issues don't occur) - official Void Linux kernel is pretty light in terms of few drivers directly built into it - so a bit harder to handle, but potentially lighter in use.

Alternatively, once plugin code fixed will be able to just use an empty plugin (or simply a # comment line in that with no actual code otherwise), then modules will not be removed at all so at least booting should fthen always work.

EDIT3: Sorry, in my haste I forgot I had moved "mount from" mountpoint after the overlay merge, so modules_remove plugin won't work yet, though the else code above should work for USB devices anyway. I'll fix the plugin code later today.

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 Fri 16 Aug 2019, 22:21; edited 2 times in total
Back to top
View user's profile Send private message 
rockedge


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

PostPosted: Fri 16 Aug 2019, 11:15    Post subject:  

yes I will test s101 revision....I can't get past the kernel panic with the s100. I'm going with the Void kernel on this series of tests
Back to top
View user's profile Send private message Visit poster's website 
wiak

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

PostPosted: Fri 16 Aug 2019, 18:25    Post subject:  

rockedge wrote:
yes I will test s101 revision....I can't get past the kernel panic with the s100. I'm going with the Void kernel on this series of tests


If you run into further problems, I'll need more info regarding media you are booting from to help work out what is going on. Also, please remember to start from blank directory in major bug tests just in case something in folder (and old upper_changes or whatever contains something causing any issues).

Despite bugs sometimes not seeming logical, there are sometimes race conditions involved that throw all logic out the window (though sleep insertions often then 'fix' the issue), or sometimes it can just be a matter of order of loading/unloading to fix. The biggest problem is when all works fine on the developer's own hardware - but not on someone elses - I can only test my own system; then system/devices-uses information becomes paramount in the bug search (followed by copious googling and probably lots of luck).

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: 1365
Location: Connecticut, United States

PostPosted: Fri 16 Aug 2019, 18:45    Post subject:  

I start fresh every time I build one to avoid problems and mix ups

I am booting from a HDD connected via USB
just got back home so I'll start the tests soon...

where is s101 located for download?
I cloned the project from github but I don't think I see s101
Back to top
View user's profile Send private message Visit poster's website 
wiak

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

PostPosted: Fri 16 Aug 2019, 19:41    Post subject:  

rockedge wrote:
where is s101 located for download?


It is already available in first post of thread rockedge. I uploaded it last night after a quick test of my own. I haven't uploaded to github, though I should, but I was waiting for tests (I'm not using git during actual development at the moment).

http://www.murga-linux.com/puppy/viewtopic.php?p=1028956#1028956

I imagine it may work for you since you are indeed connecting via usb.

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: 1842
Location: not Bulgaria

PostPosted: Fri 16 Aug 2019, 22:17    Post subject:  

Sorry, in my haste I forgot I had moved "mount from" mountpoint after the overlay merge, so modules_remove plugin won't work yet, though the else code above should work for USB devices anyway. I'll fix the plugin code later today.

I'll be looking into this module remove issue more thoroughly over the coming week, but in the meantime should be able to address most issues via plugin 'fix' (once that plugin code is fixed...)


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: 1842
Location: not Bulgaria

PostPosted: Sat 17 Aug 2019, 04:35    Post subject: build_firstrib_initramfs04_s102.sh uploaded  

build_firstrib_initramfs04_s102.sh uploaded to first post of this thread.

Changes:

****NEW (in Revision 1.0.2):

The trim modules code in the initramfs/init (i.e. modprobe -r etc...) now force keeps ehci, xhci, and sdhci modules to ensure boot ability of usb-connected devices (i.e. previously could get kernel panic on kernel unable to switch_root to /sbin/init).

Can now externally change that trim modules code section via plugin modules_remove.plug. If empty file of that name put in /mnt/bootpartition/bootdir, the modules will not be trimmed at all. Alternatively, any code placed in that plugin will be used instead of the default initramfs/init modules trim code (allowing easy fix of any such issues). That is:

/mnt/bootpartition/bootdir/modules_remove.plug should now be sourced if it exists as a regular file. If you simply create modules_remove.plug as an empty file then initramfs/init will not attempt to auto-remove modules that are not in use - that may prove helpful for systems that fail to switch_root because they cannot find /sbin/init

Alternatively, /mnt/bootpartition/bootdir/modules_remove.plug can be used to provide alternative modules remove code inside initramfs04/init - that will allow on-boot modifications to that part of the code without having to decompress the initramfs04 first.

This code really all needs tested on variety of different hardware. I only have a couple of different computer models to test it on, which over the next week I shall do as thoroughly as I can.

However, external testing will speed up the process of finding universal fix if current build initramfs04 script produces initramfs04.gz that fails on some hardware; such failures could be addressed via specially tailored modules_remove.plug once I know about them and can ascertain what being-removed-module needs to instead be kept.

Anyway, please let me know details of any tests results. If reports of failure, please also find out exact details of the boot media device involved so we can track down any missing module requirements.

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: 1365
Location: Connecticut, United States

PostPosted: Sat 17 Aug 2019, 10:26    Post subject:  

completed install of s101 successfully to a usb connected HDD
53 megs initramfs.gz
boots to void-login and so far have not tried the /rc.local trick with startx
connects to network and detects the wlan eth0 and lo and with ip link set eth0 up and ip link set lo up then udhcpc -i eth0

using Void kernel and here is the firstrib00.plug

Code:
xbps-install -y base-minimal mc
xbps-install -y ncurses-base linux4.19 linux-firmware-network wifi-firmware shadow
pwconv # set up passwd system
grpconv
echo -e "root\nroot" | passwd >/dev/null 2>&1 # Quietly set default root passwd to "root"
# you can add as many valid commandlines as you want in here
xbps-install -y xorg jwm rox bash xterm lxterminal geany adwaita-icon-theme


I would like to test if the firstrib00.plug can run the commands to rename the symlink /bin/sh from dash to bash and uncomment the en_US.UTF-8 UTF-8 in the /etc/default/glibc-locales and run
Code:
xbps-reconfigure -f glibc-locales
Back to top
View user's profile Send private message Visit poster's website 
rockedge


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

PostPosted: Sat 17 Aug 2019, 10:35    Post subject:  

I just started to work on s101..... now I will try s102...it takes me a few minutes to set up the systems! I will test s102 next. with those changes added to firstrib00.plug

then again it only takes minutes to run the scripts and have a working system and with a few more minutes it is quite easy to modify the OS into many desktop forms and shapes and how complex or simple as one desires.
Back to top
View user's profile Send private message Visit poster's website 
rockedge


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

PostPosted: Sat 17 Aug 2019, 14:41    Post subject:  

Successful build of s102 32 bit is completed and booted.

running from a usb HDD using 55 megs of RAM and the initramfs.gz is 53 megs

DELL INSPIRON E1505 dual core 2gigs RAM

firstrib00.plug

Code:
xbps-install -y base-minimal mc
xbps-install -y ncurses-base linux4.19 linux-firmware-network wifi-firmware shadow
pwconv # set up passwd system
grpconv
echo -e "root\nroot" | passwd >/dev/null 2>&1 # Quietly set default root passwd to "root"
# you can add as many valid commandlines as you want in here
xbps-install -y xorg jwm rox bash xterm lxterminal geany adwaita-icon-theme squashfs-tools


changed the /usr/bin/sh symlink from dash to bash


modified /etc/X11/xinit/xinitrc to this version (Note only the bottom lines have changed) ->

Code:
#!/bin/sh

userresources=$HOME/.Xresources
usermodmap=$HOME/.Xmodmap
sysresources=/etc/X11/xinit/.Xresources
sysmodmap=/etc/X11/xinit/.Xmodmap

# merge in defaults and keymaps

if [ -f $sysresources ]; then







    xrdb -merge $sysresources

fi

if [ -f $sysmodmap ]; then
    xmodmap $sysmodmap
fi

if [ -f "$userresources" ]; then







    xrdb -merge "$userresources"

fi

if [ -f "$usermodmap" ]; then
    xmodmap "$usermodmap"
fi

# start some nice programs

if [ -d /etc/X11/xinit/xinitrc.d ] ; then
 for f in /etc/X11/xinit/xinitrc.d/?*.sh ; do
  [ -x "$f" ] && . "$f"
 done
 unset f
fi

jwm &
rox -p default &
#xclock -geometry 50x50-1+1 &
#xterm -geometry 80x50+494+51 &
#xterm -geometry 80x20+494-0 &
exec xterm -geometry 80x66+0+0 -name login


then ran the script to build the initramfs.gz

all of it took under 15 minutes to finsh

_
Back to top
View user's profile Send private message Visit poster's website 
Display posts from previous:   Sort by:   
Page 19 of 49 [722 Posts]   Goto page: Previous 1, 2, 3, ..., 17, 18, 19, 20, 21, ..., 47, 48, 49 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.0685s ][ Queries: 13 (0.0111s) ][ GZIP on ]