Tools issueshttps://gitlab.manjaro.org/groups/tools/-/issues2023-03-15T05:12:43Zhttps://gitlab.manjaro.org/tools/maintenance-tools/boxit/-/issues/8boxit connection lost2023-03-15T05:12:43ZPhilip Müllerboxit connection lost*Created by: udeved*
```
:: Status
QObject::connect: Cannot queue arguments of type 'QAbstractSocket::SocketError'
(Make sure 'QAbstractSocket::SocketError' is registered using qRegisterMetaType().)
error: Error while reading: error:140...*Created by: udeved*
```
:: Status
QObject::connect: Cannot queue arguments of type 'QAbstractSocket::SocketError'
(Make sure 'QAbstractSocket::SocketError' is registered using qRegisterMetaType().)
error: Error while reading: error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert bad record mac
error: The remote host closed the connection
Connection lost - Maybe you have reached the timeout of 3 minutes?!
```
Never had this before.
It seems, the boxit transaction was successful however.
Just updated eudev, will see if the repo db got screwed up.
https://gitlab.manjaro.org/tools/maintenance-tools/boxit/-/issues/11add blacklist option for overlay pkgs2018-06-09T13:35:07ZPhilip Mülleradd blacklist option for overlay pkgs*Created by: philmmanjaro*
Having a **excludelist** option for the **sync-folder** not to get certain packages from our upstream project **Archlinux** we may need to add also a **blacklist** option for our overlay packages, to hold some...*Created by: philmmanjaro*
Having a **excludelist** option for the **sync-folder** not to get certain packages from our upstream project **Archlinux** we may need to add also a **blacklist** option for our overlay packages, to hold some back within our **snap** function. This would give us the option to test or release packages to a certain branch but only hold it there.
As a workaround the **xperimental** branch got introduced to experiment with new packages without changing the current workflow of our distro.https://gitlab.manjaro.org/tools/maintenance-tools/boxit/-/issues/12update our user management2018-06-09T13:35:07ZPhilip Müllerupdate our user management*Created by: philmmanjaro*
With the current given user management every developer can
* sync from our upstream project Archlinux into any branch
* push/remove packages on any branch
* snap any branch to another
We may think abo...*Created by: philmmanjaro*
With the current given user management every developer can
* sync from our upstream project Archlinux into any branch
* push/remove packages on any branch
* snap any branch to another
We may think about
* restricting the whole possibilities to several sub-rights
* add new rights if neededhttps://gitlab.manjaro.org/tools/development-tools/manjaro-tools/-/issues/276Decide what to do with master and development code2018-06-08T02:51:16ZPhilip MüllerDecide what to do with master and development code*Created by: philmmanjaro*
We should review both branches and decide what to do about them.*Created by: philmmanjaro*
We should review both branches and decide what to do about them.Bernhard LandauerBernhard Landauerhttps://gitlab.manjaro.org/tools/development-tools/manjaro-tools/-/issues/288grub fails to install2018-06-10T20:20:11ZPhilip Müllergrub fails to install*Created by: bfitzgit23*
hi there,
i just tried to build a manjaro ISO with the xfce version on the stable branch and keeps it looking for a module called overlay on the mkinitcpio portion and during the grub-probe portion. then it s...*Created by: bfitzgit23*
hi there,
i just tried to build a manjaro ISO with the xfce version on the stable branch and keeps it looking for a module called overlay on the mkinitcpio portion and during the grub-probe portion. then it says failed to install correctly during the grub package installtion during the base system install. i've dealt with this and cannot simply ignore it per when i load my ISO during the build, i don't know how to fix this or why it's occuring. here is my error in a screenshot. https://imgur.com/OT5JHLA don't know where the logs are, so i couldn't attach them so hopefully this is enough to get help. thanks.https://gitlab.manjaro.org/tools/maintenance-tools/boxit/-/issues/16boxit sync doesn't see changed package signatures2018-06-09T13:35:07ZPhilip Müllerboxit sync doesn't see changed package signatures*Created by: jonathonf*
Upstream may upload new package signatures to fix issues with expired keys rather than rebuilding and/or bumping a package.
boxit sync currently pulls only changed packages and doesn't check whether the signat...*Created by: jonathonf*
Upstream may upload new package signatures to fix issues with expired keys rather than rebuilding and/or bumping a package.
boxit sync currently pulls only changed packages and doesn't check whether the signature in the upstream package database, or the key file, has changed.
This can lead to situations where package signatures won't validate as the boxit server has the old package signature file.
If detecting these changes automatically isn't possible, boxit could do with a "clean" or "full sync" option to force a full sync from the upstream mirror so all files are checked and/or downloaded. Ideally this would still detect when a particular file hasn't changed and skip it.https://gitlab.manjaro.org/tools/development-tools/manjaro-tools/-/issues/294warning: option --root is deprecated; use --sysroot instead2018-06-08T02:51:16ZPhilip Müllerwarning: option --root is deprecated; use --sysroot instead*Created by: philmmanjaro*
Currently we fail on pacman 5.1 series with:
```
==> Creating clean working copy [phil]...done
chmod: changing permissions of '/tmp/tmp.t4ieEXfwRY': Operation not permitted
==> ERROR: An unknown error ...*Created by: philmmanjaro*
Currently we fail on pacman 5.1 series with:
```
==> Creating clean working copy [phil]...done
chmod: changing permissions of '/tmp/tmp.t4ieEXfwRY': Operation not permitted
==> ERROR: An unknown error has occurred. Exiting...
==> ERROR: An unknown error has occurred. Exiting...
/usr/bin/mkchrootpkg: line 255: 14370 User defined signal 1 sudo -u $SUDO_USER env SRCDEST="$SRCDEST" BUILDDIR="$builddir" makepkg --config="$copydir/etc/makepkg.conf" --verifysource -o
```
https://gitlab.manjaro.org/tools/development-tools/manjaro-tools/-/issues/295cp: cannot stat '/usr/share/grub/unicode.pf2'2018-06-08T02:51:16ZBernhard Landauercp: cannot stat '/usr/share/grub/unicode.pf2'Seems with updated **grub 2.03.0-6** some adjustment will be needed re **buildiso**:
```
==> Prepare [/iso/boot/grub]
-> Building core.img ...
-> Building bootx64.efi ...
cp: cannot stat '/usr/share/grub/unicode.pf2': No such fi...Seems with updated **grub 2.03.0-6** some adjustment will be needed re **buildiso**:
```
==> Prepare [/iso/boot/grub]
-> Building core.img ...
-> Building bootx64.efi ...
cp: cannot stat '/usr/share/grub/unicode.pf2': No such file or directory
```https://gitlab.manjaro.org/tools/development-tools/manjaro-tools/-/issues/296Typo in 'taget' word in README and data/manjaro-tools.conf files2018-09-29T21:48:58ZGhost UserTypo in 'taget' word in README and data/manjaro-tools.conf fileshttps://gitlab.manjaro.org/tools/development-tools/manjaro-tools/-/issues/304manjaro-chroot from live "You can't mount 0!"2020-09-01T00:40:13ZAntonín Dachmanjaro-chroot from live "You can't mount 0!"The tool is not working properly.
This is output from gnome live 4.19.13-1-MANJARO tryin' to get onto installed nonbooting manjaro
```
$ manjaro-chroot -a
===> ERROR: You can't mount 0!
$ manjaro-chroot /mnt /bin/bash
===> ERROR: faile...The tool is not working properly.
This is output from gnome live 4.19.13-1-MANJARO tryin' to get onto installed nonbooting manjaro
```
$ manjaro-chroot -a
===> ERROR: You can't mount 0!
$ manjaro-chroot /mnt /bin/bash
===> ERROR: failed to setup API filesystems in chroot /mnt
```
Maybe I am doing something wrong, I have encrypted drive during the broken installation, but no wiki entry on this tool and the readme + forum finds provides little info on how to chroot the easy way.
mhwd-chroot is horribly broken as well but I am thinking it's a deprecated tool.https://gitlab.manjaro.org/tools/development-tools/devtools/-/issues/1manjaro version of `mkarchroot` does not behave as the original, breaks e.g. ...2019-04-20T20:28:58ZChris Drexlermanjaro version of `mkarchroot` does not behave as the original, breaks e.g. aurutils`mkmanjaroroot` is a symlink to `mkarchroot`, but `mkarchroot` does not behave as the original Arch version: it creates a file `.manjaro-chroot` instead of `.arch-chroot` (see [mkarchroot.in Line 109](https://gitlab.manjaro.org/tools/dev...`mkmanjaroroot` is a symlink to `mkarchroot`, but `mkarchroot` does not behave as the original Arch version: it creates a file `.manjaro-chroot` instead of `.arch-chroot` (see [mkarchroot.in Line 109](https://gitlab.manjaro.org/tools/development-tools/devtools/blob/master/mkarchroot.in#L109) )
This essentially breaks the API of `mkarchroot` and other programs depending on this file break. My problem was with [aurutils](https://aur.archlinux.org/packages/aurutils): they check for the correctly created chroot file system by looking for `.arch-chroot`, which does not exist when using the Manjaro devtools and aurutils fail.
Possible solutions IMHO:
1. make `mkarchroot` behave as Arch equivalent, only create `.arch-chroot` and keep symlink from `mkmanjaroroot`: this could possibly break some code as manjaro packages now don't find the `.manjaro-chroot` file anymore.
2. make `mkmanjaroroot` create `.manjaro-chroot` and `mkarchroot` `.arch-chroot` (separating the two programs): this could break code that relies on the wrong behavior
3. make `mkarchroot` create *both* files `.arch-chroot` and `.manjaro-chroot` and keep symlink: possibly best backward compatibility (but maybe side effects?)
This has also been discussed in the [forum](https://forum.manjaro.org/t/manjaro-version-of-mkarchroot-does-not-behave-as-the-original-breaks-e-g-aurutils/83544)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.https://gitlab.manjaro.org/tools/maintenance-tools/manjaro-bootstrap/-/issues/1Missing pacman dependencies2019-05-09T08:35:47ZElephantusparvusMissing pacman dependenciesThe merge request for libunistring and libidn2 is not applied.
Pacman (now) also needs zstd which is a dependency of libarchive.
If not present one does get linker errors when chrooting in that environment.
Also libidn is not necessary a...The merge request for libunistring and libidn2 is not applied.
Pacman (now) also needs zstd which is a dependency of libarchive.
If not present one does get linker errors when chrooting in that environment.
Also libidn is not necessary any more.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/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/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/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/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/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/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.