rockedge wrote:I am wondering how the kernel upgrades are used in WeeDog.
_
Good question. The thought had crossed my mind too.
Yes, you certainly need to get the appropriate modules into 01firstrib_rootfs.sfs and also to rebuild the initramfs05.gz so these modules are also available in there (unless using 00firstrib_firmware_modules.sfs arrangement, in which case you'd want to rebuild that, albeit only with modules inside, not firmware - the sfs name was used because previoulsy used for Bionic zdrv firmware_modules, but with Void it only needs to contain modules if using it). However, you won't lose any of your previous work via the above procedures since that remains untouched.
EDIT: At the moment what I'd do is (untested right now):
EDIT2: Currently working on a script and testing it (current code printed towards end of this post FYI but, as I say, not guaranteed yet since just under test)
EDIT3: yes, this is tricky... There are issues with vkpurge - doesn't really work as expected in chroot, and though you 'could' upgrade kernel (new one ending up, for example, in upper_changes), the initramfs would also have to be upgraded in sync with that (since needs new kernel modules); I'm continuing to look into this less-than-trivial issue. Below is not a complete answer at all I think.
After CHECKING you really want to proceed (especially since about to delete an existing initramfs05.gz)... remove any existing:
firstrib_rootfs_for_initramfs_sNNN
uncompressed firstrib_rootfs
initramfs05.gz
vmlinuzNNNNN
Though I'd suggest making backups first, either manually, or using code such as:
Code: Select all
[ -d squashfs-root ] && rm -rf squashfs-root
[ -d firstrib_rootfs_for_initramfs_sNNN ] && mv firstrib_rootfs_for_initramfs_sNNN BKUPfirstrib_rootfs_for_initramfs_sNNN
[ -d firstrib_rootfs ] && mv firstrib_rootfs BKUPfirstrib_rootfs
[ -f 01firstrib_rootfs.sfs ] && mv 01firstrib_rootfs.sfs BKUP01firstrib_rootfs.sfs
[ -f initramfs05.gz ] && mv initramfs05.gz BKUPinitramfs05.gz
I suggest putting BKUP at front of name as above, rather than at end, so has effect also of NNlayer disabled. Also alphabetically groups all the backups together in file list.
Then:
1. unsquash the 01filesystem.sfs (or its backup) and make sure the resultant squashfs-root folder is renamed to firstrib_rootfs. That is:
Code: Select all
unsquashfs BKUP01firstrib_rootfs.sfs
mv squashfs-root firstrib_rootfs
EDIT NOTE WELL: Don't do WRONG 2 and WRONG 3 immediately below... you instead need to remove the current kernel using vkpurge, inside a chroot, as I detail later (just done a quick try)
WRONG: 2. rm -rf firstrib_rootfs/usr/lib/modules # DON'T DO THIS
WRONG: 3. rm -rf firstrib_rootfs/boot/vmlinuz* # DON'T DO THIS
CORRECT (I think... but still testing...):
2.
to chroot into firstrib_rootfs, and from there:
3. Now you could check current kernel(s) installed using, say (-l is small ell). However, since going to use vkpurge in next step, this check is probably unnecessary in practice:
EDIT3: Better is:
Code: Select all
xbps-query --regex -s '^linux[0-9.]+-[0-9._]+'
You need to examine the resulting list for the kernel name (you can try the meta-package/template name but maybe need main kernel version name; I tested but forget).
and then (untested but I think it is correct - thanks rockedge):
(not sure if you also need to remove previous firmware at this stage - I expect you don't need to).
4. followed by installing, for example, the current latest kernel with:
which should install the new kernel and its related modules
Follow by:
5.
, and then
to clean up the chroot mounts, and lastly:
6.
Code: Select all
./build_weedog_initramfs05_XXX.sh void [options]
to rebuild the initramfs05.gz with the new modules inside it, which also outputs the new kernel for booting via grub menu.lst frugal arrangement, and a new 01firstrib_rootfs.sfs as usual
I guess you could write a simple script to automate the above (using for example a cat heredocument, similar to that used in build firstrib rootfs, to automate the xbps-install -Suy linux part done inside the chroot). Easy enough to do above manually though, and sometimes its best not to over-automate in case something odd happens...
I'm currently trying the following script - I'll post later if successful
EDIT: I think the following needs more work... There are issues with vkpurge I briefly mention in following posts. vkpurge is a shell script in /usr/bin that was designed to be used on running Void system (so not from say a chroot running on other Linux host).
Code: Select all
#!/bin/sh
# rebuild_weedog_void_frugal_001 with current kernel/modules
# Revision 0.0.1 Date: 10 Oct 2019
# Copyright wiak 10 Oct 2019+; Licence MIT (aka X11 license)
#### variables-used-in-script:
# script commandline arguments $1 $2 $3 $4
# "$1" is distro (e.g. void); "$2" is optional mksquashfs compression (or "default");
# "$3" is optional "huge" initramfs (or "default); $4 is optional busybox url to use
kernel="$1"
case "$1" in
'-v'|'--version') echo "Rebuild WeeDog Void Frugal Revision 0.0.1";exit;;
'-h'|'--help'|'-?') printf '
Usage:
./rebuild_weedog_void_frugal_001.sh void [OPTIONS]
-v --version display version information and exit
-h --help -? display this help and exit
First argument void is required to undertake rebuild
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)
fourth argument can optionally also be "default"
EXAMPLES:
./rebuild_weedog_void_frugal_NNN.sh void
./rebuild_weedog_void_frugal_NNN.sh void "-comp lz4 -Xhc"
./rebuild_weedog_void_frugal_NNN.sh void default huge
For more details read the attached README and/or
visit: https://github.com/firstrib/firstrib
';exit;;
'') echo 'First argument must be distro name: void';exit;;
esac
[ -d squashfs-root ] && rm -rf squashfs-root
[ -d firstrib_rootfs_for_initramfs_sNNN ] && mv firstrib_rootfs_for_initramfs_sNNN BKUPfirstrib_rootfs_for_initramfs_sNNN
[ -d firstrib_rootfs ] && mv firstrib_rootfs BKUPfirstrib_rootfs
[ -f 01firstrib_rootfs.sfs ] && mv 01firstrib_rootfs.sfs BKUP01firstrib_rootfs.sfs
[ -f initramfs05.gz ] && mv initramfs05.gz BKUPinitramfs05.gz
echo 'Unsquashing BKUP01firstrib_rootfs.sfs ... Please wait ...'
unsquashfs BKUP01firstrib_rootfs.sfs
mv squashfs-root firstrib_rootfs
# bind mount host virtual filesystes required for chroot into firstrib_rootfs to work on host system
# as in mount_chrootXXX.sh
mkdir -p firstrib_rootfs/run/udev
mount --bind /proc firstrib_rootfs/proc && mount --bind /sys firstrib_rootfs/sys && mount --bind /dev firstrib_rootfs/dev && mount -t devpts devpts firstrib_rootfs/dev/pts && mount --bind /tmp firstrib_rootfs/tmp && mount --bind /run/udev firstrib_rootfs/run/udev && cp /etc/resolv.conf firstrib_rootfs/etc/resolv.conf
# The following commands gets done inside firstrib_rootfs (via here_document pipe to chroot):
cat << INSIDE_CHROOT | chroot firstrib_rootfs sh
# Remove all old kernel/modules
vkpurge rm all
echo 'Installing current kernel and modules ... Please wait ...'
xbps-install -Suy linux
exit
INSIDE_CHROOT
# Clean up the bind mounts that were used for the chroot
# as in umount_chrootXXX.sh:
umount -l firstrib_rootfs/proc && umount -l firstrib_rootfs/sys && umount -l firstrib_rootfs/dev/pts && umount -l firstrib_rootfs/dev && umount -l firstrib_rootfs/tmp && umount -l firstrib_rootfs/run/udev
printf "\nAt this stage you can manually modify firstrib_rootfs if you wish
Once you are ready to complete the rebuild press Enter to continue
"
read go
# Rebuild initramfs05.gz, 01firstrib_rootfs.sfs and output new vmlinuzXXX
echo "Executing $0 $@ ... Please wait ..."
exec ./build_weedog_initramfs05_s204.sh "$@"
exit
-----------------------------------------------
As far as my current efforts are concerned, Arch pacman reminds me of xbps a bit but pacman static isn't independent (it requires other code bits and pieces to be made available for it) like xbps static so I'm probably going to firstrib include it using archbootstrap or whatever it is called.
wiak