manjaro-tools issueshttps://gitlab.manjaro.org/tools/development-tools/manjaro-tools/-/issues2024-03-28T04:40:10Zhttps://gitlab.manjaro.org/tools/development-tools/manjaro-tools/-/issues/344Fix for an error and Warning in the mkinitcpio command in the prepare_initram...2024-03-28T04:40:10ZphoepsilonixFix for an error and Warning in the mkinitcpio command in the prepare_initramfs function in utils-iso-boot.sh.(WARNING: errors were encountered during the build. The image may not be complete.)```
==> Prepare [/iso/boot]
--> overlayfs mount: [/var/lib/manjaro-tools/buildiso/gnome/x86_64/bootfs]
-> Copying initcpio ...
<skip>
==> Creating xz-compressed initcpio image: '/boot/initramfs.img'
WARNING: errors were encounte...```
==> Prepare [/iso/boot]
--> overlayfs mount: [/var/lib/manjaro-tools/buildiso/gnome/x86_64/bootfs]
-> Copying initcpio ...
<skip>
==> Creating xz-compressed initcpio image: '/boot/initramfs.img'
WARNING: errors were encountered during the build. The image may not be complete.
```
One reason for this is that the symbolic links for libnss_files.so.2 and libnss_dns.so.2 do not exist in the glibc package.
We suggest commenting out the add_symlink in in miso_pxe_common.
```diff
diff --git a/initcpio/install/miso_pxe_common b/initcpio/install/miso_pxe_common
index eec9a7e..3d935f1 100644
--- a/initcpio/install/miso_pxe_common
+++ b/initcpio/install/miso_pxe_common
@@ -8,9 +8,9 @@ build() {
add_binary /usr/lib/initcpio/ipconfig /bin/ipconfig
# Add hosts support files+dns
- add_symlink /usr/lib/libnss_files.so.2 $(readlink /usr/lib/libnss_files.so.2)
+ #add_symlink /usr/lib/libnss_files.so.2 $(readlink /usr/lib/libnss_files.so.2)
add_binary $(readlink -f /usr/lib/libnss_files.so.2)
- add_symlink /usr/lib/libnss_dns.so.2 $(readlink /usr/lib/libnss_dns.so.2)
+ #add_symlink /usr/lib/libnss_dns.so.2 $(readlink /usr/lib/libnss_dns.so.2)
add_binary $(readlink -f /usr/lib/libnss_dns.so.2)
add_dir /etc
```https://gitlab.manjaro.org/tools/development-tools/manjaro-tools/-/issues/335Locale en_IL should not exist - it's he_IL or en_US, en_GB etc.2022-03-02T00:39:55ZGalia BahatLocale en_IL should not exist - it's he_IL or en_US, en_GB etc.I've installed Manjaro with just English, and that was fine. When I added Hebrew on the Language menu (KDE settings > Regional settings > Language) some system text, like Pidgin's menus, then defaulted to Hebrew, even though English was ...I've installed Manjaro with just English, and that was fine. When I added Hebrew on the Language menu (KDE settings > Regional settings > Language) some system text, like Pidgin's menus, then defaulted to Hebrew, even though English was set as my main language and that had never changed.
I eventually found out that the environment variable LANG + /etc/locale.gen + /etc/locale.conf defined my locale/lang as en_IL, which does not exist AFAIK. Hebrew should be he_IL. Changing en_IL into en_US fixed everything.
Pidgin must've fell back to the secondary language, and when I didn't have one fell back to en_US.
So what I'm suggesting is:
1. Change en_IL into he_IL. I'm not sure where that is set in the source code, couldn't find it.
2. Show an error on the Languages menu if a locale is not found and fallbacks are used.
I'm not 100% sure this is the place to post this issue, but I found similar tickets here.https://gitlab.manjaro.org/tools/development-tools/manjaro-tools/-/issues/334Patch to handle /etc/resolv.conf is a symlink2022-01-18T13:45:36ZThenujan-0Patch to handle /etc/resolv.conf is a symlinkIn order to avoid the following error message i created a symlink of /run/NetworkManager/resolv.conf in /etc/resolv.conf
https://www.reddit.com/r/Windscribe/comments/cn2qfb/etcresolvconf_is_not_a_symlink_this_may_break_dns/
But when us...In order to avoid the following error message i created a symlink of /run/NetworkManager/resolv.conf in /etc/resolv.conf
https://www.reddit.com/r/Windscribe/comments/cn2qfb/etcresolvconf_is_not_a_symlink_this_may_break_dns/
But when using the manjaro-chroot script it fails to get my internet connection to chroot and shows mount point is a symbolic link to nowhere so i modified the script to check if /etc/resolv.conf is a symbolic link and if it is a symbolic link then use /run/NetworkManager/resolv.conf instead .
And now the script also shows the internet is not connected so internet access will not be available in chroot .
```
sudo manjaro-chroot -a ✔
[sudo] password for thenujan:
==> Mounting (Ubuntu) [/dev/sda2]
--> mount: [/mnt]
your /etc/resolv.conf is a symlink so using /run/NetworkManager/resolv.conf instead
root@manjaro-minion:/#
```
```
sudo manjaro-chroot -a 127 ✘ 51s
==> Mounting (Ubuntu) [/dev/sda2]
--> mount: [/mnt]
Internet is not connected you will not have internet connectivity inside chroot
root@manjaro-minion:/#
```
code that i added to util-mount.sh checks if connected to the internet by pinging google and if the internet is not connected then it doesn't mount /etc/resolv.conf or the /run/NetworkManager/resolv.conf .
if it is connected then it checks if the /etc/resolv.conf is a symlink,if it isnt a symlink then it mounts that file if it is a symlink,it uses /run/NetworkManager/resolv.conf instead
code that I added to manjaro-chroot does the same described above but when using manjaro-chroot manually
[da260aa088.patch](/uploads/f66a5b6eb23da733e816b0abf4006baa/da260aa088.patch)https://gitlab.manjaro.org/tools/development-tools/manjaro-tools/-/issues/331buildiso fails because of missing packages due to outdated Packages-Mhwd2021-05-21T12:02:04ZAbuildiso fails because of missing packages due to outdated Packages-MhwdPossibly related issue
https://gitlab.manjaro.org/tools/development-tools/manjaro-tools/-/issues/325
This is what I get when running `buildiso -p myi3 -k linux510`:
```
error: target not found: catalyst-utils
error: target not found: l...Possibly related issue
https://gitlab.manjaro.org/tools/development-tools/manjaro-tools/-/issues/325
This is what I get when running `buildiso -p myi3 -k linux510`:
```
error: target not found: catalyst-utils
error: target not found: linux510-catalyst
error: target not found: linux510-nvidia-340xx
error: target not found: nvidia-340xx-utils
error: target not found: lib32-catalyst-utils
error: target not found: lib32-nvidia-340xx-utils
error: target not found: pangox-compat
error: target not found: catalyst-utils
error: target not found: linux510-catalyst
error: target not found: linux510-nvidia-340xx
error: target not found: nvidia-340xx-utils
error: target not found: lib32-catalyst-utils
error: target not found: lib32-nvidia-340xx-utils
error: target not found: pangox-compat
-> Copying mhwd package cache ...
building file list ... done
sent 17 bytes received 12 bytes 58.00 bytes/sec
total size is 0 speedup is 0.00
==> ERROR: File '/var/lib/manjaro-tools/buildiso/myi3/x86_64/mhwdfs/opt/mhwd/pkg/*pkg.tar*' not found.
==> No packages modified, nothing to do.
==> ERROR: A failure occurred in make_image_mhwd().
Aborting...
--> overlayfs umount: [/var/lib/manjaro-tools/buildiso/myi3/x86_64/mhwdfs]
==> ERROR: File /var/lib/manjaro-tools/buildiso/myi3/x86_64/mhwdfs/opt/mhwd/pkg/'*pkg.tar*' not found.
```
After digging a bit, I found that `buildiso -i` pulls `v18.0` profiles, where `Packages-Mhwd` contains entries that are no longer in the repos.
See:
https://gitlab.manjaro.org/tools/development-tools/manjaro-tools/-/blob/master/lib/util.sh#L328
https://gitlab.manjaro.org/tools/development-tools/manjaro-tools/-/blob/master/lib/util.sh#L838
Pulling v20.2 profiles manually fixes this issue.https://gitlab.manjaro.org/tools/development-tools/manjaro-tools/-/issues/328Stops at "( 5/35) Creating temporary files" when built on a system with kerne...2021-01-02T22:40:52ZTioStops at "( 5/35) Creating temporary files" when built on a system with kernel 5.10Using: `buildiso -p gnome` I am getting:
```
( 2/35) Registering binary formats...
Skipped: Current root is not booted.
( 3/35) Reloading system manager configuration...
Skipped: Current root is not booted.
( 4/35) Updating udev har...Using: `buildiso -p gnome` I am getting:
```
( 2/35) Registering binary formats...
Skipped: Current root is not booted.
( 3/35) Reloading system manager configuration...
Skipped: Current root is not booted.
( 4/35) Updating udev hardware database...
( 5/35) Creating temporary files..
```
And it simply stops there. So far for hours. I am not sure it does anything. All worked fine before the latest Manjaro updates.https://gitlab.manjaro.org/tools/development-tools/manjaro-tools/-/issues/327Options to set enabled calamares modules in profile.conf2020-10-28T22:17:47ZMatti HyttinenOptions to set enabled calamares modules in profile.confIt would be nice to be able to enable and disable certain calamares modules in profile.conf. This would come in handy for using gnome-initial-setup and possibly using the package selection module in the future.It would be nice to be able to enable and disable certain calamares modules in profile.conf. This would come in handy for using gnome-initial-setup and possibly using the package selection module in the future.Bernhard LandauerBernhard Landauerhttps://gitlab.manjaro.org/tools/development-tools/manjaro-tools/-/issues/325buildiso fails with kernel 5.8.x because of missing nvidia packages2021-05-21T12:02:06ZTNT2kbuildiso fails with kernel 5.8.x because of missing nvidia packagesHi, running `buildiso -f -p xfce -b stable -t ~/iso_out`
results in
```Root : /
Conf File : /etc/pacman.conf
DB Path : /var/lib/pacman/
Cache Dirs: /var/cache/pacman/pkg/
Hook Dirs : /usr/share/libalpm/hooks/ /etc/pacman.d/hoo...Hi, running `buildiso -f -p xfce -b stable -t ~/iso_out`
results in
```Root : /
Conf File : /etc/pacman.conf
DB Path : /var/lib/pacman/
Cache Dirs: /var/cache/pacman/pkg/
Hook Dirs : /usr/share/libalpm/hooks/ /etc/pacman.d/hooks/
Lock File : /var/lib/pacman/db.lck
Log File : /var/log/pacman.log
GPG Dir : /etc/pacman.d/gnupg/
Targets : linux54-bbswitch linux54-broadcom-wl linux54-zfs zfs-utils linux54-virtualbox-guest-modules linux54-headers zfs-dkms libva-intel-driver libva-mesa-driver libva-vdpau-driver lib32-libva-vdpau-driver libxaw libxpm libxvmc mesa-vdpau lib32-mesa-vdpau lib32-libxvmc lib32-primus linux54-nvidia-455xx nvidia-455xx-utils lib32-nvidia-455xx-utils opencl-mesa open-vm-tools primus bumblebee nvidia-prime gtkmm3 spice-vdagent virtualbox-guest-utils vulkan-radeon lib32-vulkan-radeon vulkan-intel lib32-vulkan-intel xf86-input-vmmouse xf86-video-amdgpu xf86-video-ati xf86-video-dummy xf86-video-fbdev xf86-video-intel xf86-video-nouveau xf86-video-openchrome xf86-video-sisusb xf86-video-vesa xf86-video-vmware xf86-video-voodoo
:: Synchronizing package databases...
downloading core.db...
downloading extra.db...
downloading community.db...
downloading multilib.db...
error: target not found: linux54-nvidia-455xx
error: target not found: nvidia-455xx-utils
error: target not found: lib32-nvidia-455xx-utils
error: target not found: linux54-nvidia-455xx
error: target not found: nvidia-455xx-utils
error: target not found: lib32-nvidia-455xx-utils
-> Copying mhwd package cache ...
building file list ... done
sent 17 bytes received 12 bytes 58.00 bytes/sec
total size is 0 speedup is 0.00
==> ERROR: File '/var/lib/manjaro-tools/buildiso/xfce/x86_64/mhwdfs/opt/mhwd/pkg/*pkg.tar*' not found.
==> No packages modified, nothing to do.
==> ERROR: A failure occurred in make_image_mhwd().
Aborting...
--> overlayfs umount: [/var/lib/manjaro-tools/buildiso/xfce/x86_64/mhwdfs]
```
Before the kernel update, everything worked. Can you update the script for the new packages?https://gitlab.manjaro.org/tools/development-tools/manjaro-tools/-/issues/323Buildiso doesn't work in docker2021-06-07T03:53:26ZNickolay LeschevBuildiso doesn't work in dockerHello!
I am not experienced in CI/CD automatization, but I am trying to make auto build the iso in docker, which runs in CircleCI machine. I use machine executor in CircleCI to start docker in privileged mode, but buildiso still gives a...Hello!
I am not experienced in CI/CD automatization, but I am trying to make auto build the iso in docker, which runs in CircleCI machine. I use machine executor in CircleCI to start docker in privileged mode, but buildiso still gives an error: ![2020-05-03_May3829-1000x363](/uploads/d902ad75d92d79e45eeb29357cdf76bb/2020-05-03_May3829-1000x363.png)
I use the next command to start the docker container:
```
docker run \
--name manjarolinux-build \
--mount type=bind,src="$(pwd)",dst="/home/isobuilder/project" \
--workdir "/home/isobuilder/project" \
--cap-add SYS_ADMIN \
--entrypoint "./install.sh" \
demysteriismundi/manjarolinux-build:stable -b
```
I hope you will tell me the way to solve this problem. Maybe CircleCI not suitable for such purposes so what can I use for that?https://gitlab.manjaro.org/tools/development-tools/manjaro-tools/-/issues/322How can I contribute with a patch?2020-10-31T08:59:27ZChristian FinnbergHow can I contribute with a patch?I have been unable to find information about how can I contribute with a patch to Manjaro-tools. I can't fork it to make a merge request and I don't know to whom should I send it then to review. Thanks!I have been unable to find information about how can I contribute with a patch to Manjaro-tools. I can't fork it to make a merge request and I don't know to whom should I send it then to review. Thanks!https://gitlab.manjaro.org/tools/development-tools/manjaro-tools/-/issues/321[buildpkg] splitting packages not work if present multiple 'arch' array2020-05-01T15:30:18ZStefano Capitani[buildpkg] splitting packages not work if present multiple 'arch' arrayWe have an old issue present in `buildpkg` function: not working if the multiple PKGBUILD contain a mix of architecture array: in our case if we mix `arch=any` and `arch=x86_64`.
The problem is [here](https://gitlab.manjaro.org/tools/dev...We have an old issue present in `buildpkg` function: not working if the multiple PKGBUILD contain a mix of architecture array: in our case if we mix `arch=any` and `arch=x86_64`.
The problem is [here](https://gitlab.manjaro.org/tools/development-tools/manjaro-tools/-/blob/master/lib/util-pkg-chroot.sh#L157-171). The `post_build` function not recognize the array if is present ( as normally ) inside the `package_XXXX()` function of the `PKGBUILD`. As i understand is because a variable into a function can't be exported in other scripts . I have tried this approach but without success. I have at the end of the idea. Following the approach of arch is hard because use more scripts and library function into makepkg process to parse e divide the PKGBUILD for any splitted package ( if understand correctly their approach )
```
post_build(){
source PKGBUILD
if [[ ${#pkgname[@]} > 1 ]]; then
archs=$(grep 'arch=' PKGBUILD | cut -d "=" -f2- | sed 's/.//;s/.$//' | tr '\n' ' ' | sed 's/^/(/;s/$/)/')
echo $archs
s=${#archs[@]}
echo $s
counter=0
echo $counter
while [[ $counter -lt $s ]]; do
local ext='pkg.tar.zst' tarch ver src
for pkg in ${pkgname[$counter]}; do
case ${archs[$counter]} in
any) tarch='any' ;;
*) tarch=${target_arch}
esac
local ver=$(get_full_version "$pkg") src
src=$pkg-$ver-$tarch.$ext
move_to_cache "$src"
done
local name=${pkgbase:-$pkgname}
archive_logs "$name"
counter=$(( $counter + 1 ))
done
else
local ext='pkg.tar.zst' tarch ver src
for pkg in ${pkgname[@]}; do
case $arch in
any) tarch='any' ;;
*) tarch=${target_arch}
esac
local ver=$(get_full_version "$pkg") src
src=$pkg-$ver-$tarch.$ext
move_to_cache "$src"
done
local name=${pkgbase:-$pkgname}
archive_logs "$name"
fi
```https://gitlab.manjaro.org/tools/development-tools/manjaro-tools/-/issues/318Request: not check /etc/lsb-release2020-03-05T22:08:53ZSteven LeeRequest: not check /etc/lsb-releaseCurrently, if there is no `/etc/lsb-release`, `manjaro-chroot` will report error.
Wish to not checking this, because it is not necessary for the problem this tool is going to solve.Currently, if there is no `/etc/lsb-release`, `manjaro-chroot` will report error.
Wish to not checking this, because it is not necessary for the problem this tool is going to solve.https://gitlab.manjaro.org/tools/development-tools/manjaro-tools/-/issues/316sourcing makepkg.conf2019-12-25T11:52:19ZGhost Usersourcing makepkg.confInstead of hardcoded pkg extension - use the env variable from makepkg.conf
e.g. from signpkgs.in
find $PWD -maxdepth 1 -name '*${PKGEXT}' -exec signfile {} \;
This may be because I don't fully understand the tools but the followi...Instead of hardcoded pkg extension - use the env variable from makepkg.conf
e.g. from signpkgs.in
find $PWD -maxdepth 1 -name '*${PKGEXT}' -exec signfile {} \;
This may be because I don't fully understand the tools but the following seems a little off - why is the user overwritten by the default?
* checkpkg.in - lines 22 and 23
* signfile.in - line 20 and 21
```
load_vars "$HOME/.makepkg.conf"
load_vars /etc/makepkg.conf
```
Everywhere else the loading of makepkg.conf reads like
```
load_vars "$USER_HOME/.makepkg.conf" || load_vars /etc/makepkg.conf
```
What is the rationale of having a local .makepkg.conf and overwrite any changes made to the local config with the default config?
https://gitlab.manjaro.org/tools/development-tools/manjaro-tools/-/issues/314Netbooting Manjaro, currently failing due to no memdisk support2019-10-18T20:44:09ZSkylerNetbooting Manjaro, currently failing due to no memdisk supportThis is basically a part 2 of the issue in the archived repository at Github (https://github.com/manjaro/manjaro-tools/issues/177).
I would kindly ask to either:
1) Restore PXE related settings, that were removed in a commit (42e0735b7...This is basically a part 2 of the issue in the archived repository at Github (https://github.com/manjaro/manjaro-tools/issues/177).
I would kindly ask to either:
1) Restore PXE related settings, that were removed in a commit (42e0735b772d121b008a0044ad7db3ff56709a25), two years ago.
2) Host a extracted ISO that's always up-to-date, when a new ISO gets published.
3) Publish a kernel we can use to netboot with.https://gitlab.manjaro.org/tools/development-tools/manjaro-tools/-/issues/313buildiso using a buildlist2019-09-14T08:44:35ZGhost Userbuildiso using a buildlistWhen using buildiso with a list and using the `-f` argument only the first in the queue is build with the extra packages.
Sample build list name `test.list`
```
lxde
lxqt
openbox
```
execute with -q - just to show what would be done
```...When using buildiso with a list and using the `-f` argument only the first in the queue is build with the extra packages.
Sample build list name `test.list`
```
lxde
lxqt
openbox
```
execute with -q - just to show what would be done
```
~ >>> buildiso -p test -f -q
[sudo] password for fh:
==> manjaro-tools
-> version: 0.15.9
-> config: ~/.config/manjaro-tools/manjaro-tools.conf
==> PROFILE:
-> gitlab brach: master
-> build_lists: community|default|test|manjaro|sonar
-> build_list_iso: test
-> is_build_list: true
==> OPTIONS:
-> arch: x86_64
-> branch: stable
-> kernel: linux52
==> ARGS:
-> clean_first: true
-> images_only: false
-> iso_only: false
-> persist: false
==> DIST SETTINGS:
-> dist_name: Manjaro
-> dist_release: 18.1.0
-> dist_codename: Juhraya
==> ISO INFO:
-> iso_label: MJRO1810
-> iso_compression: xz
==> BUILD QUEUE:
--> Profile: [lxde]
-> iso_file: manjaro-lxde-18.1.0-stable-x86_64.iso
--> Profile: [lxqt]
-> iso_file: manjaro-lxqt-18.1.0-stable-minimal-x86_64.iso
--> Profile: [openbox]
-> iso_file: manjaro-openbox-18.1.0-stable-minimal-x86_64.iso
```https://gitlab.manjaro.org/tools/development-tools/manjaro-tools/-/issues/312Bug `manjaro-chroot -a`2020-09-02T18:44:10Zn0neBug `manjaro-chroot -a``manjaro-chroot -a`
gives out a bug where Manjaro-Linux is found at 0). [0-0]
Pressing 0 results in an error, whereby pressing 1 (although not an option) is resulting in the desired outcome.`manjaro-chroot -a`
gives out a bug where Manjaro-Linux is found at 0). [0-0]
Pressing 0 results in an error, whereby pressing 1 (although not an option) is resulting in the desired outcome.https://gitlab.manjaro.org/tools/development-tools/manjaro-tools/-/issues/311Cannot use buildpkg for some packages from AUR2019-08-28T11:44:59ZRomanCannot use buildpkg for some packages from AURHello,
Cannot build some packages, which extract AppImage inside `prepare()` function, using buildpkg utility. In the same time, makepkg does the job very well.
```
buildpkg -p jitsi-meet-electron
--> Loading compiler settings: x86_64
...Hello,
Cannot build some packages, which extract AppImage inside `prepare()` function, using buildpkg utility. In the same time, makepkg does the job very well.
```
buildpkg -p jitsi-meet-electron
--> Loading compiler settings: x86_64
==> Updating chroot for [stable] (x86_64)...
:: Synchronizing package databases...
core is up to date
extra is up to date
community is up to date
:: Starting full system upgrade...
there is nothing to do
--> Time chroot_init: 0.03 minutes
==> Start building [jitsi-meet-electron]
==> Making package: jitsi-meet-electron 1.1.1-1 (Fri 23 Aug 2019 11:45:14 PM CEST)
==> Retrieving sources...
-> Downloading jitsi-meet-x86_64.AppImage...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 616 0 616 0 0 602 0 --:--:-- 0:00:01 --:--:-- 602
100 58.5M 100 58.5M 0 0 9046k 0 0:00:06 0:00:06 --:--:-- 12.2M
-> Found jitsi-meet.desktop
-> Found jitsi-meet
-> Found LICENSE
==> Validating source files with md5sums...
jitsi-meet-x86_64.AppImage ... Passed
jitsi-meet.desktop ... Passed
jitsi-meet ... Passed
LICENSE ... Passed
--> Setting mirrorlist branch: stable
==> Making package: jitsi-meet-electron 1.1.1-1 (Fri 23 Aug 2019 09:45:21 PM UTC)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
-> Found jitsi-meet-x86_64.AppImage
-> Found jitsi-meet.desktop
-> Found jitsi-meet
-> Found LICENSE
==> Validating source files with md5sums...
jitsi-meet-x86_64.AppImage ... Passed
jitsi-meet.desktop ... Passed
jitsi-meet ... Passed
LICENSE ... Passed
==> Extracting sources...
==> Starting prepare()...
/startdir/PKGBUILD: line 26: /build/jitsi-meet-electron/src/jitsi-meet-x86_64.AppImage: No such file or directory
==> ERROR: A failure occurred in prepare().
Aborting...
```https://gitlab.manjaro.org/tools/development-tools/manjaro-tools/-/issues/310Add support for znx overlays.2020-02-13T22:41:08ZGhost UserAdd support for znx overlays.`znx` specifies a scheme for allowing the user to save data in the storage device. The initramfs is responsible for mounting whichever directories the user requests with the `OVERLAYFS` driver (thus, allowing data persistence between reb...`znx` specifies a scheme for allowing the user to save data in the storage device. The initramfs is responsible for mounting whichever directories the user requests with the `OVERLAYFS` driver (thus, allowing data persistence between reboots).
I'm unable to fork the project, so I had to write the solutions here.
One file should be added, and one altered.
A new initramfs hook: `miso_znx_overlays`.
```shell
mnt_znx_overlays () {
# Persistent storage directory.
zpd=/run/miso/img_dev/${img_loop%/*}/DATA
# Mount the requested overlays.
for k in $(printf "$ZNX_OVERLAYS" | sed 's/,/ /g'); do
mkdir -p \
$1/$k \
$zpd/$k \
$zpd/.znx-tmp/$k.w
mount -t overlay \
-o lowerdir=$1/$k \
-o upperdir=$zpd/$k \
-o workdir=$zpd/.znx-tmp/$k.w \
. $1/$k
done
}
znx_mount_handler () {
newroot="$1"
miso_loop_mount_handler $newroot
[ "$ZNX_OVERLAYS" ] &&
mnt_znx_overlays $newroot
}
run_hook () {
[ "$copytoram" == "y" -a "$ZNX_OVERLAYS" ] && {
echo "WARNING: 'copytoram' is set. znx overlays will not be available."
return
}
[ "$img_loop" -a "$ZNX_OVERLAYS" ] && {
img_dev=$(find_dev_by_path "$img_loop")
mount_handler="znx_mount_handler"
}
}
```
That hook should be specified in `/etc/mkinitcpio.conf`:
```
MODULES=(loop dm-snapshot)
HOOKS=(base udev miso miso_shutdown miso_loop_mnt miso_znx_overlays miso_pxe_common miso_pxe_http miso_pxe_nbd miso_pxe_nfs miso_kms modconf block filesystems keyboard keymap)
COMPRESSION=xz
```
---
Those are all the changes needed to enable data persistence in the ISO images.https://gitlab.manjaro.org/tools/development-tools/manjaro-tools/-/issues/309Can't boot from a GRUB loop device.2020-02-13T22:33:28ZGhost UserCan't boot from a GRUB loop device.The GRUB bootloader has the ability to boot directly from ISO images. `znx` exploits that feature to provide a very crucial part of its functionality. When a Manjaro image is deployed (GNOME, Plasma, XFCE), `znx` fails to boot it. The in...The GRUB bootloader has the ability to boot directly from ISO images. `znx` exploits that feature to provide a very crucial part of its functionality. When a Manjaro image is deployed (GNOME, Plasma, XFCE), `znx` fails to boot it. The initramfs scripts will complain because the root device can't be found.
The [`miso_loop_mnt`](https://gitlab.manjaro.org/tools/development-tools/manjaro-tools/blob/master/initcpio/hooks/miso_loop_mnt) hook [tries to detect](https://gitlab.manjaro.org/tools/development-tools/manjaro-tools/blob/master/initcpio/hooks/miso_loop_mnt#L4) the loop device based on its label. However, the GRUB configuration file does not pass the needed parameter; instead, it passes the device UUID. But that UUID is never set.
A solution for that problem is to discover the device from within the initramfs by looking for the loop device (which is a file) in all the connected devices. That is achieved by the `find_dev_by_path` function below.
```shell
find_dev_by_path () {
local path="$1"
local tmp_mnt=/tmp_mnt
local _mnt
local a d
local device
[ "$path" ] ||
return 1
mkdir -p "$tmp_mnt"
for a in 1 2 3; do
for d in $(awk '{ print "/dev/"$4 }' /proc/partitions); do
# -- If the device is already mounted, it shouldn't be
# -- unmounted after the check.
grep -q "^$d " /proc/mounts && {
_mnt=$(grep "^$d " /proc/mounts | cut -d ' ' -f 2)
unmount=
} || {
mount -r -t auto "$d" "$tmp_mnt" 2> /dev/null || continue
_mnt="$tmp_mnt"
unmount=true
}
# -- File exists in $d. Save $d on $device.
[ -f "$_mnt/$path" ] &&
device="$d"
[ "$unmount" ] &&
umount "$tmp_mnt" 2> /dev/null || true
[ "$device" ] && {
echo "$device"
return
}
done
sleep 1
done
return 1
}
run_hook () {
[ "$img_flags" ] || img_flags="defaults"
if [ "$img_loop" ]; then
img_dev=$(find_dev_by_path "$img_loop")
mount_handler="miso_loop_mount_handler"
fi
}
miso_loop_mount_handler () {
newroot="$1"
local _dev_loop
msg ":: Setup a loop device from $img_loop located at device $img_dev"
_mnt_dev "$img_dev" "/run/miso/img_dev" "-r" "$img_flags"
if _dev_loop=$(losetup --find --show --read-only "/run/miso/img_dev/$img_loop"); then
misodevice="$_dev_loop"
else
echo "ERROR: Setting loopback device for file '/run/miso/img_dev/$img_loop'"
launch_interactive_shell
fi
miso_mount_handler $newroot
if [ "$copytoram" == "y" ]; then
losetup -d $_dev_loop 2> /dev/null
umount /run/miso/img_dev
else
echo $(readlink -f $img_dev) >> /run/miso/used_block_devices
fi
}
```https://gitlab.manjaro.org/tools/development-tools/manjaro-tools/-/issues/308patch for basestrap2021-10-17T07:13:09Zvfjplpatch for basestrap-cache (-c) (default behavior not changed) description was reversed compared to behavior, also changed logic and default variable state to better reflect variable name and behavior
-directory (-d) (behavior changed) now correctly warns ...-cache (-c) (default behavior not changed) description was reversed compared to behavior, also changed logic and default variable state to better reflect variable name and behavior
-directory (-d) (behavior changed) now correctly warns if -d is not specified (previously there was no warning with and without -d)
-interactive (-i) (default behavior not changed) now is possible to use interactive mode(previously mode was always non-interactive with and without -i)
[basestrap.patch](/uploads/2f7f9ce14c020692d9c74704308aecc1/basestrap.patch)https://gitlab.manjaro.org/tools/development-tools/manjaro-tools/-/issues/306grub-mkimage is missing modules that could enable UEFI boot of Manjaro from c...2019-05-08T07:16:06ZPete Batardgrub-mkimage is missing modules that could enable UEFI boot of Manjaro from content extracted to a FAT32 partitionPreamble
--------
This is a duplicate of https://gitlab.manjaro.org/packages/core/grub/issues/2, since it appears that the 'GRUB' that needs to be fixed is not the "core" GRUB package but the GRUB that is used to boot the ISO, in manjar...Preamble
--------
This is a duplicate of https://gitlab.manjaro.org/packages/core/grub/issues/2, since it appears that the 'GRUB' that needs to be fixed is not the "core" GRUB package but the GRUB that is used to boot the ISO, in manjaro-tools.
As pointed out in the issue referenced above, it can be demonstrated that replacing the current Manjaro ISO EFI GRUB bootloader with a version that includes FAT32 support allows users to create bootable UEFI media that, as opposed to using a `dd` copy, can be made by simply extracting the whole ISO content on a GPT partitioned FAT32 drive, and then booting it from a UEFI computer.
This can be desirable for Windows users, who, for varied reasons, such as being able to see the full content of the media they just created or being able to also use the media as regular storage, may prefer this method of creating bootable media as opposed to `dd` mode. This is even more true as most other distributions (Debian, Ubuntu, Arch) do support this mode of installation.
Proposed fix
------------
[Line 61 in `util-iso-boot.sh`](https://gitlab.manjaro.org/tools/development-tools/manjaro-tools/blob/master/lib/util-iso-boot.sh#L61):
```
grub-mkimage -d ${grub}/${platform} -o ${grub}/${platform}/${img} -O ${platform} -p ${prefix} biosdisk iso9660
```
should be altered to:
```
grub-mkimage -d ${grub}/${platform} -o ${grub}/${platform}/${img} -O ${platform} -p ${prefix} biosdisk iso9660 part_msdos part_gpt fat ntfs
```
For consistency, `part_msdos part_gpt fat ntfs` should probably also be added to [line 101](https://gitlab.manjaro.org/tools/development-tools/manjaro-tools/blob/master/lib/util-iso-boot.sh#L101).
If you do that, then, from what I was able to validate, the method of creating bootable media described above should also work with Manjaro ISOs, as opposed to currently resulting in a `grub rescue>` prompt due to the GRUB bootloader being unable to read content from a standalone FAT32 partition.