RC7 (STABLE) WeeDogLinux Arch 64 now released

[rufwoof]

The (function) code snipped I'm using for voidlinux autologin (as root) ...

Code: Select all

_autologin () {
  echo Setting up autologin and auto start X
  cp -R /etc/sv/agetty-tty1 /etc/sv/agetty-autologin-tty1
  echo "GETTY_ARGS=\"--autologin root --noclear\"" >>/etc/sv/agetty-autologin-tty1/conf
  rm /var/service/agetty-tty1
  ln -s /etc/sv/agetty-autologin-tty1 /var/service
  # Above is as per https://wiki.voidlinux.org/Automatic_Login_to_Graphical_Environment
  # however for live-boot that doesn't work alone, we also need to ...
  cd /etc/runit/runsvdir/default
  rm agetty-tty1
  ln -s /etc/sv/agetty-autologin-tty1 agetty-autologin-tty1
  # Auto start X
  cat <<'EOF' >> /root/.profile
# autologin on tty1
if [ -z "$DISPLAY" ] && [ "$(fgconsole)" -eq 1 ]; then
  exec startx
fi
EOF
}

I've also added masterpdfeditor5 to the core set

[Keef]

I've already managed a 32bit build with previous versions, but build_weedog_initramfs05_s103u.sh is not working with the 'void' parameter, to use its kernel.
I get:

Code: Select all

 firstrib_rootfs needs to at least include xbps-install:
linuxX.XX, ncurses-base, and linux-firmware-network,
and optional small extra wifi-firmware.
Or simply install ncurses-base, and template: linux
(which also brings nvidia, amd, i915 and more graphics drivers)

It works without using 'void', but no kernel or firmware of course.

EDIT I've just checked firstrib_rootfs. Kernel is there in boot/ but not in boot/kernel.
If I move it (kernel) to the kernel folder it works then. I'll have to try a previous version again and check if there is a difference that is not just my own doing.

[wiak]

I've already managed a 32bit build with previous versions, but build_weedog_initramfs05_s103u.sh is not working with the 'void' parameter, to use its kernel.
I get:

Code: Select all

 firstrib_rootfs needs to at least include xbps-install:
linuxX.XX, ncurses-base, and linux-firmware-network,
and optional small extra wifi-firmware.
Or simply install ncurses-base, and template: linux
(which also brings nvidia, amd, i915 and more graphics drivers)

It works without using 'void', but no kernel or firmware of course.

EDIT I've just checked firstrib_rootfs. Kernel is there in boot/ but not in boot/kernel.
If I move it (kernel) to the kernel folder it works then. I'll have to try a previous version again and check if there is a difference that is not just my own doing.

Keef, I haven't had any such problems and no other such reports so I suggest you redownload the build scripts in case you have accidentally modified your own copy wrongly. The section of code in build_weedog_initramfs05_s103u.sh that copies the kernel and modules over into initramfs is as follows and you should note that it expects to find the kernel at firstrib_rootfs/boot and NOT at firstrib_rootfs/boot/kernel. Are you sure you have not installed two different kernels into firstrib_rootfs(?) - that would also cause that error I think. If so you need to delete one of the kernels manually. Void will download the current default kernel usually, which is now up to 5.x and no longer 4.19:

Code: Select all

# Modules need to be loaded by initramfs/init if distro_name kernel being used
case "$kernel" in
	void)
		# Copy in Void Linux kernel modules and firmware from firstrib_rootfs,
		# and copy out Void kernel vmlinuz for later copying to /mnt/bootpartition/bootdir
		echo "Copying Void Linux modules to initramfs build. Please wait patiently..."
		cp -af firstrib_rootfs/usr/lib/modules firstrib_rootfs_for_initramfs_sNNN/usr/lib/
		cp -a firstrib_rootfs/boot/vmlinuz* .

		# initramfs/init needs to load sufficient modules to boot system
		_modprobe_modules
	  ;;

Per the following link, to keep the code simple I don't have any logic in the build script to account for possibility the user has installed two kernels in firstrib_rootfs.

http://www.murga-linux.com/puppy/viewto ... 28#1036728

wiak

[rufwoof]

I hit a similar problem a couple of weeks back and indeed it was because I was specifying a kernel version, modifying it to just install 'linux' (meta-package) resolved the issue for me. This is my current install set ...

Code: Select all

xbps-install -y linux base-system shadow xorg xinit xbitmaps \
                terminus-font squashfs-tools alsa-utils jwm \
                tilda mtpaint mc galculator adwaita-icon-theme \
                ccrypt xdotool skippy-xd xlunch bmon iftop \
                calcurse htop ncdu curl chrony xterm geany qt5ct \
                cryptsetup inxi android-file-transfer-linux dbus \
                alsa-plugins dunst inetutils dhclient alsa-tools \
                gvfs polkit usbutils p7zip usbmuxd wireless_tools \
                alsaequal gkrellm yad encfs wkhtmltopdf fzf \
                octoxbps guvcview libreoffice chromium vlc audacity \
                gparted kdenlive ssr master-pdf-editor

[Keef]

Yes it is probably just me. I usually delete everything and start from fresh, but there were two kernels in there for some reason (perhaps I had forgotten the last time).
Anyway, all working well now, apologies for flagging up a non-existant problem.

EDIT - looks like it is definitely because I have a specific (older) kernel identified in the plugin, and the current one is being downloaded too. I'll know to avoid that now.

[rufwoof]

Doing yet another build, but whilst waiting I loaded a 1hr 20m video into audacity where I wanted to amplify the sound. Applied the amplification filter and saved that to a .mp3 (amplified-audio.mp3)

Used ffmpeg to strip out the sound from the original video using the -an switch ...

ffmpeg -i Stephan_Bodzin.mp4 -c copy -an Stephan_nosound.mp4

which took around a minute to run through. Now merging that soundless video with the amplied sound .mp3

ffmpeg -i Stephan_nosound.mp4 -i amplified-audio.mp3 output.mp4

That's all booted using copy2ram voidlinux variant, but I am now also adding a encrypted swap file based on HDD and sized to the amount of available ram and with that firstrib build and ffmpeg merging all going on its heavily loaded and using around a GB of swap.



However browsing and also playing that amplified mp3 in vlc and I'm not noticing any slowdown/jitter/glitches at all [The build is just starting to mksquashfs and the system is still chugging along nicely].

[wiak]

Anyway, all working well now, apologies for flagging up a non-existant problem.
...
EDIT - looks like it is definitely because I have a specific (older) kernel identified in the plugin, and the current one is being downloaded too. I'll know to avoid that now

I'm working on new build initramfs script at the moment so I'll see if I can address that problem in that one - possibly simply by warning user two or more kernels.

wiak

[rufwoof]

Setting up a x86_64 and noarch snapshot (static Void ) mirror of the voidlinux repo for --current (that is a sub folder within current). Note that I am excluding non-free (which is a sub-folder below current) as that's stuff I don't use ... nvidia and suchlike. You may prefer to include that and if so then remove the --exclude 'nonfree' from the rsync command parameters

Code: Select all

#!/bin/sh

xbps-install -y rsync
mkdir -p /mnt/sda1/VOID-REPO  # where we'll store the local repo

rsync -avHP --delete --exclude 'debug' --exclude 'multilib' --exclude 'musl' --exclude 'nonfree' --exclude 'aarch64' --exclude '*.armv7l.xbps*' --exclude '*armv6l.xbps*' --exclude '*.i686.xbps*' rsync://alpha.de.repo.voidlinux.org/voidmirror/current/ /mnt/sda1/VOID-REPO/current/

# Note that nonfree is a sub folder beneath 'current'
# To get less verbose log leave out v and P options to rsync.
# Once you have a static version of the repo, that can be used as an
# argument to the --repository option or be declared in /etc/xbps.d/.
# files in that folder mask/override the default files of the same name in /usr/share/xbps.d
# i.e. copy those files into /etc/xbps.d/ and edit them to point to the local repo folder
# A complete URL or full path can be entered to the repo location

# Repo has to be indexed before it can be used ...
cd /mnt/sda1/VOID-REPO/current
xbps-rindex -a /mnt/sda1/VOID-REPO/current/*.xbps

Afterwards I have a 42.4GB local repo

Duplicating /usr/share/xbps.d/. files into etc/xbpd.d ... and modifying those to use that local repo instead of a url, will take precedence over the /usr/share/xbps.d/ file settings i.e. entry of repository=/mnt/sda1/VOID-REPO/current
Alternatively you can specify the repo on the xbps-install line for instance
xbps-install -y --repository=/mnt/sda1/VOID-REPO/current leafpad

For stability I'd rather have a static repo to build/run from, and just periodically update that to another later known/proven-working snapshot, rather than risking regular updating and potential breakage at the worst possible time.

EDIT: Just re-ran that a few days later and the rsync update and re-indexing took just minutes to run through.

[seaside]

Has anyone run into this problem? Or ideas on cause?

Code: Select all

./build_firstrib_rootfs_102.sh void rolling i386

From download.log

xbps-0.56_7: configuring ...
xbps-0.56_7: installed successfully.

19 downloaded, 19 installed, 0 updated, 19 configured, 0 removed.

*** Next command in INSIDE_CHROOT is "xbps-install -y eudev"
*** which sets up these names for install and then is killed

Name Action Version New version Download size
libblkid install - 2.34_1 135KB
libkmod install - 26_3 42KB
eudev install - 3.2.8_2 952KB

Size to download: 1130KB
Size required on disk: 8942KB
Space available on disk: 44GB


[*] Downloading packages
Killed

At the INSIDE_CHROOT point where "xbps-install -y eudev" executes ,the files are set up to be downloaded, but then the downloading is "Killed" - and the same happens with any subsequent firstrib00.plug commands following.

At first I thought maybe the repo was it, but changing that did not fix. A real puzzle for me.

This is a very nifty project, Thanks.

S

[wiak]

EDIT: < 42GB final local repo mirror for x86_64 and noarch, however doesn't build with the current build scripts as there's hard coded repo setting within the script(s). I've move using a local repo to the backburner for the time being.

I'm not sure what hard coded repo setting you are referring to, rufwoof. I haven't looked into using local repo for everything, but in the scripts the repo used during the build can be changed via plugin firstrib.repo (though I haven't thought of, or tried, setting that up to use local repo and can't remember at the moment what void wiki says about using local repos). Should be possible to make it work I'm sure. Here is current change repo code via the plugin:

Code: Select all

	repo="https://alpha.de.repo.voidlinux.org"  # default build repo
	if [ -s "./firstrib.repo" ];then . "./firstrib.repo"; fi
	# i.e. If firstrib.repo exists then source it to change build repo from above default
	# For example, for "us" repo, firstrib.repo text file should just contain the single commandline
	#              repo="http://alpha.us.repo.voidlinux.org"

wiak

[wiak]

Has anyone run into this problem? Or ideas on cause?

Code: Select all

./build_firstrib_rootfs_102.sh void rolling i386

From download.log

xbps-0.56_7: configuring ...
xbps-0.56_7: installed successfully.

19 downloaded, 19 installed, 0 updated, 19 configured, 0 removed.

*** Next command in INSIDE_CHROOT is "xbps-install -y eudev"
*** which sets up these names for install and then is killed

Name Action Version New version Download size
libblkid install - 2.34_1 135KB
libkmod install - 26_3 42KB
eudev install - 3.2.8_2 952KB

Size to download: 1130KB
Size required on disk: 8942KB
Space available on disk: 44GB


[*] Downloading packages
Killed

Hi seaside,

I just did a quick build in empty directory using:

Code: Select all

./build_firstrib_rootfs_102.sh void rolling i386

partial log:

Code: Select all

xbps-0.56_7: configuring ...
xbps-0.56_7: installed successfully.

19 downloaded, 19 installed, 0 updated, 19 configured, 0 removed.

Name     Action    Version           New version            Download size
libblkid install   -                 2.34_1                 126KB 
libkmod  install   -                 26_3                   36KB 
eudev    install   -                 3.2.8_2                946KB 

Size to download:             1110KB
Size required on disk:        8914KB
Space available on disk:      4172MB


[*] Downloading packages
libblkid-2.34_1.x86_64.xbps: 126KB [avg rate: 192KB/s]
libblkid-2.34_1.x86_64.xbps.sig: 512B [avg rate: 6494KB/s]
libkmod-26_3.x86_64.xbps: 36KB [avg rate: -- stalled --]
libkmod-26_3.x86_64.xbps.sig: 512B [avg rate: 5618KB/s]
eudev-3.2.8_2.x86_64.xbps: 946KB [avg rate: 210KB/s]
eudev-3.2.8_2.x86_64.xbps.sig: 512B [avg rate: 5618KB/s]

[*] Verifying package integrity
libblkid-2.34_1: verifying RSA signature...

so all building successfully for me. I don't remember ever seeing the Killed error you mention. I am building on BionicDog64 at present (can build i386 result from 64bit OS, but can't build 64bit system from 32bit OS since chroot part wouldn't work then). I'll boot up BionicPup32 and try the same from there and let you know if all went fine there too.

EDIT: I should mention that I have occasionally had a problem with Void Linux .de repo going down (maybe for maintenance), so on those occasions have created a firstrib.repo txt file plugin, which I put in build directory alongside build_firstrib_rootfs_102.sh. That just contains the url of alternative repo. Contents as follows for http us repo:

Code: Select all

repo="http://alpha.us.repo.voidlinux.org"

I've still to try build from BionicPup32 host - I had a disaster last week during mount experiments where my partition with that on it had been accidentally erases. I'm re-downloading BionicPup32 right now...

wiak

[rufwoof]

Hi wiak. Yes it (repo) is a small/simple change. I've put in on hold as I'm striving to stick with the default build scripts and I didn't want to get too diversified from the core build/setup (rolled back rather than continuing to make too many changes).

On a separate note attached is a sfs for tray temp (sourced from http://www.murga-linux.com/puppy/viewto ... 63#1030063). Installing that into void linux variant seems to work fine. Fake .gz suffix but that doesn't matter as you can just 'load' it as-is using

Code: Select all

unsquashfs -f -d / traytemp_1.4.sfs.gz

To run it ... /usr/local/bin/newyad (does require that yad be installed (xbps-install yad)).

Both the 'load' and run commands could be put into your .xinitrc, or alternatively within a <StartupCommand>...</StartupCommand> .jwmrc tag.

On yet another note I like to set my tray clock as also being the Menu button and show/hide desktop toggle

Code: Select all

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

Left mouse click the clock and it shows/hides the desktop, right mouse click shows the jwm menu.

[wiak]

Hello again seaside,

I've now tried build from BionicPup32 also using:

Code: Select all

./build_firstrib_rootfs_102.sh void rolling i386

and, per my immediately previous post, that also worked without any issues.

I can only imagine, at this stage, that Void Repo must have been down or glitchy, under maintenance when you tried. It's certainly all working now.

Code: Select all

[*] Configuring unpacked packages
libblkid-2.34_1: configuring ...
libblkid-2.34_1: installed successfully.
libkmod-26_3: configuring ...
libkmod-26_3: installed successfully.
eudev-3.2.8_2: configuring ...
Updating udev hardware database ...
Updating udev(7) hwdb.bin...
eudev-3.2.8_2: installed successfully.

3 downloaded, 3 installed, 0 updated, 3 configured, 0 removed.

EDIT: I wasn't using any firstrib00.plug for above test. What did you have inside your one, seaside?

wiak

[wiak]

On a separate note attached is a sfs for tray temp (sourced from http://www.murga-linux.com/puppy/viewto ... 63#1030063). Installing that into void linux variant seems to work fine. Fake .gz suffix but that doesn't matter as you can just 'load' it as-is using

Code: Select all

unsquashfs -f -d / traytemp_1.4.sfs.gz

To run it ... /usr/local/bin/newyad (does require that yad be installed (xbps-install yad)).

Both the 'load' and run commands could be put into your .xinitrc, or alternatively within a <StartupCommand>...</StartupCommand> .jwmrc tag.

On yet another note I like to set my tray clock as also being the Menu button and show/hide desktop toggle

Code: Select all

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

Left mouse click the clock and it shows/hides the desktop, right mouse click shows the jwm menu.

Thanks rufwoof, useful stuff. I'll put link into User contributed post later (going out just now).

wiak

[wiak]

Much of this post remains the most informative and relevant, but see the latest release notes in following link for a few extra new changes:

http://www.murga-linux.com/puppy/viewto ... 39#1037639
---------------------------------------------------------------------------------------------------------

build_weedog_initramfs05_s201.sh uploaded to usual download post:

http://www.murga-linux.com/puppy/viewto ... 24#1035524

This new version is backwards compatible with old s103u version. Please always use this new s201.sh version in new builds. Testing appreciated. There are many combinations needing tested so please let me know if you come across any issues.

Bumped to s2xx.sh because of enhanced NNsfs/dir handling


CHANGES

1. Option to create "huge" initramfs05.gz, which will (automatically) contain a copy of created 01firstrib_rootfs.sfs in its /boot/initramfsNN directory.

2. Option to use a build plugin called weedog_extra_sfs.plug
That gets sourced into build_weedog_initramfs05 script immediately after mksquashfs creation of 01firstrib_rootfs.sfs
It can contain any code, but might be, for example, used to create and/or copy other NNsfs files into initramfs /boot/initramfsNN directory.

3. Option to specify mksquashfs compression parameters for creation of 01firstrib_rootfs.sfs

4. NNsfs/dir objects can be placed either:

a. Inside the initramfs /boot/initramfsNN directory (lowest priority), or

b. In bootfrom directory (medium priority), which can optionally be loaded into RAM via copy2ram grub kernel line option, or

c. In some other location (highest priority), which can be on other disk or partition). That other location is specified by grub kernel line option: altNN=path2dir (e.g. altNN=/mnt/sda2/extra_NN/wherever)

These NN object locations can contain whatever numbered NNsfs or NNdirs you wish. If same number is used in more than one of these locations, the altNN (highest priority) location ones will be used.


NOTES

If a "huge" initramfs has been built to contain 01firstrib_rootfs.sfs, that sfs will only be used (mounted) if neither bootfrom nor altNN has a 01firstrib_rootfs (sfs or dir) in it, otherwise, highest priority location will be the one used. That facility will usefully allow you to test alternative external 01firstrib_rootfs.sfs creations even when humungous initramfs05.gz is being used.

If an ever higher priority location is desired, that can be implemented by sourcing code from build-user created rdsh2.plug (which would need to call _addlayer function like the code for other locations do). An example where that even higher priority might be useful would be if you wanted to load/mount some NNsfs files via network protocols such as nfs.

For guidance prior to running the script, please consult:

Code: Select all

# ./build_weedog_initramfs05_s201.sh --help

Usage:
./build_weedog_initramfs05_sNNN.sh [OPTIONS]

-v --version    	display version information and exit
-h --help -?    	display this help and exit
distro_name		(i.e. void, ubuntu, debian, or devuan)
			auto-insert Linux distro modules/firmware into
			initramfs and output associated Linux kernel;
			all of which must be pre-installed into
			firstrib_rootfs build.

Optional second argument is mksquashfs compression (or "default")
Optional third argument is "huge" (or "default") initramfs
"huge" includes 01firstrib_rootfs.sfs inside initramfs/boot/initramfsNN
Optional fourth argument is busybox_url (in case, e.g. arm64 required)

EXAMPLES: 
./build_weedog_initramfs05_sNNN.sh void  # or debian, ubuntu, devuan etc
./build_weedog_initramfs05_sNNN.sh void "-comp lz4 -Xhc"
./build_weedog_initramfs05_sNNN.sh void default huge

wiak

[AndresC2]

Hi wiak

build_weedog_initramfs copy modules in initramfs/usr/lib/modules but in firstrib_rootfs/usr/lib/modules there are the same modules too,

is possible a symbolic link: ln -s initramfs/usr/lib/modules firstrib_rootfs/usr/lib/modules

or do not copy only move when finish install apps in firstrib_rootfs:

mv firstrib_rootfs/usr/lib/modules firstrib_rootfs_for_initramfs_sNNN/usr/lib/

thanks

[wiak]

Hi wiak

build_weedog_initramfs copy modules in initramfs/usr/lib/modules but in firstrib_rootfs/usr/lib/modules there are the same modules too,

is possible a symbolic link: ln -s initramfs/usr/lib/modules firstrib_rootfs/usr/lib/modules

or do not copy only move when finish install apps in firstrib_rootfs:

mv firstrib_rootfs/usr/lib/modules firstrib_rootfs_for_initramfs_sNNN/usr/lib/

thanks

Hi Andres,

The modules need to be copied (or indeed moved) into the initramfs in order to initially boot. Certainly in case of humungous initramfs (i.e. where initramfs contains firstrib_rootfs) the duplication could perhaps be avoided (by, for example moving them back into the firstrib_rootfs) - may be more trouble than it is worth, but I'll think about it. However, for normal initramfs , you certainly also need the modules available after the switch_root - a process which "removes recursively all files and directories on the current root filesystem", so my gut feeling is that some kind of symlink back system won't work, but I'll experiment with that at some stage, or give me details if that worked for you. Storage space on boot media is not a major concern to me, to be honest - simplicity and more so, efficiency, is what I'm looking for - so normal initramfs fine with modules in it and also in firstrib_rootfs - maybe a saving of RAM possible with humungous initramfs - late here and tired out, so will have to think about it tomorrow...

Certainly it should basically boot if modules moved rather than copied - potential problem comes after the switch_root when you definitely still need all the modules available for udev and for user to modprobe as and when they want to.

It is certainly important to understand that firstrib_rootfs is not accessible until the initramfs/init has access to the modules, so that would be a chicken before the egg type of situation if you expected to somehow link the modules from firstrib_rootfs - i.e. initramfs has to already have them so it can then access firstrib_rootfs. And firstrib_rootfs needs the modules after the switch_root has occurred. It's a different matter entirely if the drivers are already built into the kernel (such as is the case with, for example, BionicPup - but Void kernel, for example, needs modules loaded to access most media. The bootloader, of course, is what initially loads the initramfs into RAM and provides that for the kernel to access (that's my understanding anyway and I could be wrong...).

wiak

[seaside]

Hello again seaside,

I've now tried build from BionicPup32 also using:

Code: Select all

./build_firstrib_rootfs_102.sh void rolling i386

and, per my immediately previous post, that also worked without any issues.

I can only imagine, at this stage, that Void Repo must have been down or glitchy, under maintenance when you tried. It's certainly all working now.

Code: Select all

[*] Configuring unpacked packages
libblkid-2.34_1: configuring ...
libblkid-2.34_1: installed successfully.
libkmod-26_3: configuring ...
libkmod-26_3: installed successfully.
eudev-3.2.8_2: configuring ...
Updating udev hardware database ...
Updating udev(7) hwdb.bin...
eudev-3.2.8_2: installed successfully.

3 downloaded, 3 installed, 0 updated, 3 configured, 0 removed.

EDIT: I wasn't using any firstrib00.plug for above test. What did you have inside your one, seaside?

wiak

wiak,

Thank you for checking.

I've tested now with other repos and still any downloads after the first "xbps-install" line, the download gets killed. Same happens with any firstrib00.plug addons.

Code: Select all

cat << INSIDE_CHROOT | chroot firstrib_rootfs sh
xbps-install -Suy xbps-triggers base-files xbps <--eudev
***** anything below this line, the files are identified but the download is killed ****
NOTE: if packages are added to the first line eg (eudev), they all download properly. Past that line, they are killed.

Very puzzling..

Cheers,
s

[wiak]

Hello again seaside,

I've now tried build from BionicPup32 also using:

Code: Select all

./build_firstrib_rootfs_102.sh void rolling i386

and, per my immediately previous post, that also worked without any issues.

I can only imagine, at this stage, that Void Repo must have been down or glitchy, under maintenance when you tried. It's certainly all working now.

Code: Select all

[*] Configuring unpacked packages
libblkid-2.34_1: configuring ...
libblkid-2.34_1: installed successfully.
libkmod-26_3: configuring ...
libkmod-26_3: installed successfully.
eudev-3.2.8_2: configuring ...
Updating udev hardware database ...
Updating udev(7) hwdb.bin...
eudev-3.2.8_2: installed successfully.

3 downloaded, 3 installed, 0 updated, 3 configured, 0 removed.

EDIT: I wasn't using any firstrib00.plug for above test. What did you have inside your one, seaside?

wiak

wiak,

Thank you for checking.

I've tested now with other repos and still any downloads after the first "xbps-install" line, the download gets killed. Same happens with any firstrib00.plug addons.

Code: Select all

cat << INSIDE_CHROOT | chroot firstrib_rootfs sh
xbps-install -Suy xbps-triggers base-files xbps <--eudev
***** anything below this line, the files are identified but the download is killed ****
NOTE: if packages are added to the first line eg (eudev), they all download properly. Past that line, they are killed.

Very puzzling..

Cheers,
s

That is very puzzling indeed, seaside. I make builds all the time of course and that has never happened to me. Perhaps rufwoof or rockedge or someone else who frequently uses the scripts can confirm or comment.

The only thing I can suggest is that you remove these lines in the chroot part and only build up to the stage before eudev. Then, from the build directory (where your partial firstrib_rootfs has been built on you build host, run the script I provided called mount_chrootver007.sh;

mount_chrootver007.sh and umount_chrootver007.sh scripts are provided for download with other utilities here:

http://www.murga-linux.com/puppy/viewto ... 57#1028957


that chroots into the build and from inside there, try manually to install extra packages using xbps-install. That is, run:

Code: Select all

./mount_chrootver007.sh

then inside the resulting chroot, run say command:

Code: Select all

xbps-install -S file

to see if you can install the 'file' package, or whatever, and you could also try then to xbps-install eudev, to see what error messages you are getting, if so. Once finished installing, or attempting to install package, you just enter 'exit' to leave the chroot, and then clean up the mounts that were used with the chroot by runniing script:

Code: Select all

./umount_chrootver007.sh

Sorry, I can't suggest more at present, other than the above, as well as asking you to see if you get any error messages you could report back. And also looking for comments from others here on the thread.

EDIT: Actually could you PM me the exact build_firstrib_rootfs_102.sh script you are using (tho I guess if pristine downloaded one should be same exactly as the one I use...). I certainly would like to get to the bottom of this in case there is an issue that simply doesn't happen on my own system.

I can't imagine that Void Linux repo(s) are all locking you out for some reason! But why on earth your void install download is getting 'Killed' during processing is really weird to me.

EDIT2: I forgot to ask what host system you are building on, in case their is some host-related issue we need to get to the bottom of. Then I would suggest trying a build from a pristine-built system known to work fine as a host (such as BionicPup32). And if that still fails - if you have a second (different model) of computer you could try it on...

wiak

[wiak]

Hi wiak

build_weedog_initramfs copy modules in initramfs/usr/lib/modules but in firstrib_rootfs/usr/lib/modules there are the same modules too,

is possible a symbolic link: ln -s initramfs/usr/lib/modules firstrib_rootfs/usr/lib/modules

or do not copy only move when finish install apps in firstrib_rootfs:

mv firstrib_rootfs/usr/lib/modules firstrib_rootfs_for_initramfs_sNNN/usr/lib/

thanks

Now that I'm awake, I've been thinking about your comment more Andres. Actually, some time back I did many tests to see if RAM use could be reduced. I went as far as manually removing all of initramfs directories (including modules) prior to the switch_root (despite man switch_root saying switch_root itself recursively removes everything automatically anyway). Made no difference. Fact is, initramfs needs modules inside it, and later, firstrib_rootfs needs modules inside it. But I don't think the modules originally loaded by initramfs remain stored after the switch_root, so the issue you imagine, doesn't exist in practice - I could be wrong, but that's what my own tests suggested and what the docs tell me. I could try such tests again (trying moves and symlinks and so on) but that's a lot of work without I personally feel much likelihood of achieving anything - but if you find out in tests of your own otherwise, please of course let me know. Linux is pretty clever at how it handles RAM and cache and switch_root is carefully crafted to remove what is unneeded.

The other thing i did was to check alternative initramfs boots (using initramfs from Linux From Scratch and also checking RAM used by other frugal installed systems available here on the forum - in each case WeeDog came out just as good and usually better in terms of RAM available once booted. Without analysing how switch_root performs its magic in C I can't determine more about it. But please try the mods you are thinking of and see if you can save anything resource-wise in the end - I am certainly open to whatever results you can bring show me. But I have to say that resource usage by WeeDog seems already to be very good/frugal, and it seems to me the doubling-up you suggest isn't actually happening in RAM in practice - not that I have observed thus far in practice anyway.

So please compare results also with other systems that use aufs or overlayfs to see if any use significantly less resources on running. I would be surprised if everyone made the same mistakes in their initramfs designs so that would be a good indication that all is well with WeeDog initramfs too (or otherwise) - that's also the reason I checked with such comparisons earlier myself, and found nothing untoward.

EDIT: uncompressed size of /usr/lib/modules is around 70MiB. When you check RAM free in WeeDog (after clearing caches with 'sync && echo 3 > /proc/sys/vm/drop_caches) you will find total RAM that has been used up is less than that in default build (and is accountable by the RAM taken up by modprobe loaded modules for a large part). Clearly initramfs/usr/lib/modules has not been left behind stored in RAM after the switch_root. All seems well to me. Yes, in a humungous initramfs build, the initramfs itself contains the modules and so does the 01firstrib_rootfs.sfs, but that is of no real consequence aside from slightly larger initramfs05.gz than it could be (though impractical, I'd say, to arrange that differently), and it has no effect, as far as I see, on final RAM used/available, so really fine as things are I think.

wiak