Re: `makepkg` generates two packages
Le jeu. 7 mars 2024 à 15:15, Ryan Petris a écrit : > On Thu, Mar 7, 2024, at 6:45 AM, Martin Rys wrote: > > If you had the configuration autoreplaced it would mean you never edited > it - in which case you'd be building packages on a single thread... Surely > not? > > Martin > > On Thu, Mar 7, 2024, 14:41 Ryan Petris wrote: > > > On Thu, Mar 7, 2024, at 4:38 AM, Robin Candau wrote: > > On 3/7/24 12:34, lacsaP Patatetom wrote: > > hi, > Hi, > > > > when I run `makepkg`, it generates a second package with the `-debug` > > "extension" (eg. `mypackage-w.x.y-z-x86_64.pkg.tar.zst` and > > `mypackage-debug-w.x.y-z-x86_64.pkg.tar.zst`). > > > > I couldn't find anything about this on the wiki : is this a new feature > > and/or is there a parameter to pass to `makepkg` to avoid building it ? > > > Debug packages have been introduced in Arch in early 2022. > See https://archlinux.org/news/debug-packages-and-debuginfod/ > > regards, lacsaP. > > -- > Regards, > Robin Candau / Antiz > > > > *Attachments:* > >- OpenPGP_0xFDC3040B92ACA748.asc >- OpenPGP_signature.asc > > > Arch itself may have been generating debug packages since 2022, however > it's only recently that makepkg started spitting out debug packages by > default. The change was made all the way back in June of last year > <https://gitlab.archlinux.org/archlinux/packaging/packages/pacman/-/commit/90bf367e61b4f77f8351d0412be3d0c4ddadb85a>, > but was only included in a pacman release at the beginning of February > <https://gitlab.archlinux.org/archlinux/packaging/packages/pacman/-/tags/6.0.2-9>, > as part of a pkgrel bump. > > This came as a surprise to me as well, when I had -debug packages start > showing up in my personal repository when they had not before, without any > changes made on my end. > > Personally I would have expected some sort of announcement for this > change, though there was none. > > > Prior to needing to modify options, my changes to makepkg consisted of: > > echo 'MAKEFLAGS="-j$(nproc)"' >> /etc/makepkg.conf > > So yes, it's possible. > > On that note, I'm building my packages using standard github actions; I > don't believe those are multi-threaded anyway. > > idem for me. but I build packages very occasionally, so it's not a problem for me (I'll have a coffee in the meantime;-)).
Re: `makepkg` generates two packages
Le jeu. 7 mars 2024 à 13:28, Robin Candau a écrit : > On 3/7/24 13:21, Ryan Petris wrote: > > On Thu, Mar 7, 2024, at 4:38 AM, Robin Candau wrote: > >> On 3/7/24 12:34, lacsaP Patatetom wrote: > >> > hi, > >> Hi, > >> > > >> > when I run `makepkg`, it generates a second package with the `-debug` > >> > "extension" (eg. `mypackage-w.x.y-z-x86_64.pkg.tar.zst` and > >> > `mypackage-debug-w.x.y-z-x86_64.pkg.tar.zst`). > >> > > >> > I couldn't find anything about this on the wiki : is this a new > feature > >> > and/or is there a parameter to pass to `makepkg` to avoid building it > ? > >> > > >> Debug packages have been introduced in Arch in early 2022. > >> See https://archlinux.org/news/debug-packages-and-debuginfod/ > >> <https://archlinux.org/news/debug-packages-and-debuginfod/> > >> > regards, lacsaP. > >> > >> -- > >> Regards, > >> Robin Candau / Antiz > >> > >> > >> > >> *Attachments:* > >> > >> * OpenPGP_0xFDC3040B92ACA748.asc > >> * OpenPGP_signature.asc > > > > Arch itself may have been generating debug packages since 2022, however > > it's only recently that makepkg started spitting out debug packages by > > default. The change was made all the way back in June of last year > > < > https://gitlab.archlinux.org/archlinux/packaging/packages/pacman/-/commit/90bf367e61b4f77f8351d0412be3d0c4ddadb85a>, > but was only included in a pacman release at the beginning of February < > https://gitlab.archlinux.org/archlinux/packaging/packages/pacman/-/tags/6.0.2-9>, > as part of a pkgrel bump. > > > This came as a surprise to me as well, when I had -debug packages start > > showing up in my personal repository when they had not before, without > > any changes made on my end. > > > > Personally I would have expected some sort of announcement for this > > change, though there was none. > The news in 2022 said that enabling debug packages for all packages was > an ongoing effort, suggesting that such a change would happen sooner or > later. But fair enough, I get your point. > > If anything, as Christian/gromit already said in a previous mail on that > thread, you can disable the debug option in PKGBUILDs/makepkg.conf to > avoid -debug packages from being created. > > -- > Regards, > Robin Candau / Antiz > > thank you for your answers. I did see the changes introduced last February in `/etc/makepkg.conf` but I had targeted those related to Rust since my package is "based" on cargo. have a nice day, regards, lacsaP.
`makepkg` generates two packages
hi, when I run `makepkg`, it generates a second package with the `-debug` "extension" (eg. `mypackage-w.x.y-z-x86_64.pkg.tar.zst` and `mypackage-debug-w.x.y-z-x86_64.pkg.tar.zst`). I couldn't find anything about this on the wiki : is this a new feature and/or is there a parameter to pass to `makepkg` to avoid building it ? regards, lacsaP.
Re: Issues with new NTFS module
Le ven. 17 nov. 2023 à 13:49, Giovanni Santini a écrit : > Hi IacsaP and Lukasz, > On 2023-11-17 08:40, lacsaP Patatetom wrote: > > on the `/proc/sys/vm/` side may be ? > does the `sync` followed by a `sysctl -q vm.drop_caches=3` change things ? > > regards, lacsaP. > > tried but to no avail. > > Here is the session output: > > --- > > (13:44) giovanni @ ~ $ sysctl vm.drop_caches > (13:44) giovanni @ ~ $ sudo sysctl vm.drop_caches=3 > [sudo] password for giovanni: > vm.drop_caches = 3 > (13:44) giovanni @ ~ $ udisksctl mount -b /dev/nvme0n1p5 -t ntfs3 > Mounted /dev/nvme0n1p5 at /run/media/giovanni/Data > (13:44) giovanni @ ~ $ cat /run/media/giovanni/Data/mount_test.txt > Using ntfs3 > (13:45) giovanni @ ~ $ echo "Using udisks and ntfs3" > > /run/media/giovanni/Data/mount_test.txt > (13:45) giovanni @ ~ $ cat /run/media/giovanni/Data/mount_test.txt > (13:45) giovanni @ ~ $ sync > (13:45) giovanni @ ~ $ cat /run/media/giovanni/Data/mount_test.txt > (13:45) giovanni @ ~ $ udisksctl unmount -b /dev/nvme0n1p5 > Unmounted /dev/nvme0n1p5. > (13:45) giovanni @ ~ $ udisksctl mount -b /dev/nvme0n1p5 -t ntfs3 > Mounted /dev/nvme0n1p5 at /run/media/giovanni/Data > (13:45) giovanni @ ~ $ cat /run/media/giovanni/Data/mount_test.txt > Using udisks and ntfs3 > (13:45) giovanni @ ~ $ > > --- > > As Lukasz mentioned, it probably is a bug. > > I will open one on the bug tracker and if needed towards the kernel > itself. :) > > Will keep you posted. > > Bests, > > -- > Giovanni Santini > > (13:45) giovanni @ ~ $ echo "Using udisks and ntfs3" > /run/media/giovanni/Data/mount_test.txt (13:45) giovanni @ ~ $ cat /run/media/giovanni/Data/mount_test.txt try calling `sysctl` after `sync` here : (13:45) giovanni @ ~ $ sync; sudo sysctl vm.drop_caches=3 (13:45) giovanni @ ~ $ cat /run/media/giovanni/Data/mount_test.txt
Re: Issues with new NTFS module
Le ven. 17 nov. 2023 à 07:41, Giovanni Santini a écrit : > Hi Marius, > On 2023-11-15 14:16, Marius Kittler wrote: > > Since both are completely different implementations the syncing behavior might > differ. I haven't paid much attention to the syncing behavior of the new > kernel > module but it might simply be more lazy than the FUSE implementation. Does it > help to invoke `sync` manually? If yes, this may also be a workaround in case > you really want it to write the data without delay. > > I did try, yes. No fortune with manual sync and udisks or mount. > > Here is a shell session, I think a pastebin is not needed given that it is > short: > > --- > > (23:16) giovanni @ ~ $ udisksctl mount -b /dev/nvme0n1p5 -t ntfs3 > Mounted /dev/nvme0n1p5 at /run/media/giovanni/Data > (23:16) giovanni @ ~ $ touch /run/media/giovanni/Data/ntfs_error.txt > (23:17) giovanni @ ~ $ ls -al /run/media/giovanni/Data/ntfs_error.txt > -rw-r--r-- 1 giovanni users 0 Nov 16 23:17 > /run/media/giovanni/Data/ntfs_error.txt > (23:17) giovanni @ ~ $ echo "Using ntfs3" > > /run/media/giovanni/Data/ntfs_error.txt > (23:17) giovanni @ ~ $ cat /run/media/giovanni/Data/ntfs_error.txt > (23:17) giovanni @ ~ $ udisksctl unmount -b /dev/nvme0n1p5 > Unmounted /dev/nvme0n1p5. > (23:17) giovanni @ ~ $ udisksctl mount -b /dev/nvme0n1p5 -t ntfs3 > Mounted /dev/nvme0n1p5 at /run/media/giovanni/Data > (23:17) giovanni @ ~ $ cat /run/media/giovanni/Data/ntfs_error.txt > Using ntfs3 > (23:17) giovanni @ ~ $ udisksctl unmount -b /dev/nvme0n1p5 > Unmounted /dev/nvme0n1p5. > (23:18) giovanni @ ~ $ sudo mount -t ntfs3 -o uid=$UID,gid=$GROUPS > /dev/nvme0n1p5 /mnt/ > (23:18) giovanni @ ~ $ cat /mnt/ntfs_error.txt > Using ntfs3 > (23:18) giovanni @ ~ $ echo "Using ntfs3 and mount" > /mnt/ntfs_error.txt > (23:19) giovanni @ ~ $ cat /mnt/ntfs_error.txt > (23:19) giovanni @ ~ $ sync > (23:19) giovanni @ ~ $ cat /mnt/ntfs_error.txt > (23:19) giovanni @ ~ $ sync > (23:19) giovanni @ ~ $ cat /mnt/ntfs_error.txt > (23:19) giovanni @ ~ $ sudo umount /mnt > (23:19) giovanni @ ~ $ sudo mount -t ntfs3 -o uid=$UID,gid=$GROUPS > /dev/nvme0n1p5 /mnt/ > (23:19) giovanni @ ~ $ cat /mnt/ntfs_error.txt > Using ntfs3 and mount > (23:19) giovanni @ ~ $ > > --- > > You can see that when I try to overwrite the file content it just > "appears" empty. > > Unmounting and remounting the partition makes the content appear. > > Bests, > > -- > Giovanni Santini > > on the `/proc/sys/vm/` side may be ? does the `sync` followed by a `sysctl -q vm.drop_caches=3` change things ? regards, lacsaP.
Re: pacman via pacstrap
Le ven. 10 nov. 2023 à 17:41, Doug Newgard a écrit : > On Fri, 10 Nov 2023 08:40:35 +0100 > lacsaP Patatetom wrote: > > # pacstrap -c -C target/etc/pacman.conf -U target/ > > pkg/numix-gtk-theme-git-2.6.7.r55.ad4b345-1-any.pkg.tar.zst --overwrite > '*' > > > > thank you for this tip from the bowels of pacstrap because this > > option-passing method is not specified in the pacstrap man. > > > > have a good day, regards, lacsaP. > > Why aren't you just using pacman --sysroot here? > what would be the difference between using `pacman` directly and using `pacstrap` ?
Re: pacman via pacstrap
Le jeu. 9 nov. 2023 à 21:52, Christoph Gysin a écrit : > My bad, it seems the extra dashes are not needed, pacstrap ignores unknown > options. Try: > > # pacstrap -c -C target/etc/pacman.conf -U target/ > pkg/numix-gtk-theme-git-2.6.7.r55.ad4b345-1-any.pkg.tar.zst --overwrite > > On Mon, Nov 6, 2023 at 2:51 PM lacsaP Patatetom > wrote: > >> Le mer. 1 nov. 2023 à 14:51, Christoph Gysin >> a écrit : >> >>> >>> On Wed, Nov 1, 2023 at 1:45 AM lacsaP Patatetom >>> wrote: >>> >>>> I use `pacstrap -U` to install locally forged packages in a dedicated >>>> folder. >>>> this dedicated folder already contains some files and some of these >>>> files are causing problems for `pacstrap -U` (eg. `pacman -U`). >>>> >>>> i'd like to be able to use `--overwrite` option and pass it from >>>> `pacstrap`. >>>> >>>> is it possible to pass options to `pacman` via `pacstrap` ? >>>> >>> >>> It seems pacstrap is passing any additional flags to pacman: >>> >>> >>> https://github.com/archlinux/arch-install-scripts/blob/master/pacstrap.in#L141 >>> >>> So you should be able to pass options using e.g.: >>> >>> $ pacstrap -U /mnt linux -- --overwrite >>> >> >> hi, >> >> here's a case study that might be more telling : >> >> ``` >> # pacstrap -c -C target/etc/pacman.conf -U target/ >> pkg/numix-gtk-theme-git-2.6.7.r55.ad4b345-1-any.pkg.tar.zst >> ==> Creating install root at target/ >> ==> Installing packages to target/ >> loading packages... >> resolving dependencies... >> looking for conflicting packages... >> Packages (1) numix-gtk-theme-git-2.6.7.r55.ad4b345-1 >> Total Installed Size: 3.77 MiB >> :: Proceed with installation? [Y/n] >> (1/1) checking keys in keyring >> [#] >> 100% >> (1/1) checking package integrity >> [#] >> 100% >> (1/1) loading package files >> [#] >> 100% >> (1/1) checking for file conflicts >> [#] >> 100% >> error: failed to commit transaction (conflicting files) >> numix-gtk-theme-git: target/usr/share/themes/Numix/gtk-3.20/gtk.css >> exists in filesystem >> numix-gtk-theme-git: target/usr/share/themes/Numix/openbox-3/themerc >> exists in filesystem >> Errors occurred, no packages were upgraded. >> ==> ERROR: Failed to install packages to new root >> >> # pacstrap -c -C target/etc/pacman.conf -U target/ >> pkg/numix-gtk-theme-git-2.6.7.r55.ad4b345-1-any.pkg.tar.zst -- --overwrite >> ==> Creating install root at target/ >> ==> Installing packages to target/ >> loading packages... >> error: '--overwrite': could not find or read package >> error: '--config=target/etc/pacman.conf': could not find or read package >> error: '--noconfirm': could not find or read package >> ==> ERROR: Failed to install packages to new root >> ``` >> >> the `numix` package simply comes from AUR and the two files I'm following >> (eg. versioned) `target/usr/share/themes/Numix/gtk-3.20/gtk.css` and >> `target/usr/share/themes/Numix/openbox-3/themerc` are already present in >> the tree and make some changes to the files supplied by default with the >> package. >> >> note that the `--overwrite` option is not passed on to `pacman` and that >> the problem does not recur if I try to reinstall the package, even though >> the two files are still present. >> >> regards, lacsaP. >> > you're right, don't add extra dashes (and add the necessary to the overwrite option) : # pacstrap -c -C target/etc/pacman.conf -U target/ pkg/numix-gtk-theme-git-2.6.7.r55.ad4b345-1-any.pkg.tar.zst --overwrite '*' thank you for this tip from the bowels of pacstrap because this option-passing method is not specified in the pacstrap man. have a good day, regards, lacsaP.
Re: pacman via pacstrap
Le mer. 1 nov. 2023 à 14:51, Christoph Gysin a écrit : > > On Wed, Nov 1, 2023 at 1:45 AM lacsaP Patatetom > wrote: > >> I use `pacstrap -U` to install locally forged packages in a dedicated >> folder. >> this dedicated folder already contains some files and some of these files >> are causing problems for `pacstrap -U` (eg. `pacman -U`). >> >> i'd like to be able to use `--overwrite` option and pass it from >> `pacstrap`. >> >> is it possible to pass options to `pacman` via `pacstrap` ? >> > > It seems pacstrap is passing any additional flags to pacman: > > > https://github.com/archlinux/arch-install-scripts/blob/master/pacstrap.in#L141 > > So you should be able to pass options using e.g.: > > $ pacstrap -U /mnt linux -- --overwrite > hi, here's a case study that might be more telling : ``` # pacstrap -c -C target/etc/pacman.conf -U target/ pkg/numix-gtk-theme-git-2.6.7.r55.ad4b345-1-any.pkg.tar.zst ==> Creating install root at target/ ==> Installing packages to target/ loading packages... resolving dependencies... looking for conflicting packages... Packages (1) numix-gtk-theme-git-2.6.7.r55.ad4b345-1 Total Installed Size: 3.77 MiB :: Proceed with installation? [Y/n] (1/1) checking keys in keyring [#] 100% (1/1) checking package integrity [#] 100% (1/1) loading package files [#] 100% (1/1) checking for file conflicts [#] 100% error: failed to commit transaction (conflicting files) numix-gtk-theme-git: target/usr/share/themes/Numix/gtk-3.20/gtk.css exists in filesystem numix-gtk-theme-git: target/usr/share/themes/Numix/openbox-3/themerc exists in filesystem Errors occurred, no packages were upgraded. ==> ERROR: Failed to install packages to new root # pacstrap -c -C target/etc/pacman.conf -U target/ pkg/numix-gtk-theme-git-2.6.7.r55.ad4b345-1-any.pkg.tar.zst -- --overwrite ==> Creating install root at target/ ==> Installing packages to target/ loading packages... error: '--overwrite': could not find or read package error: '--config=target/etc/pacman.conf': could not find or read package error: '--noconfirm': could not find or read package ==> ERROR: Failed to install packages to new root ``` the `numix` package simply comes from AUR and the two files I'm following (eg. versioned) `target/usr/share/themes/Numix/gtk-3.20/gtk.css` and `target/usr/share/themes/Numix/openbox-3/themerc` are already present in the tree and make some changes to the files supplied by default with the package. note that the `--overwrite` option is not passed on to `pacman` and that the problem does not recur if I try to reinstall the package, even though the two files are still present. regards, lacsaP.
pacman via pacstrap
hi, I use `pacstrap -U` to install locally forged packages in a dedicated folder. this dedicated folder already contains some files and some of these files are causing problems for `pacstrap -U` (eg. `pacman -U`). i'd like to be able to use `--overwrite` option and pass it from `pacstrap`. is it possible to pass options to `pacman` via `pacstrap` ? regards, lacsaP.
Re: colored prompt in early userspace
Le mar. 28 mars 2023 à 16:34, lacsaP Patatetom a écrit : > > hi, > > when you add the `break` parameter to the list of parameters passed > when the system boots, you find yourself in an interactive shell that > allows you to issue commands, perform tests, and so on... > > the shell is apparently provided by `ash`. > > how to have a colored prompt (which visually helps to detach the > prompt from the rest) ? > > the `~/.profile` file mentioned here and there does not seem to be read/used. > `/.profile` and `/etc/profile` don't do much better. > `ashrc` also tested without success. > > if the prompt offered at this level can be colored, I think it would > not be a luxury to implement it directly in mkinitcpio ;-) > > regards, lacsaP. I finally modified the `launch_interactive_shell` function present in the `/usr/lib/initcpio/init_functions` file which exports the definition of the prompt : ` export PS1='\n\e[33m(rootfs) \W \$ \e[m' ` not sure if this is the cleanest way to precede... regards, lacsaP.
colored prompt in early userspace
hi, when you add the `break` parameter to the list of parameters passed when the system boots, you find yourself in an interactive shell that allows you to issue commands, perform tests, and so on... the shell is apparently provided by `ash`. how to have a colored prompt (which visually helps to detach the prompt from the rest) ? the `~/.profile` file mentioned here and there does not seem to be read/used. `/.profile` and `/etc/profile` don't do much better. `ashrc` also tested without success. if the prompt offered at this level can be colored, I think it would not be a luxury to implement it directly in mkinitcpio ;-) regards, lacsaP.
Re: X application preferences
Le ven. 24 mars 2023 à 11:43, lacsaP Patatetom a écrit : > > Le ven. 24 mars 2023 à 11:38, David a écrit : > > > > On Fri, 24 Mar 2023 at 10:25, lacsaP Patatetom wrote: > > > Le ven. 24 mars 2023 à 11:13, <2qdxy4rzwzuui...@potatochowder.com> a > > > écrit : > > > > On 2023-03-24 at 11:03:33 +0100, lacsaP Patatetom > > > > wrote: > > > > > > > I would like the `lxtask` application (LXDE task manager) to open > > > > > systematically in "always on top" mode : is it possible to do this in > > > > > the `~/.Xresources` file ? > > > > > otherwise, where can it be configured ? > > > > > > "Always on top" is a function of your window manager, so the answer to > > > > your question depends on your window manager. > > > > > I'm using OpenBox. > > > > Hi, this might help: > > https://askubuntu.com/questions/445529/how-can-i-have-an-application-automatically-display-on-all-desktops-with-openbox > > adding > ``` > > above > > ``` > in the `...` node do the trick :-) > > regards, lacsaP. in my `~/.config/openbox/rc.xml` file ;-)
Re: X application preferences
Le ven. 24 mars 2023 à 11:38, David a écrit : > > On Fri, 24 Mar 2023 at 10:25, lacsaP Patatetom wrote: > > Le ven. 24 mars 2023 à 11:13, <2qdxy4rzwzuui...@potatochowder.com> a écrit : > > > On 2023-03-24 at 11:03:33 +0100, lacsaP Patatetom > > > wrote: > > > > > I would like the `lxtask` application (LXDE task manager) to open > > > > systematically in "always on top" mode : is it possible to do this in > > > > the `~/.Xresources` file ? > > > > otherwise, where can it be configured ? > > > > "Always on top" is a function of your window manager, so the answer to > > > your question depends on your window manager. > > > I'm using OpenBox. > > Hi, this might help: > https://askubuntu.com/questions/445529/how-can-i-have-an-application-automatically-display-on-all-desktops-with-openbox adding ``` above ``` in the `...` node do the trick :-) regards, lacsaP.
Re: X application preferences
Le ven. 24 mars 2023 à 11:29, Ralf Mardorf a écrit : > > On Fri, 2023-03-24 at 11:03 +0100, lacsaP Patatetom wrote: > > I would like the `lxtask` application (LXDE task manager) to open > > systematically in "always on top" mode > > Hi, > > for similar things I'm using scripts based on a combination of > > eval $(xdotool ... > wmctrl ... > > I'm not using the "above" property, but I suspect it enables "always on > top". > > I'm using it for several other tasks. The windows of some programs hide > their title bars under a top panel when they are launched. One of my > scripts automatically moves those programs below the top panel. > > Regards, > Ralf thank you for these ideas. I had started to try to do something with `wmctrl` but I want to find something else. regards, lacsaP.
Re: X application preferences
Le ven. 24 mars 2023 à 11:13, <2qdxy4rzwzuui...@potatochowder.com> a écrit : > > On 2023-03-24 at 11:03:33 +0100, > lacsaP Patatetom wrote: > > > I would like the `lxtask` application (LXDE task manager) to open > > systematically in "always on top" mode : is it possible to do this in > > the `~/.Xresources` file ? > > otherwise, where can it be configured ? > > "Always on top" is a function of your window manager, so the answer to > your question depends on your window manager. I'm using OpenBox. I will take a look at his documentation. I am interested if you have the solution in hand or under elbow ;-) thanks for the track, regards, lacsaP
X application preferences
hi, I would like the `lxtask` application (LXDE task manager) to open systematically in "always on top" mode : is it possible to do this in the `~/.Xresources` file ? otherwise, where can it be configured ? regards, lacsaP.
Re: /dev/stderr in early userspace
Le jeu. 23 mars 2023 à 11:02, nl6720 a écrit : > > On Thursday, 23 March 2023 10:49:40 EET lacsaP Patatetom wrote: > > hi, > > > > I recently noticed that `/dev/stderr` was not present at the very > > beginning of the boot, in early userspace. > > > > if I add `break` parameter to have control during this step and do a > > `ls` test, this is what I get: > > > > ``` > > [rootfs ]# ls -l /dev/std* > > ls: /dev/std*: No such file or directory > > ``` > > > > Is there anything special to add/do to get these special devices ? > > > > nothing special in my `mkinitcpio.conf`, `base` and `udev` hooks > > installed/used. > > just note that the image is made from a chroot with `arch-chroot` with > > no error/warning. > > > > regards, lacsaP. > > > > Hi! > > This was fixed in mkinitcpio 35.1, specifically in the commit > https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/commit/ae2b2dc139baa72e6669bae7ef85396a2bca0408 > > /dev/stderr (and the rest of them) should exist in early userspace. > > nl6720 ok for me with mkinitcpio 35.1 : "special" devices are now present. thanks. regards, lacsaP. (my problem with pv (pipe view @ https://github.com/a-j-wood/pv/issues/19) is no longer to be found on this side)
/dev/stderr in early userspace
hi, I recently noticed that `/dev/stderr` was not present at the very beginning of the boot, in early userspace. if I add `break` parameter to have control during this step and do a `ls` test, this is what I get: ``` [rootfs ]# ls -l /dev/std* ls: /dev/std*: No such file or directory ``` Is there anything special to add/do to get these special devices ? nothing special in my `mkinitcpio.conf`, `base` and `udev` hooks installed/used. just note that the image is made from a chroot with `arch-chroot` with no error/warning. regards, lacsaP.
Re: bio_check_ro @ blk-core.c
Le mar. 21 mars 2023 à 11:27, Emil Velikov a écrit : > > On Mon, 20 Mar 2023 at 16:49, lacsaP Patatetom wrote: > > > > hi, > > > > back again ;-) > > > > this github page will perhaps allow you to better understand my problem and > > to guide me towards a solution. > > > > my main problem is my inability to patch the kernel as I used to do in > > order to prevent LVM to modify a read-only disk. > > > > I don't have experience with the kernel block layer, so you're better > off asking on the official mailing list (ML). > > To make your experience smoother, I would suggest using plain text > emails [2] and avoiding top-posting [3]. You also might want to have a > quick look at their ML archive [4] for other "dos" and "don'ts". > > HTH > Emil > > [1] linux-bl...@vger.kernel.org > [2] > https://www.lifewire.com/how-to-send-a-message-in-plain-text-from-gmail-1171963 > [3] https://en.wikipedia.org/wiki/Posting_style#Top-posting > [4] https://lore.kernel.org/linux-block/ thanks a lot for everything Emil ! have a good day, regards, lacsaP.
Re: linux headers
again thank you for explanations/clarifications. have a good day, regards, lacsaP. Le mar. 21 mars 2023 à 11:16, Genes Lists a écrit : > On 3/21/23 04:26, lacsaP Patatetom wrote: > > hi everybody, > > > > > my development workstation is running 6.1.20-1-lts and I made > > linux-lts-ro-6.1.15-1-x86_64.pkg.tar.zst and > > linux-lts-ro-headers-6.1.15-1-x86_64.pkg.tar.zst packages on it : if now > > I want to compile on this development workstation applications to run on > > another workstation which is running 6.1.15-1-lts-ro, what should I do > > so that the compilation takes this specificity into account ? > > Unless you are compiling kernel modules the answer is nothing. The > kernel team takes great pains to ensure that user space will continue to > work. Most of the kernel interface of the kernel with user space is > mediated by libraries such as glibc. > > You do need to be sure that your user-space environment is consistent > between the compiling host and the application target. For example that > the target machines run same version of glibc etc. > > So short answer - if only difference between your compile machine and > target application machine is kernel - there is nothing special you need > to do. > > Good luck. > > > > >
Re: linux headers
hi everybody, if point #1 is now relatively clear to me (eg. out of tree kernel modules need to recompile, otherwise it should work with few exceptions), point #2 is still pending. so I rephrase my question hoping to find an answer ;-) my development workstation is running 6.1.20-1-lts and I made linux-lts-ro-6.1.15-1-x86_64.pkg.tar.zst and linux-lts-ro-headers-6.1.15-1-x86_64.pkg.tar.zst packages on it : if now I want to compile on this development workstation applications to run on another workstation which is running 6.1.15-1-lts-ro, what should I do so that the compilation takes this specificity into account ? I saw that there was the gcc ‘--enable-kernel=version’ option : is it the solution ? if yes, how to introduce it during the traditional "./configure && make" ? regards, lacsaP. Le lun. 20 mars 2023 à 13:19, Jeronimo Garcia a écrit : > lvm is a good one , bpftrace and other tools that might rely on kernel > hooks , or something specific module or statically compiled feature , but > as Ralf said , the vast majority of user land applications can be used > interchangeably with different kernels . > > On Mon, 20 Mar 2023 at 11:59, lacsaP Patatetom > wrote: > >> thank you for your feedback Ralf which is in line with Genes' >> explanations. >> >> the application that could fall into the mentioned category and that I am >> paying attention to is lvm, but previous tests show that this is not the >> case (the lvm2 package provided by ArchLinux behaves as expected with the >> recompiled modified kernel). >> >> regards, lacsaP. >> >> >> >> Le lun. 20 mars 2023 à 12:49, Ralf Mardorf a >> écrit : >> >>> On Mon, 2023-03-20 at 12:27 +0100, lacsaP Patatetom wrote: >>> > if I understand correctly, I can install my package linux-lts-perso- >>> > 6.1.15-2-x86_64.pkg.tar.zst, boot on it (eg. "my" kernel) and continue >>> > to use the binaries present on my system while they have not been >>> > compiled with its (new) headers and especially for the binaries that >>> > call the functions present in the blk-core.c file ? >>> >>> I still don't know if I understand you and >>> https://www.google.com/search?q=translate doesn't help. >>> >>> You can install >>> >>> core/linux-lts 6.1.20-1 >>> core/linux-lts-docs 6.1.20-1 >>> core/linux-lts-headers 6.1.20-1 >>> >>> and also your >>> >>> linux-lts-perso 6.1.15-2 >>> linux-lts-perso-docs6.1.15-2 >>> linux-lts-perso-headers 6.1.15-2 >>> >>> neither the version, nor the pkgrel matter. >>> You can run one or the other kernel and you can build modules for what >>> ever kernel you like, see >>> >>> https://wiki.archlinux.org/title/Dynamic_Kernel_Module_Support#Rebuild_modules >>> . >>> >>> You (usually) can use a binary such as /usr/bin/vim with one or the >>> other kernel, but you might need to build modules to use something like >>> virtualbox. >>> >>> In your case something like systemd or xorg is irrelevant, but something >>> like this might depend closer on kernel versions, than vim does. >>> >>> Regards, >>> Ralf >>> >>
Re: bio_check_ro @ blk-core.c
hi, back again ;-) this github page <https://github.com/patatetom/lvm-on-readonly-block-device/blob/main/README.md> will perhaps allow you to better understand my problem and to guide me towards a solution. my main problem is my inability to patch the kernel as I used to do in order to prevent LVM to modify a read-only disk. regards, lacsaP. Le lun. 20 mars 2023 à 10:11, lacsaP Patatetom a écrit : > hi Emil, > > forgive me if this is the third time I've replied to this message but I > received a moderation warning the two previous times that my reply was over > 40Kb when my preparation file was only 13Kb... > > I haven't had any feedback about this moderation since last week, so I > don't know if you received my answer... > > this one concluded that the recent version of LVM integrated in the ISO > image of ArchLinux modifies a disk, even if this one and all its partitions > are set as read-only (chmod 444 /dev/sdX* && blockdev --setro /dev/sdX* > with udev rule). > > thank you for this investigation, this history. > > regards; lacsaP. > > > Le mer. 15 mars 2023 à 16:36, Emil Velikov a > écrit : > >> Greetings Pascal, >> >> After following the links I see what's happening. Essentially: >> - Kernel gained RO/RW correctness check - circa Jan 2018, kernel >> commit 721c7fc701c71f693307d274d2b346a1ecd4a534 >> - LVM was initially buggy but later fixed, circa Mar 2018, >> - Kernel check got partially reverted because broken LVM is still >> used - circa Aug 2018, kernel commit >> a32e236eb93e62a0f692e79b7c3c9636689559b9 >> - People used an out of tree patch, reinstating the correctness check >> - The function return type was dropped since it is unused - Sep 2022, >> kernel commit bdb7d420c6f6d2618d4c907cd7742c3195c425e2 >> - kernel patch no longer applies, correct behaviour cannot be enforced >> >> To unblock yourself, it will be a matter of reverting >> bdb7d420c6f6d2618d4c907cd7742c3195c425e2 and then >> a32e236eb93e62a0f692e79b7c3c9636689559b9. >> >> For the mid/long run, one should consider a proper upstream solution: >> >> Assuming I'm in your position, I would dig through the data in the >> linked commits and estimate which/how many distributions ship with >> buggy LVM. Then formulate a comprehensive cover letter, proposing a) >> reverts (if LVM is no longer used in the wild) or b) reverts && a >> (KCONFIG, sysctl, other) toggle to control the behaviour. >> >> Hope that helps, >> Emil >> >> On Wed, 15 Mar 2023 at 13:38, Pascal wrote: >> > >> > hi Emil, >> > >> > in view of your answer and after rereading my email, I realize that I >> was confused in my request. >> > here it is, I hope, more clearly reformulated :-) >> > >> > first of all, I use ArchLinux to, from time to time, compile the >> slightly modified LTS kernel, and this from PKGBUILD provided by ArchLinux >> at some point. >> > >> > some technologies such as LVM do not take into account the read-only >> applied on a block device. >> > see the two links provided in the previous exchanges for more details... >> > >> > >> > until now, I recompiled the kernel by applying a slight modification to >> the bio_check_ro function present in the blk-core.c source file. >> > the last time I made this modification was on the Linux-LTS-5.10.19 >> kernel : >> > ( >> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/block/blk-core.c?h=v5.10.19 >> ) >> > >> > $ diff -u 5.10.19.original/blk-core.c 5.10.19.me/blk-core.c >> > --- 5.10.19.original/blk-core.c 2023-03-15 13:44:20.176929833 +0100 >> > +++ 5.10.19.me/blk-core.c 2023-03-15 13:44:02.353596114 +0100 >> > @@ -706,7 +706,7 @@ >> > "Trying to write to read-only block-device %s (partno %d)\n", >> > bio_devname(bio, b), part->partno); >> > /* Older lvm-tools actually trigger this */ >> > - return false; >> > + return true; >> > } >> > >> > return false; >> > >> > the compilation of the modified LTS 5.10.19 kernel went well and the >> correction seems to do the job... >> > >> > >> > since this last time (2022/01), the source file blk-core.c has been >> modified a lot and the bio_check_ro function is part of these modifications >> : >> > ( >> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/block/blk-core.c?h=v6.1.15 >> ) >> > >> > $ diff -u 5.10
Re: linux headers
thank you for your feedback Ralf which is in line with Genes' explanations. the application that could fall into the mentioned category and that I am paying attention to is lvm, but previous tests show that this is not the case (the lvm2 package provided by ArchLinux behaves as expected with the recompiled modified kernel). regards, lacsaP. Le lun. 20 mars 2023 à 12:49, Ralf Mardorf a écrit : > On Mon, 2023-03-20 at 12:27 +0100, lacsaP Patatetom wrote: > > if I understand correctly, I can install my package linux-lts-perso- > > 6.1.15-2-x86_64.pkg.tar.zst, boot on it (eg. "my" kernel) and continue > > to use the binaries present on my system while they have not been > > compiled with its (new) headers and especially for the binaries that > > call the functions present in the blk-core.c file ? > > I still don't know if I understand you and > https://www.google.com/search?q=translate doesn't help. > > You can install > > core/linux-lts 6.1.20-1 > core/linux-lts-docs 6.1.20-1 > core/linux-lts-headers 6.1.20-1 > > and also your > > linux-lts-perso 6.1.15-2 > linux-lts-perso-docs6.1.15-2 > linux-lts-perso-headers 6.1.15-2 > > neither the version, nor the pkgrel matter. > You can run one or the other kernel and you can build modules for what > ever kernel you like, see > > https://wiki.archlinux.org/title/Dynamic_Kernel_Module_Support#Rebuild_modules > . > > You (usually) can use a binary such as /usr/bin/vim with one or the > other kernel, but you might need to build modules to use something like > virtualbox. > > In your case something like systemd or xorg is irrelevant, but something > like this might depend closer on kernel versions, than vim does. > > Regards, > Ralf >
Re: linux headers
it's clear yes, thanks for these explanations/clarifications. Le lun. 20 mars 2023 à 12:42, Genes Lists a écrit : > > > > > if I understand correctly, I can install my package > > linux-lts-perso-6.1.15-2-x86_64.pkg.tar.zst, boot on it (eg. "my" > > kernel) and continue to use the binaries present on my system while they > > have not been compiled with its (new) headers and especially for the > > binaries that call the functions present in the blk-core.c file ? > > The kernel headers are used to compile out-of-tree kernel modules for > that kernel. You should always install kernel and its companion headers > file. While there may be cases where the headers are not actually > changed and it may work - good policy is always install both kernel and > its companion headers package. If you don't compile out of tree kernel > modules then you may not even need to install headers. > > Hope that is clear. > > > >
Re: linux headers
Le lun. 20 mars 2023 à 12:00, Genes Lists a écrit : > On 3/20/23 06:44, lacsaP Patatetom wrote: > > Please don't top post on mailing lists. > I use GMail and just click on "Respond to all" : is this the "top post" ? should I only answer you or not put you individually in the answer since you are in the list ? > > I don't understand what 'problem' you are speaking of. All you've asked > is if you can install a kernel headers from a different build - the > general answer is "no" - don't ever do that. > I don't understand either : it makes me think of a dialogue of the deaf :-) > > I already explained if you want to compile kernel package that you hav > emodified, bump pkgrel and compile it - it will create both kernel and > kernel headers package - install and use them both. > if I understand correctly, I can install my package linux-lts-perso-6.1.15-2-x86_64.pkg.tar.zst, boot on it (eg. "my" kernel) and continue to use the binaries present on my system while they have not been compiled with its (new) headers and especially for the binaries that call the functions present in the blk-core.c file ? > > Cross compile?? Unless you're compiling on one architecture for another > I don't understand the question. Since you're compiling a kernel for a > VM your host and VM are presumably both x86-64. > I put cross in quotes to mean some analogy with this one (eg. cross-compilation: x86 > arm / me: 6.1.20 > 6.1.15) > > Honestly, my best advice to you is stop trying to build kernels. > > >
Re: linux headers
not renaming the package and modifying pkgrel can indeed lead me to confusion, but it's just personal compilation. ok : good practices you encourage ;-) version 6.1.20 has just been downloaded and will be soon in place but my question remains : how to target 6.1.15 when evolving under 6.x.y (or 6.1.z) ? virtual machine (this is what I use to get around the problem but it seems pretty heavy) ? "cross" compilation ? make parameters ? environment variables ? thank you for these precisions which unfortunately do not enlighten me much :-( regards, lacsaP. Le lun. 20 mars 2023 à 11:02, Genes Lists a écrit : > On 3/20/23 05:27, lacsaP Patatetom wrote: > > hi, > > > > > - When you change the source you must also bump pkgrel as the package > is now different. > > - If you want to build your own version of an Arch package, you should > not use same package name as the official Arch package - this will only > lead to bad things. Change the package name to something else. > > > - current kernel LTS is 6.1.20 so probably you should throw away > 6.1.15 and use that anyway. > > > best, > > gene > > > >
linux headers
hi, I have some questions about the compilation process which I am not familiar with. #1 using ArchLinux PKGBUILD, I recompiled the LTS kernel with a slight change introduced in the block/blk-core.c file and two files were generated : linux-lts-6.1.15-1-x86_64.pkg.tar.zst and linux-lts-headers-6.1.15-1-x86_64.pkg.tar.zst. on the other hand, I had previously compiled packages that used linux-lts-headers-6.1.15-1-x86_64.pkg.tar.zst : do I have to recompile them after the change ? #2 my host kernel has been upgraded to 6.1.19-1-lts : how do I compile to 6.1.15-1-lts from 6.1.19-1-lts? regards, lacsaP.
Re: bio_check_ro @ blk-core.c
hi Emil,
forgive me if this is the third time I've replied to this message but I
received a moderation warning the two previous times that my reply was over
40Kb when my preparation file was only 13Kb...
I haven't had any feedback about this moderation since last week, so I
don't know if you received my answer...
this one concluded that the recent version of LVM integrated in the ISO
image of ArchLinux modifies a disk, even if this one and all its partitions
are set as read-only (chmod 444 /dev/sdX* && blockdev --setro /dev/sdX*
with udev rule).
thank you for this investigation, this history.
regards; lacsaP.
Le mer. 15 mars 2023 à 16:36, Emil Velikov a
écrit :
> Greetings Pascal,
>
> After following the links I see what's happening. Essentially:
> - Kernel gained RO/RW correctness check - circa Jan 2018, kernel
> commit 721c7fc701c71f693307d274d2b346a1ecd4a534
> - LVM was initially buggy but later fixed, circa Mar 2018,
> - Kernel check got partially reverted because broken LVM is still
> used - circa Aug 2018, kernel commit
> a32e236eb93e62a0f692e79b7c3c9636689559b9
> - People used an out of tree patch, reinstating the correctness check
> - The function return type was dropped since it is unused - Sep 2022,
> kernel commit bdb7d420c6f6d2618d4c907cd7742c3195c425e2
> - kernel patch no longer applies, correct behaviour cannot be enforced
>
> To unblock yourself, it will be a matter of reverting
> bdb7d420c6f6d2618d4c907cd7742c3195c425e2 and then
> a32e236eb93e62a0f692e79b7c3c9636689559b9.
>
> For the mid/long run, one should consider a proper upstream solution:
>
> Assuming I'm in your position, I would dig through the data in the
> linked commits and estimate which/how many distributions ship with
> buggy LVM. Then formulate a comprehensive cover letter, proposing a)
> reverts (if LVM is no longer used in the wild) or b) reverts && a
> (KCONFIG, sysctl, other) toggle to control the behaviour.
>
> Hope that helps,
> Emil
>
> On Wed, 15 Mar 2023 at 13:38, Pascal wrote:
> >
> > hi Emil,
> >
> > in view of your answer and after rereading my email, I realize that I
> was confused in my request.
> > here it is, I hope, more clearly reformulated :-)
> >
> > first of all, I use ArchLinux to, from time to time, compile the
> slightly modified LTS kernel, and this from PKGBUILD provided by ArchLinux
> at some point.
> >
> > some technologies such as LVM do not take into account the read-only
> applied on a block device.
> > see the two links provided in the previous exchanges for more details...
> >
> >
> > until now, I recompiled the kernel by applying a slight modification to
> the bio_check_ro function present in the blk-core.c source file.
> > the last time I made this modification was on the Linux-LTS-5.10.19
> kernel :
> > (
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/block/blk-core.c?h=v5.10.19
> )
> >
> > $ diff -u 5.10.19.original/blk-core.c 5.10.19.me/blk-core.c
> > --- 5.10.19.original/blk-core.c 2023-03-15 13:44:20.176929833 +0100
> > +++ 5.10.19.me/blk-core.c 2023-03-15 13:44:02.353596114 +0100
> > @@ -706,7 +706,7 @@
> > "Trying to write to read-only block-device %s (partno %d)\n",
> > bio_devname(bio, b), part->partno);
> > /* Older lvm-tools actually trigger this */
> > - return false;
> > + return true;
> > }
> >
> > return false;
> >
> > the compilation of the modified LTS 5.10.19 kernel went well and the
> correction seems to do the job...
> >
> >
> > since this last time (2022/01), the source file blk-core.c has been
> modified a lot and the bio_check_ro function is part of these modifications
> :
> > (
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/block/blk-core.c?h=v6.1.15
> )
> >
> > $ diff -u 5.10.19.original/blk-core.c 6.1.15.original/blk-core.c
> > --- 5.10.19.original/blk-core.c 2023-03-15 13:44:20.176929833 +0100
> > +++ 6.1.15.original/blk-core.c 2023-03-15 13:50:36.560271323 +0100
> > @@ -14,11 +14,10 @@
> > */
> > #include
> > #include
> > -#include
> > #include
> > #include
> > -#include
> > ...
> > @@ -681,40 +483,22 @@
> > }
> >
> > late_initcall(fail_make_request_debugfs);
> > -
> > -#else /* CONFIG_FAIL_MAKE_REQUEST */
> > -
> > -static inline bool should_fail_request(struct hd_struct *part,
> > - unsigned int bytes)
> > -{
> > - return false;
> > -}
> > -
> > #endif /* CONFIG_FAIL_MAKE_REQUEST */
> >
> > -static inline bool bio_check_ro(struct bio *bio, struct hd_struct *part)
> > +static inline void bio_check_ro(struct bio *bio)
> > {
> > - const int op = bio_op(bio);
> > -
> > - if (part->policy && op_is_write(op)) {
> > - char b[BDEVNAME_SIZE];
> > -
> > + if (op_is_write(bio_op(bio)) && bdev_read_only(bio->bi_bdev)) {
> > if (op_is_flush(bio->bi_opf) && !bio_sectors(bio))
> > - return false;
> > -
> > - WARN_ONCE(1,
> > - "Trying to write to read-only block-device %s (partno
> %d)\n",
> > -
