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 Sun 15 Dec 2019, 10:18
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 43 of 49 [722 Posts]   Goto page: Previous 1, 2, 3, ..., 41, 42, 43, 44, 45, 46, 47, 48, 49 Next
Author Message
rockedge


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

PostPosted: Tue 01 Oct 2019, 08:56    Post subject:  

I needed some success after many many attempts to boot the weedog ISO and all resulting in a kernel panic. So I booted a Bionic32-v8 iso in VirtualBox into RAM and used GParted to format the virtual HDD and Grub4Dos to set up the MBR.

Downloaded the weedog scripts created a directory and copied those scripts and a firstrib00-32.plug.

ran those scripts with Bionic32 on VirtualBox and added a menu.lst to boot the new weedog.

I umounted the Bionic32 iso "CD" and booted into a brand new weedog running nicely in VBox.

Then I exported it as a VirtualBox appliance which I tested by creating a new virtual machine and loading and booting the weedog appliance

Which worked great and I feel better now.

The point really is...to be able to watch what a good boot looks like so I can modify the isolinux.cfg correctly to be able to boot weedog burned from a WeeDog ISO...in theory.

But some success is better than none and one step closer Very Happy

Plus fun watching a WeeDog run VBox and WeeDog
2019-09-30-184434_640px.png
 Description   
 Filesize   156.99 KB
 Viewed   306 Time(s)

2019-09-30-184434_640px.png

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: Tue 01 Oct 2019, 11:04    Post subject:  

I had no idea what I was doing really, but nevertheless I have successfully now booted a WeeDog void from DVD on my second attempt (talk about luck...).

My machine is an old HP elitebook 2530p which happens to come with a DVD writer built into it.

First I read:

https://wiki.debian.org/RepackBootableISO

ignoring all the jigdo stuff (as it said I could...)

So a command for making booting iso using xorriso was there...

My host system was BionicDog64, and I checked and it had isolinux and xorriso installed already.

Then I remembered I had seen possibility to create an iso when remastering with BionicDog's quick-remaster program, so I opened that up to check and sure enough it used xorriso command pretty much the same as in above debian link. The only difference is that above also uses -isohybrid-gpt-basdat, which I might later try since might be how to boot on UEFI machine (but I don't have such a machine here to test just now anyway - my partner has one, but she is away on trip till next week). Anyway, from the above, did the following:

1. created directory weedog_iso_build
2. cp -a /usr/local/isodata/isolinux weedog_iso_build
3. mkdir weedog_iso_build/weelive
4. cd weedog_iso_build/weelive
5. Put weedog build scripts in there and firstrib00.plug_void_default_anyarch and ran:
6. ./build_firstrib_rootfs_103.sh void rolling amd64 firstrib00.plug_void_default_anyarch

followed by (once firstrib_rootfs build complete):

7. ./build_weedog_initramfs05_s203.sh void "-comp lz4 -Xhc"
8. I then deleted all from inside weelive but for initramfs05.gz and 01firstrib_rootfs.sfs and vmlinuz (which I had renamed to simply vmlinuz)
9. Then I cd to just outside weelive and into isolinux folder (i.e. cd ../isolinux) and edited live.cfg to contain:

Code:
label WeeDog
kernel /weelive/vmlinuz
append initrd=/weelive/initramfs05.gz bootfrom=/mnt/sr0/weelive usbwait=12 inram_sz=100% changes=RAM


Really, I was guessing... but ends up working... I guess should also include copy2ram so you can umount and eject the CD or DVD tho I didn't try that.

10 then cd to just outside weedog_iso_build/isolinux (i.e. cd ..) and ran command:

Code:
xorriso -as mkisofs -r -J -joliet-long -l -isohybrid-mbr /usr/lib/ISOLINUX/isohdpfx.bin -partition_offset 16 -V "weedog" -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -o ../"weedog-void-amd64.iso" ../"weedog_iso_build"


The above causes the iso named weedog-void-amd64.iso to be created just outside the weedog_iso_build directory.

11. Then I used pBurn to first blank an ancient old DVD R/W I found in a box I had! And then used pBurn to burn the weedog-void-amb64.iso file onto it (via device /dev/sr0; perhaps /dev/cdrom would have worked - I don't know, I didn't try that). EDIT: just checked and /dev/cdrom is a symlink to /dev/sr0 on my machine so I guess that would have worked as an alternative.

12. And then I rebooted... and to my amazement... it booted up fine.

I hope I have documented the above correctly (I'm just writing it down from memory) but shouldn't be much missing or wrong if anything. Note that I guessed the append argument bootfrom=/mnt/sr0/weelive since it seemed to make sense - anyway, it booted, so seems to be correct for my system anyway; EDIT: but /mnt/cdrom/weelive might have been better - I'm not sure at the moment).

As I said, I did the above whilst running on a BionicDog64 host system; you'd need to make sure isolinux was installed (and xorriso and maybe more) if using a different system (and also maybe check the ISOLINUX directories are in the same place).

Hope the above helps you too rockedge, since same should surely boot directly on a VBox Virtual Machine also. I haven't uploaded the iso anywhere, since it is pretty big (508 MiB) since made no attempt to slim it down (firmware etc) in any way.

EDIT: Note that. to make them easy to find, I've added link to this post and to rockedge's VBox-related post above to the HowTo list at User Contributions post:

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

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: Tue 01 Oct 2019, 15:14    Post subject:  

I am carefully looking over what you did and I will go ahead and repeat it plus modify what I have so far. I figured if I could boot it on VirtualBox it will boot on my physical machines and I don't need to restart my real machine every time I break something.

I should soon have a copy of something that works well and go from there

Plus I compiled pure-ftpd which is working really well for super easy FTP server set ups in WeeDog
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: Tue 01 Oct 2019, 16:24    Post subject:  

Success!

It was a faulty isolinux.cfg parameters. I used sr0 and it worked.
my structure is different slightly then what wiak used.

Bionic32-v8 as host mounted on /mnt/sdb1
mkdir /mnt/sdb1/weedog

copied the weedog build scripts with the firstrib00-32.plug into /mnt/sdb1/weedog and ran both scripts which successfully completed.
Deleted the scripts from /mnt/sdb1/weedog.
and copied from Bionic32-v8 and added to the weedog files:
Code:
01firstrib_rootfs.sfs
efi.img
isolinux.bin
ldlinux.c32
libcom32.c32
libutil.c32
vmlinuz-5.2.17_1
initramfs05.gz


I added isolinux.cfg like this:
Code:
DEFAULT linux
  SAY Now booting the kernel from SYSLINUX...
LABEL linux
  KERNEL vmlinuz-5.2.17_1
  APPEND initrd=initramfs05.gz bootfrom=/mnt/sr0 usbwait=12 inram_sz=100% changes=RAM   


then from a terminal opened in /mnt/sdb1 used:

Code:
mkisofs -b isolinux.bin -c boot.cat -D -l -R -v -V "WeeDog" -no-emul-boot -boot-load-size 4 -boot-info-table -o "weedog32.iso" weedog


ISO is created in /mnt/sdb1 as weedog32.iso.

I created a VirtualBox machine and booted and logged in and startx activated the X desktop

I will be trying out isohybrid as well now, and construct some simple installer perhaps

this ISO is 1156 megs...But nothing has been stripped or compressed that much and I am not 100% sure all those files need to be in the ISO for booting...that I will have to look at

_
_
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: Tue 01 Oct 2019, 22:06    Post subject:  

That's great rockedge. It's good to have weedog iso booting now, especially useful for virtual machine boots, I should try that. I used to use VMware a lot at work, and virtualbox occasionally at home but many years ago. Mainly I did a lot with User Mode Linux though since it was so lightweight back then and perfect for my network LAN/router experiments.

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: Wed 02 Oct 2019, 03:06    Post subject:  

I've been thinking further about the point or otherwise of providing WeeDog (Void or otherwise) in the form of downloadable isos. To be frank, for the most part I see litlle point unless simply to get some people started.

Aside from removing var/cache/xbps contents I generally see no point in trying to produce a small download in terms of an iso. That has always been a major focus on this forum, but when I for example use BionicDog, though the iso download is small my daily system built using it isn't once I've installed the apps I want is several GB... If someone did want a small WeeDog for running on an old system wholly in RAM, then I'd suggest using BionicPup (or other Pup) kernel/firmware/modules sfs with WeeDog (you could certainly build a very small WeeDog that way); that has some disadvantages in terms of Void compatibility, but for old system, a good flexible approach since you still get xbps capability no traditional Pup would give you.

Alternative is to use a DebianDog, which is a great system in terms of functionality, though they are not particularly small in terms of firmware/modules either (I never use copy2ram with my DebianDogs) - Puppy on the other hand includes specially compiled kernel which to some extent needs less external firmware/module support. Of course 'special' kernel/module/firmware combinations could be built on and for Void itself - though personally I have no such plans.

The main bulk of Void Linux is simply the large amount of firmware (and to some extend the large number of modules) that come with it. In general use that just occupies disk space (of which there is usually plenty) - Void Linux as a distro is however extremely efficient in terms of RAM and CPU use, and hard to beat IMO. The one exception where smaller rootfs size would be useful would be when using copy2ram in a very small system configuration (more apps soon take up much more space than the firmware...) - certainly less firmware would provide a one-off overhead reduction, so if anyone comes up with a way of determining what firmware and modules their own system actually needs of course that would be a useful utility.

Otherwise, I think simply using the two build scripts is the best way to install WeeDog (or use an existing root-filesystem, Void, or Slackware, or whatever, along with WeeDog initramfs provided via build_weedog_initramfs script).

For special purposes, such as rockedge's Zoneminder, I think an iso of 600Mb to 1GByte (or more) is perfectly appropriate, or for an image to use with VirtualBox or similar (though it remains the case IMO that installation via build scripts is much more flexible in practice, in the likes of VirtualBox too - i.e. builds specially created firstrib build plugs... and then, if wished, put into bootable iso form via simple utility).

But above is just my opinion - if someone wants to pursue the making of a small iso that's fine of course!

I would always encourage using the build scripts (with well-developed firstrib plugin) for simplicity and ease of maintenance over downloading any pre-configured iso. It is just so simple and more satisfying overall in the end... The simplicity of the build system and the special functionality of WeeDog initramfs is a major point of difference to other offerings. That, and the ease also of adding additional WeeDog initramfs functionality via its simple script plugin support, which removes the need for expanding, custom one-purpose editing, and re-compression of the initramfs cpio archive itself. So anyone can practice adding functionality to WeeDog without danger of damaging the core initramfs itself - like a lego distro building kit, which gives it a huge amount of scope for developers, and, by its thus very open nature, also invites the contributions of others.

wiak

EDIT: But in terms of not making a small iso, I'm talking above about general purpose download iso. For your own use on particular system, see my next post, where I'll describe what I do sometimes.

_________________
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: Wed 02 Oct 2019, 05:33    Post subject:  

Following on from my immediately above post:

Generally, I find I don't need much firmware. Immediately after booting WeeDog, I run command:

Code:
dmesg | grep firmware


which only reports:

Code:
[    8.997192] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[    9.049562] iwlwifi 0000:02:00.0: loaded firmware version 8.83.5.1 build 33692 op_mode iwldvm


I then google iwlwifi "firmware version 8.83.5.1 build 33692"

and find this link:

https://wireless.wiki.kernel.org/en/users/Drivers/iwlwifi

and that page tells me that firmware 8.83.5.1 corresponds to:

iwlwifi-5000

as I once described here: http://www.murga-linux.com/puppy/viewtopic.php?p=1022822#1022822

Actually, for my wifi driver, I use firmware: iwlwifi-5000-5.ucode

So what I do, is I build firstrib_rootfs including the install of linux-firmware-network (which happens to include the above I think). Anyway, I then copy the whole of /usr/lib/firmware out of firstrib_rootfs (for use when needed) and simply put back firstrib_rootfs/usr/lib/firmware/iwlwifi-5000-5.ucode. That simple step saves almost 250 MB! i.e. start with almost no firmware and only add what you later find you need...

[at that stage you can also further prune the system. For example, emptying out contents of /var/cache/xbps and /usr/share: man pages, docs, info pages, and locales etc. and even stripping lib binaries, though sometimes risky and I wouldn't bother]

Great thing is, in WeeDog, I can boot with that uncompressed firstrib_rootfs, to make sure that firmware is enough... simply by renaming it to 01firstrib_rootfs (and disabling any 01firstrib_rootfs.sfs by maybe renaming that to NO01firstrib_rootfs.sfs). Result is, that for commandline use anyway, weedog boots fine with that and connects to Internet via wifi... Yes, I may need some other firmware for graphics use (maybe /usr/lib/firmware/i915 folder for my system (but I can add that later). Of course I could also make a small NNfirmware.sfs file for adding to one of the WeeDog layers if I so decide (but not really necessary), or an alternative firstrib_firmware_modules.sfs (as described in earlier builds).

Modules don't take up so much space as Void-provided-firmware anyway, but there is a simple script available that could be modified to prune down the modules you might need (based on output of lsmod after WeeDog booted). remove_kernel_modules.sh:

https://wiki.ubuntu.com/ReducingDiskFootprint?action=AttachFile&do=view&target=remove_kernel_modules.sh

I haven't tried the above remove modules tool yet, but it looks sensible and simple enough.

So with these simple measures you could make a very small custom iso for your own system (which is handy for copy2ram use).

The following is a useful hw determining tool:

Code:
xbps-install lshw


Some details in about such tools in this thread:

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

and: https://ezix.org/project/wiki/HardwareLiSter

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: Wed 02 Oct 2019, 08:22    Post subject:  

In addition to clearing out /var/cache/xbps my firstrib plug also clears out

/usr/lib/libreoffice/share/extensions ... dictionaries for other languages

/usr/share/locale .. locales for other non used locations

rm -rf /usr/lib/libreoffice/help # 195MB (68MB lz4 -Xhc compressed)

A massive saving can also be achieved by clearing out firmware and modules. To achieve that you can compile the kernel using localyesconfig such that all of the modules required for your hardware are built into the kernel. Last time I ran that it expanded the kernel from something like 7MB to 16MB (minimal increase) whilst knocking down the main sfs filesize by around 250MB (big saving). BUT compiling the kernel whilst relatively simple does take a lot of time ... several hours (and some). And of course the product is a kernel that is specific to the hardware/machine (non portable).

Haven't tried it, but this looks helpful https://github.com/graysky2/modprobed-db. Rather than having to attach everything you might use prior to building the kernel with make localyesconfig you can record them as you go using that utility (assuming it works as described)
Quote:
You need to make sure that all modules you will ever need are loaded at the point you run make localmodconfig. One tool that can help to achieve this is https://github.com/graysky2/modprobed-db.

First, boot up a default distribution kernel and run /usr/bin/modprobed-db store periodically, or every time you connect some new piece of hardware.

Then, run sudo /usr/bin/modprobed-db recall which will load all the modules that were ever loaded when modprobe-db store was run, and now you do make localmodconfig.


From the kernel documentation
Quote:
"make localmodconfig" Create a config based on current config and loaded modules (lsmod). Disables any module option that is not needed for the loadedmodules.

To create a localmodconfig for another machine, store the lsmod of that machine into a file and pass it in as a LSMOD parameter.

For me however, saving 340MB of firmware/modules out of the final main sfs (lib firmware and modules folders), 250MB or so smaller sfs filesize is pretty much irrelevant on my 4GB laptop. Inconvenience of having to compile each kernel rather than having it delivered as a pre-built binary ... for zero benefit in my case. And from what I've seen so far, voidlinux regularly release kernel versions/changes.

My laptop sees around 700GB of ram reserved for graphics, so 3.3GB out of 4GB total ram of remaining available ram. I boot everything into that, copy2ram, changes=RAM with a main sfs that is loaded with pretty much all I use (chromium, libreoffice, vlc, audacity, openshot ....etc.) and typically that sees around half of the available ram remaining for operation. Just in case ... I also create/load a encrypted swap file on hdd (located on sda1), automatically sized to the same size as ram (3.3GB) and commonly even under pretty heavy usage not even half of that gets used (I should really revise the code to set the swap file to being half size). And that's all when using lz4 (-Xhc) compression, with xz high compression the size can be reduced substantially more - but at the expense of slower performance. voidlinux is quick by itself, when used with fast lz4 decompression and having everything run in ram (my laptop's spin up speed is noticeably slow, the reason I came by it (gifted (as good as new) by a Windows fan, but where Windows ran painfully slow on the laptop)) .. it really flies.

PS ... I boot with inram_sz=100% and thus far haven't noticed any downside from doing so.
s.png
 Description   
 Filesize   8.71 KB
 Viewed   180 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 
rufwoof


Joined: 24 Feb 2014
Posts: 3681

PostPosted: Wed 02 Oct 2019, 08:56    Post subject:  

I've removed all tray icons from jwmtray such as xload, cpu temperature, caps lock, battery power ... to just leave the clock. That considerably lowers the temperature and cycles, so improves battery reserve times. No menu button either (I set the jwm clock to left mouse click activate show/hide desktop, right mouse click to show the jwm menu).
Code:
        <TaskList maxwidth="2560"/>

        <Dock/>
        <Clock format=" %a %d %b %H %M"><Button mask="1">showdesktop</Button>
        <Button mask="23"></Button></Clock>

    </Tray>
I leave jwm menu sparse however, just shutdown/reboot and launch Terminal, but where I have tilda terminal always running, F1 to show (full screen) and hide it. To launch programs I use xlunch, so just one file to maintain (/etc/xlunch/entries.dsv). I also have skippy installed, so you can quickly see/select open windows - but jwm tray also provides that function. I have alt-space and altgr-space (right side of spacebar) set to present xlunch, which once you're used to it is very quick/easy. /etc/system.jwmrc (being a single user desktop (laptop) I edit the main files rather than storing versions under /root) code snippet ...
Code:
    <Key mask="C" key="Down">exec:amixer -c 1 set Master 2%- </Key>
    <Key mask="C" key="Up">exec:amixer set -c 1 Master 2%+ </Key>
    <Key mask="C" key="0">exec:amixer -c 1 sset Master,0 toggle </Key>
    <Key mask="4" key="space">exec:skippy-xd</Key>
    <Key mask="A" key="space">exec:/usr/local/bin/xlunch-show.sh</Key>
    <Key mask="5" keycode="65">exec:/usr/local/bin/xlunch-show.sh</Key> # AltGr space

ctrl up/down arrows raises/lowers the volume.

The rightmost vertical strip of keys all serve as browser control, HOME jumps to the top of a web page, END jumps to the bottom, Page Up/Down jumps up/down by a page, arrow keys moves a web page line by line.

I also prefer mc (midnight commander) for file management over rox, but I do use rox (and geany) at times. mc is available through F1 (tilda), and where typically that is the first thing I load up in one of tilda's tabs (multiple terminals).

alt-space and type the first few letters of a program to filter down to the intended program, or use the arrow keys to move to the target program and press Enter to launch it ... or use the touchpad and mouse to and click the program to launch it. Very quick once you're driving that instinctively. And voidlinux's supplied version of xlunch works incredibly well IME. The best so far that I've come across (having tried xlunch across a range of different distros).



Alt space and run the zzz command to put the laptop instantly into sleep mode whether the lid is opened or closed. Enter to wake it up again. I don't run any acpi stuff so if I have something running and I'm physically moving around I can close the laptop lid without it automatically going into sleep mode.

Highly recommend you try xlunch for yourself. I never used to use the AltGr key, as on a UK keyboard the only thing that I might occasionally use it for is to altgr 4 ... to print the Euro currency symbol €, other than that it was pretty much a dead key for me. Now as a right hand xlunch launch ... it gets more than its fair amount of usage Smile

_________________
( ͡° ͜ʖ ͡°) :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: Wed 02 Oct 2019, 09:26    Post subject:  

Well I think I have finally found a bug (introduced in model 05 I think), though I have to double-check. I haven't found it till now, because it actually has no effect on anything weedog initramfs is being used for currently. But it would have been noticed if using, say, BionicPup kernel and a 00firstrib_firmware_modules.sfs, which no one contributing to this thread has done for a long time. It's simply this line 325 of build_weedog_initramfs05_s203.sh script:

Code:
   mount --bind 00firmware_modules/usr/lib/modules /usr/lib/modules  # needed for overlayfs module


Though, I have as yet to double-check this, I believe it should be:

Code:
   mount --bind ${layers_base}/00firmware_modules/usr/lib/modules /usr/lib/modules  # needed for overlayfs module


I came across it, because, following my previous post, I was experimenting with extracting /usr/lib/firmware and /usr/lib/modules out of firstrib_rootfs and putting that into a 00firstrib_firmware_modules.sfs, which actually works by the way, even with the above bug because in Void kernel case the modules are in any case already loaded into the initramfs itself so above failing mount has no detrimental effect (would be different with BionicPup kernel case where modules are not pre-loaded into the initramfs...).

The reason I was experimenting was simply that, though not quite as good as re-compiling the kernel with modules/firmware built in, does allow using very small amount of system-specific firmware in the firstrib_rootfs. On my system, I just have that iwlwifi firmware in /usr/lib/firmware, so also getting a massive firstrib_rootfs size saving... (firmware is not preloaded into the initramfs, only the modules and these take up much less space than the huge amount of firmware Void provides).

I'll mention a bit more of how to use a 00firstrib_firmware_modules.sfs like this in my next post, once I've double-checked everything. It makes it possible to provide a much smaller downloadable iso, but with separate 00firstrib_firmware_modules.sfs, which may be no big deal at all. Of course if kernel changes, the initramfs needs rebuilt anyway since the modules needed in that also need changed. With Void kernel you certainly do need sufficient modules inside the initramfs itself such that it can do the overlay and also load the modules needed to see the external firstrib_rootfs on whatever media it is stored on (however, there is no doubt that modules list inside initramfs could also be pruned significantly - though I'm also not sure it is worth doing so for most scenarios on most computers 10 years old or less...).

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: Wed 02 Oct 2019, 09:33    Post subject:  

So, just briefly. To extract the firstrib_rootfs firmware and modules and put them into an sfs for auto-loading, what I do is this:

Code:
mkdir -p firstrib_firmware_modules/usr/lib
# mv firstrib_rootfs/usr/lib/modules firstrib_firmware_modules/usr/lib/modules # probably not move modules - see NOTE at foot
mv firstrib_rootfs/usr/lib/firmware firstrib_firmware_modules/usr/lib/firmware


Then I prune the firmware down to next to nothing (which saves tons); could also prune the modules at that stage, and then, I make the sfs with command:

Code:
mksquashfs firstrib_firmware_modules/ 00firstrib_firmware_modules.sfs -noappend -comp xz -b 524288 -Xdict-size 524288 -Xbcj x86


Then I rename firstrib_rootfs to 01firstrib_rootfs and boot the system with that uncompressed 01firstrib_rootfs (instead of 01firstrib_rootfs.sfs) to see if all works. Then I can make a new 01firstrib_rootfs.sfs out of that when it does (much smaller since no firmware and modules taken out of it).

NOTE: In practice, I'd probably modify the above to just put /usr/lib/firmware into 00firstrib_firmware_modules.sfs because modules for Void Linux need to be built into the initramfs and the build_weedog_initramfs05 script needs these modules to be in firstrib_rootfs so best to leave them there... But the above idea should work fine with /usr/lib/firmware

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 
seaside

Joined: 11 Apr 2007
Posts: 935

PostPosted: Wed 02 Oct 2019, 10:51    Post subject: Usb drive timing  

In my experience, it seems there is a wait of usb device recognition anywhere from one-half second to twenty or more. Instead of having a "usbwait=15", what about a "variable speed" usb device loader....

Here's a modification to the "build_weedog_initramfs" "init" file I've started to use.

On the boot kernel line put "usbwait=0"

Upon boot, a test loop is then entered and checked in .5 second intervals until the "/mnt/${bootpartition}" is mounted.

Changes to "init" -

Code:

#Find below line and comment it out
# mkdir -p /mnt/${bootpartition} && mount /dev/${bootpartition} /mnt/${bootpartition}

#add this -

mkdir -p /mnt/${bootpartition}

if [ $usbwait -eq 0 ] ; then
echo -e "\e[33mCurrently seeking $bootpartition for slow devices. Please wait patiently...\e[0m"  >/dev/console
while ! mount /dev/${bootpartition} /mnt/${bootpartition} 2>/dev/null; do  sleep .5; done
else
mount /dev/${bootpartition} /mnt/${bootpartition}
fi

echo -e "\e[32mYes.found and mounted $bootpartition .. now continuing boot process.....\e[0m" >/dev/console

You can put an actual sleep amount or "0" for "variable".

So far, I've just used "usbwait=0" and it's working nicely..

Cheers,
s
Back to top
View user's profile Send private message 
wiak

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

PostPosted: Wed 02 Oct 2019, 10:57    Post subject: Re: Usb drive timing  

seaside wrote:
In my experience, it seems there is a wait of usb device recognition anywhere from one-half second to twenty or more. Instead of having a "usbwait=15", what about a "variable speed" usb device loader....


Yes, I did actually consider doing pretty much exactly that early on (except I just planned to the increment time idea, not having fixed as an alternative at all), but at that time was keeping the build script very simple and with as few lines as reasonably possible so just adopted a user manual entry for usbwait. However, the script has inevitably increased (a bit...) in size and complexity (whilst still being relatively short, simple to read, modify and understand, so yes, putting that auto-usbwait mechanism in place would probably be fine (and I like the implementation). I'm soon to upload new version because of small 'bug' I mentioned in my post above, so might try that in the latest and see if it works out to everyone's satisfaction.

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: Wed 02 Oct 2019, 12:05    Post subject:  

the overall size is not a concern of high priority at this time. Performance although is, and good low CPU loads and temps with actually quite low RAM usage is what I am experiencing.

The ISO I threw together is mainly for experimentation and gaining some knowledge. Running the scripts from a host system like Puppy Linux Bionic which is a great system for this kind of work, is the best way to start a build of WeeDog. Using a plug that is already tested or just modifying one for personal preference because it is easy to do.

But there is the case that someone does not have a host system to start up, and needs some basic system to boot to be the host system. In this case the ISO would be handy, especially since WeeDog can run those scripts very well and why not have a WeeDog that can be host to creating another WeeDog.

I would like to see Grub4Dos run in WeeDog. I am playing around with it, so far no luck.

I am seeing that even if the size of WeeDog is in my case without ZoneMinder and LHMP is as an ISO 1151 megs large but it will run in only 71 megs of RAM after startx activated the X server desktop.

_
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: Wed 02 Oct 2019, 12:16    Post subject:  

I'm not sue what you mean about getting grub4dos to run in WeeDog rockedge. I use grub4dos to boot when making weedog USB bootable.

By the way, seaside, I came across a kernel command line parameter some time ago, rootwait, which sounded relevant but I forgot to look into it. I'm off to sleep now but maybe worth investigating its purpose. Probably I'll set things to not wait indefinitely though, but rather to have a give up timeout in case device faulty.

quai

_________________
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 
Display posts from previous:   Sort by:   
Page 43 of 49 [722 Posts]   Goto page: Previous 1, 2, 3, ..., 41, 42, 43, 44, 45, 46, 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.1957s ][ Queries: 13 (0.0379s) ][ GZIP on ]