Re: How to build GCC for a specific machine using pbuilder?
On 19/06/2020 18:36, deloptes wrote: > Mikhail Morfikov wrote: > >> I've read something about setting flags like: --enable-languages= or >> --disable-multilib , which I think would speed the whole process up, but >> unfortunately I have no idea which file in the debian/ dir I should change >> to build the GCC for my machine only. Any suggestions? Also how to >> include/exclude patches so they were applied to the source -- there's no >> "debian/patches/series" file. > > usually it is in debian/rules (this is the debians make file) > > read the docs first - the thing with the patches is explained on the debian > wiki like > https://wiki.debian.org/debian/patches > https://www.debian.org/doc/manuals/maint-guide/modify.en.html > https://wiki.debian.org/debian/patches > > be patient it works > > I know, but have you ever seen the debian/ dir in the gcc sources? Take a look here[1]. [1]: https://salsa.debian.org/toolchain-team/gcc signature.asc Description: OpenPGP digital signature
How to build GCC for a specific machine using pbuilder?
I wanted to change the GCC source a little bit by adding some patches that aren't available in Debian. I downloaded the Debian GCC source via "apt-get source" . I tried to build the source in the Debian way (using pbuilder) just to test how much time would it take. I gave up after 2h because probably it builds everything for everyone, and it's not really what I wanted it to do. I've read something about setting flags like: --enable-languages= or --disable-multilib , which I think would speed the whole process up, but unfortunately I have no idea which file in the debian/ dir I should change to build the GCC for my machine only. Any suggestions? Also how to include/exclude patches so they were applied to the source -- there's no "debian/patches/series" file. signature.asc Description: OpenPGP digital signature
Re: Is there a way to load/unload a firmware manually?
I think I finally solved this.
Basically not all files from /lib/firmware/ are copied to the initrd image,
which means that there's some mechanism, which decides what to add (and I
have no idea what that is). Looking for info, I came across some
suggestions that only the drivers compiled as kernel modules are subjected
to this behavior. So basically when you've built a driver into the kernel,
you have to take care of everything manually. So in my case, I have every
single module built into my kernel, so there's two ways to handle this.
I can use the CONFIG_EXTRA_FIRMWARE_DIR= and CONFIG_EXTRA_FIRMWARE= kernel
options, or I can add a hook to initramfs config (under
/etc/initramfs-tools/hooks/), which would look like the one following:
#!/bin/sh -e
# Copy missing firmware files
PREREQ=""
prereqs () { echo "${PREREQ}"; }
case "${1}" in prereqs) prereqs; exit 0 ;; esac ;
. /usr/share/initramfs-tools/hook-functions
echo -n "Copying missing firmware files... "
[ ! -d "${DESTDIR}/lib/firmware/" ] && mkdir -p ${DESTDIR}/lib/firmware/
[ ! -d "${DESTDIR}/lib/firmware/brcm/" ] && mkdir -p
${DESTDIR}/lib/firmware/brcm/
cp /lib/firmware/iwlwifi-6000g2a-6.ucode ${DESTDIR}/lib/firmware/
cp /lib/firmware/brcm/BCM20702A1-0a5c-21e6.hcd ${DESTDIR}/lib/firmware/brcm/
echo "done."
exit 0
And then the firmware files would finally get into the initrd image:
# lsinitramfs /boot/initrd.img-5.5.8-amd64 | grep -i firm
usr/lib/firmware
usr/lib/firmware/brcm
usr/lib/firmware/brcm/BCM20702A1-0a5c-21e6.hcd
usr/lib/firmware/iwlwifi-6000g2a-6.ucode
usr/lib/udev/rules.d/50-firmware.rules
which I think solves the issue for good. :]
signature.asc
Description: OpenPGP digital signature
Re: Is there a way to load/unload a firmware manually?
On 07/03/2020 13:50, deloptes wrote: > Well, I build my own kernels and they all have the firmware > directory included. Why not compare all relevant parts instead > complaining?!I regenerate two initrd images at the same machine and system > using *update-initramfs -u -k all* . So I think the same initramfs config is used in both cases during the process, right? But one of the generated image has the lib/firmware dir included and the other has not. The only one thing I could think of what can cause this problem is the kernel config (as I mentioned in one of the previous messages). But I compared the /boot/config* files grep'ing for "firmware" and they have the same options set. So I have no idea what could cause the issue. If I knew, or at least had some clues, I wouldn't complain and ask for help to solve the issue. What else should I compare? signature.asc Description: OpenPGP digital signature
Re: Is there a way to load/unload a firmware manually?
On 07/03/2020 00:28, deloptes wrote: > try with the stock kernel > modprobe -v iwlwifi > > or whatever the module name is and update initrd. > Check the results > lsinitramfs /boot/initrd.img- No, this does nothing, still only the Debian kernel's initrd has the firmware dir included. It's really weird that this is different for stock and not stock kernel... signature.asc Description: OpenPGP digital signature
Re: Is there a way to load/unload a firmware manually?
On 06/03/2020 18:42, deloptes wrote: > Just check the configuration in /etc/initramfs-tools/ No, there's nothing useful for me there, so it has to be in some other place, hmm... signature.asc Description: OpenPGP digital signature
Re: Is there a way to load/unload a firmware manually?
On 06/03/2020 16:49, deloptes wrote: > I think if the intel driver is not compiled in the kernel, you do not > have to compile the firmware. > > So what you are actually saying, that when you have the stock kernel > and load the intel driver, it does not pick up the firmware? > > Can you confirm this? No, I'm using my own kernel and not the Debian's one, but I didn't have to build the firmware into the kernel image before (in the case of the old WiFi card and old laptop). Now after I moved in to the new laptop I have to, and I don't know why. I just checked, and it looks like the usr/lib/firmware/ dir is included in the stock Debian kernel's initrd image, but it's not in mine kernel's initrd. That's weird because I generate the images via *update-initramfs -u -k all* all the time. So why does one have this dir included and the other not? I think when I find out what's going on here I will solve this riddle. I bet something is missing in the kernel config. signature.asc Description: OpenPGP digital signature
Re: Is there a way to load/unload a firmware manually?
On 06/03/2020 07:50, deloptes wrote: > So if you compile the driver static in the kernel I am not sure 100% > but it should have the firmware already somewhere to be loaded. This > is interesting question. I think most of the usecases include using > initrd that would have driver and firmware. I'm just asking because I had a BCM WiFi card in my previous laptop and that card needed firmware-brcm80211 . Now I have a new laptop, and it has an Intel WiFi, which needs firmware-iwlwifi . I have the same setup (LUKSv2+LVM), and the exact same system (it was moved to the new laptop), and in the case of the Intel WiFi I have to compile the firmware into the kernel using the following kernel options: CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware" CONFIG_EXTRA_FIRMWARE="iwlwifi-6000g2a-6.ucode" So the question I'm asking myself is why weren't the options needed in the case of my old WiFi card? It also wanted its firmware but it looks like it could be loaded after the system partition was decrypted. So it's weird... signature.asc Description: OpenPGP digital signature
Is there a way to load/unload a firmware manually?
Basically there's an option to load/unload a kernel module via modprobe and modprobe -r . Is there a way to do this with, for instance, WiFi firmware? Also, what happens to the loaded firmware when you unload the corresponding module? And another question: when I compile a module into the kernel and that module needs some firmware -- can this firmware be loaded later and make the hardware work properly, or this can't be done and you have to include the firmware in the kernel image itself?
Re: What's the purpose of initrd.img{,.old} and vmlinuz{,.old} symlinks in the root dir?
On 01/03/2020 17:15, mick crane wrote: > On 2020-02-29 18:17, Mikhail Morfikov wrote > >> vmlinuz -> boot/vmlinuz-5.4.0-4-amd64 >> lrwxrwxrwx 1 root root 24 2020-02-24 00:37:53 >> vmlinuz.old -> boot/vmlinuz-5.5.4-amd64 >> > > .old is pointing to a newer kernel ? > > mick > Yes, it is because I updated recently the debian kernel. So I think it thinks the older is newer now. But after moving the links to the /boot/ dir, I get: $ ls -al /boot/ | egrep "vmlinuz|initrd" lrwxrwxrwx 1 root root 22 2020-03-01 15:18:21 initrd.img -> initrd.img-5.5.4-amd64 -rw-r--r-- 1 root root 39127233 2020-02-14 17:23:07 initrd.img-5.4.0-4-amd64 -rw-r--r-- 1 root root 16005450 2020-03-01 14:41:38 initrd.img-5.5.4-amd64 lrwxrwxrwx 1 root root 24 2020-03-01 15:18:21 initrd.img.old -> initrd.img-5.4.0-4-amd64 lrwxrwxrwx 1 root root 19 2020-03-01 15:18:21 vmlinuz -> vmlinuz-5.5.4-amd64 -rw-r--r-- 1 root root 5627632 2020-02-13 06:14:49 vmlinuz-5.4.0-4-amd64 -rw-r--r-- 1 root root 9331760 2020-02-26 09:38:52 vmlinuz-5.5.4-amd64 lrwxrwxrwx 1 root root 21 2020-03-01 15:18:21 vmlinuz.old -> vmlinuz-5.4.0-4-amd64 So the .old points now to the older one. But I don't need the debian kernel anyway since I build it on my own. I haven't removed it just in case. :] But I think I will remove it when I set everything up to avoid such situations. signature.asc Description: OpenPGP digital signature
Re: What's the purpose of initrd.img{,.old} and vmlinuz{,.old} symlinks in the root dir?
On 01/03/2020 16:53, David Wright wrote: > I've read here that Grub can decrypt LUKS, but currently only v1, > at least in buster, so no help to you. Actually grub supports LUKSv2[1], but I haven't tried it yet. [1]: https://git.savannah.gnu.org/cgit/grub.git/commit/?id=365e0cc3e7e44151c14dd29514c2f870b49f9755 signature.asc Description: OpenPGP digital signature
Re: What's the purpose of initrd.img{,.old} and vmlinuz{,.old} symlinks in the root dir?
On 01/03/2020 02:15, David Wright wrote: > They're a convenience. If you want them kept in /boot, then edit > /etc/kernel-img.conf and linux-update-symlinks will recreate them > there when the kernel is updated. Ditto if you want them removed. I didn't know there's even such an option. But yes, it creates links in /boot/ now. >> Also, I'm trying to configure refind EFI boot manager, and >> basically I don't want to change its config file with each kernel >> update (the numbers in the file names change). > > I'm not familiar with that, but one of the reasons there are links > in root is for that very reason: their names don't change. That's why I need those links in /boot/ , so refind would easily pick them up. > You don't say why *you* think it's better to create links in /boot, > so I'm not sure why we're expected to think so too. But if you want > them in both places, I think you have to maintain them in the other > location yourself. I thought it was obvious, but I write it again to be clear. I'm using LUKSv2+LVM setup and (so far) syslinux/extlinux as a bootloader in MBR/MS-DOS partition layout (this will change to refind + EFI soon). So my machine is encrypted entirely, and only the /boot/ (and future ESP) partition remains unencrypted. When my system creates the links to the initrd and kernel in / , they're useless since you have to decrypt the root partition in order to get to those links, and in order to decrypt the partition, you have to load the kernel first, but when you load the kernel, you don't need the links anymore... So as you can see the better place for the links is in /boot/ and not in / , at least in the case of fully encrypted installation setups. signature.asc Description: OpenPGP digital signature
What's the purpose of initrd.img{,.old} and vmlinuz{,.old} symlinks in the root dir?
I have an encrypted (LUKSv2) LVM setup with a separate unencrypted /boot/ partition. When I install a new kenrel in the system, the following symlinks are created in the root directory (/): # ls -al / ... lrwxrwxrwx 1 root root 29 2020-02-14 17:22:18 initrd.img -> boot/initrd.img-5.4.0-4-amd64 lrwxrwxrwx 1 root root 27 2020-02-24 00:37:53 initrd.img.old -> boot/initrd.img-5.5.4-amd64 ... lrwxrwxrwx 1 root root 26 2020-02-14 17:22:18 vmlinuz -> boot/vmlinuz-5.4.0-4-amd64 lrwxrwxrwx 1 root root 24 2020-02-24 00:37:53 vmlinuz.old -> boot/vmlinuz-5.5.4-amd64 So I have a question here: what's the purpose of the links? Also, I'm trying to configure refind EFI boot manager, and basically I don't want to change its config file with each kernel update (the numbers in the file names change). Wouldn't be better to create the links under /boot/ dir instead (or in addition to the already existing ones, if they serve any purpose)? signature.asc Description: OpenPGP digital signature
How to build FreeTube using pbuilder?
There's an app called FreeTube[1], which is a nice alternative for other apps playing YT vids. Unfortunately its source is a little bit different than regular sources which can be build using the Debian build system (pbuilder). Does anyone know how to build this app in the Debian way and could give me some hints on how to do it properly? I know it has the upstream .deb package to be installed in the system, but I wanted to build myself. [1] https://github.com/FreeTubeApp/FreeTube signature.asc Description: OpenPGP digital signature
Re: How to configure the hugepages group in Debian?
On 07/05/2019 14:06, Jonas Smedegaard wrote: > You probably use systemd: system/dev-hugepages.mount Yes that was it. Thanks. signature.asc Description: OpenPGP digital signature
Re: How to configure the hugepages group in Debian?
On 07/05/2019 13:51, Reco wrote: > This particular systemd part is called dev-hugepages.mount. I see, yes now it works well. Thanks for the info. signature.asc Description: OpenPGP digital signature
How to configure the hugepages group in Debian?
There's an entry on the Debian wiki[1] where people can read about the hugepages in Debian, but I don't really think this article is up to date. Basically when you look at the mount points in the system, you can also see this one: # mount | grep -i huge hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M) I don't have any fstab entries that would allow to mount /dev/hugepages . So something is mounting it automatically, but I couldn't find any info what that would be. It's not really a problem what and where mounts the resource, but I wanted to configure the group that can be set via the "vm.hugetlb_shm_group" sysctl parameter. There's info on the Debian wiki how to do this, and I wanted to add the following entry to the /etc/fstab file in order to configure the group: hugetlbfs /dev/hugepages hugetlbfs rw,relatime,pagesize=2M,mode=1770,gid= 0 0 But this doesn't really work. I mean, those mount options aren't set or are reset. So how to configure this thing? [1] https://wiki.debian.org/Hugepages signature.asc Description: OpenPGP digital signature
Re: How to limit udisks2 rules to a specific device?
On 2018-04-09 12:30, Richard Hector wrote: > On 09/04/18 04:50, Mikhail Morfikov wrote: >> When it comes to mounting devices, I have two simple rules: >> 1) only root can do it. >> 2) in some cases only defined users can mount some specific devices. >> >> So I want to forbid all users (except root) to access all devices that people >> can possibly plug into a USB port. But devices can be distinguished by, for >> instance, some serial number (or something else). I have a USB drive, and I >> want >> it to be accessed and mounted by my regular user without asking me for >> password >> each time I do so. > > I assume faking the serial number is too difficult to be worried about? > > Richard > I know little about faking the serial number of a device, but it was just an example. There're lots of things a device can be matched against, and also you can give different privileges to users even when they operate on the same device. And, of course, remember that the message, which is returned to a user, is "Not authorized to perform operation", and not "Not authorized to perform operation due to not whitelisted serial number". :) So it could be difficult to know why you're not able to mount such device in my system. Anyways, I've manged to install the experimental version of policykit. It works well, and I was able to set everything in the way I wanted. signature.asc Description: OpenPGP digital signature
Re: How to limit udisks2 rules to a specific device?
On 2018-04-08 20:00, Brian wrote:
> On Sun 08 Apr 2018 at 18:50:50 +0200, Mikhail Morfikov wrote:
>
> [...]
>> I've seen that people use something similar to the following rule:
>> -
>> /etc/polkit-1/localauthority/50-local.d/20-udisks2.pkla
>> -
>> [Allow morfik to mount devices]
>> Identity=unix-user:morfik;
>> Action=org.freedesktop.udisks2.*;
>> ResultAny=no
>> ResultInactive=no
>> ResultActive=yes
>> -
>> And this is a little bit better than the previous solution because it gives
>> me
>> the ability to specify users/groups , and only the parties can do some
>> actions,
>> like for instance mounting a device (to be viewed via pkaction). The problem
>> here is that I can't choose which devices should be accessed by the identity
>> --
>> I'm able only to set which actions can be allowed.
>>
>> In the polkit manual[1], there's an example that would do exactly what I
>> want.
>> I'm speaking about this:
>> --
>> polkit.addRule(function(action, subject) {
>> if (action.id.indexOf("org.freedesktop.udisks2.") == 0 &&
>> action.lookup("drive.vendor") == "SEAGATE" &&
>> action.lookup("drive.model") == "ST3300657SS" &&
>> subject.isInGroup("engineers")) {
>> return polkit.Result.YES;
>> }
>> }
>> });
>> --
>> I bet there's also probably something like:
>> action.lookup("drive.serial")
>> but I don't really know how to get those values yet.
>>
>> Anyways, I don't think the above rule can be used with the polkit version
>> that's
>> currently in Debian, which is 0.105 . That rule can be used when you deal
>> with
>> 0.106+ , and 0.113 is available in the experimental branch, but
>> unfortunately it
>> can't be installed due to dependencies problems.
>>
>> Is there a way to convert that rule somewhat or is this functionality
>> specific
>> to the polkit v0.106+? Or maybe is there another way to achieve what I want?
>
> Converting from the JavaScript to the old style? Probably not. Converting
> the other way? Maybe.
>
> https://lists.debian.org/debian-user/2016/01/msg00209.html
>
I think I need the newer polkit version.
signature.asc
Description: OpenPGP digital signature
How to limit udisks2 rules to a specific device?
I've never been using udisks/udisks2 before because I didn't really need it, but
now I thought I could see what the tool is capable of and give it a chance.
When it comes to mounting devices, I have two simple rules:
1) only root can do it.
2) in some cases only defined users can mount some specific devices.
So I want to forbid all users (except root) to access all devices that people
can possibly plug into a USB port. But devices can be distinguished by, for
instance, some serial number (or something else). I have a USB drive, and I want
it to be accessed and mounted by my regular user without asking me for password
each time I do so.
So far, I created two UDEV rules:
-
SUBSYSTEMS=="usb", \
ENV{UDISKS_IGNORE}="1", \
ENV{UDISKS_AUTO}="0", \
ENV{UDISKS_SYSTEM}="1"
ATTRS{serial}=="some-serial-number", \
ENV{UDISKS_IGNORE}="1", \
ENV{UDISKS_AUTO}="0", \
ENV{UDISKS_SYSTEM}="0"
-
The two rules do their job. Basically, the first rule marks all USB devices as
internal/system, and the second rule allows only the specific device to be
accessed by a regular user (later on in udisks). This, of course, allow all
regular users (not just me) to mount the device, so it's not really what I want,
but it's close enough to use it in this form.
I've seen that people use something similar to the following rule:
-
/etc/polkit-1/localauthority/50-local.d/20-udisks2.pkla
-
[Allow morfik to mount devices]
Identity=unix-user:morfik;
Action=org.freedesktop.udisks2.*;
ResultAny=no
ResultInactive=no
ResultActive=yes
-
And this is a little bit better than the previous solution because it gives me
the ability to specify users/groups , and only the parties can do some actions,
like for instance mounting a device (to be viewed via pkaction). The problem
here is that I can't choose which devices should be accessed by the identity --
I'm able only to set which actions can be allowed.
In the polkit manual[1], there's an example that would do exactly what I want.
I'm speaking about this:
--
polkit.addRule(function(action, subject) {
if (action.id.indexOf("org.freedesktop.udisks2.") == 0 &&
action.lookup("drive.vendor") == "SEAGATE" &&
action.lookup("drive.model") == "ST3300657SS" &&
subject.isInGroup("engineers")) {
return polkit.Result.YES;
}
}
});
--
I bet there's also probably something like:
action.lookup("drive.serial")
but I don't really know how to get those values yet.
Anyways, I don't think the above rule can be used with the polkit version that's
currently in Debian, which is 0.105 . That rule can be used when you deal with
0.106+ , and 0.113 is available in the experimental branch, but unfortunately it
can't be installed due to dependencies problems.
Is there a way to convert that rule somewhat or is this functionality specific
to the polkit v0.106+? Or maybe is there another way to achieve what I want?
-- Morfik
[1] https://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html
signature.asc
Description: OpenPGP digital signature
Re: How to redirect messages in ~/.xsession-errors to a FIFO device?
On 2018-04-06 18:56, Greg Wooledge wrote: > On Fri, Apr 06, 2018 at 06:45:20PM +0200, Mikhail Morfikov wrote: >> Basically even the standard "exec ..." in the /etc/X11/Xsession file (with >> changed $ERRFILE) works fine, but I have to "cat" the FIFO device first >> (without >> using systemd). The same with your exec command -- there's no difference in >> working. > > Opening one end of a FIFO blocks until the OTHER end is also opened. > This is why the first process to open the FIFO should be launched in > the background (it is going to block), if both ends are coming from the > same parent script. > I just realized that. I have some other FIFO devices that rsyslog uses, and based on that I thought rsyslog just sends messages to the FIFO devices because it was working just fine (without any additional steps, except creating the FIFO device), but it turns out that rsyslog has its own queues that buffer the messages, and when I "cat" the FIFO devices later on, rsyslog sends what's in the queues and I get the output in the desktop terminal. The same with systemd FIFO sockets -- they also have queues to buffer messages, and they pass them when I "cat" the FIFO device. So that's basically the difference between rsyslog/systemd sockets and manually created FIFO devices, and now I get why this didn't work OOTB, and why it won't work without some additional steps. :) > I'm assuming that when you speak of "cat" you mean a process that opens > the FIFO for reading. > Yes. signature.asc Description: OpenPGP digital signature
Re: How to redirect messages in ~/.xsession-errors to a FIFO device?
On 2018-04-06 17:53, Greg Wooledge wrote: > On Fri, Apr 06, 2018 at 05:48:35PM +0200, Mikhail Morfikov wrote: >> If I set $ERRFILE to the FIFO device, processing of the script will be >> stopped >> in the point where "exec ..." appears (before sourcing the >> /etc/X11/Xsession.d/ >> dir). > > You need to run something in the background which opens the FIFO for > reading before you run foreground commands that try to open the FIFO > for writing. > > Typically you would create the FIFO, then launch the reader (logger) > in the background, then carry on with opening FIFO writers. > So basically, the systemd's solution (in the first message) is the only one that will work OOTB without any other additional steps, right? signature.asc Description: OpenPGP digital signature
Re: How to redirect messages in ~/.xsession-errors to a FIFO device?
On 2018-04-06 18:29, Don Armstrong wrote:
> On Fri, 06 Apr 2018, Mikhail Morfikov wrote:
>> Basically, all messages returned by X-applications are redirected to the
>> ~/.xsession-errors file.
> [...]
>> Unfortunately, the ~/.xsession-errors file grows in size, and after a
>> few hours it's around 20-30 MiB, and the content of the file isn't removed
>> with
>> each X session restart.
>
> I personally do this:
>
> DATE=$(date "+%Y%m%d_%H%M%S")
> # track xsession errors
> mv ~/.xsession-errors ~/.xsession-errors_${DATE};
> ln -sf ~/.xsession-errors_${DATE} ~/.xsession-errors-current;
> # delete old xsession error files
> find ~/ -maxdepth 1 -mindepth 1 -type f \
> -iname '.xsession-errors_*' -ctime +30 -delete;
>
> in my .xsession.[1]
>
>> Is it even possible to redirect the content of the file to the FIFO device in
>> this way?
>
> The general way to do this is to do re-exec the shell with different
> output options, something like this:
>
> exec > /dev/log-xsession-errors 2>&1;
>
> in your .xsession [or whatever you're using to start things] after
> testing that the FIFO works.
Basically even the standard "exec ..." in the /etc/X11/Xsession file (with
changed $ERRFILE) works fine, but I have to "cat" the FIFO device first (without
using systemd). The same with your exec command -- there's no difference in
working.
>
> 1: https://git.donarmstrong.com/x_base.git/b/.xsession
>
signature.asc
Description: OpenPGP digital signature
Re: How to redirect messages in ~/.xsession-errors to a FIFO device?
On 2018-04-06 15:48, to...@tuxteam.de wrote: > On Fri, Apr 06, 2018 at 03:18:08PM +0200, Mikhail Morfikov wrote: >> Basically, all messages returned by X-applications are redirected to the >> ~/.xsession-errors file [...] > >> till a terminal with "cat" is started inside of the X session. I'm just >> wondering whether similar solution can be achieved without systemd. > > You might consider adding one file in /etc/X11/Xsession.d which does your > trick. Those files are sourced *after* the exec >> "$ERRFILE"... Could you tell me what in your opinion I should do because I'm a little bit confused. If I set $ERRFILE to the FIFO device, processing of the script will be stopped in the point where "exec ..." appears (before sourcing the /etc/X11/Xsession.d/ dir). If I put "exec ..." in some file under the /etc/X11/Xsession.d/ dir (commenting it out from the main Xsession script), the X session won't start either because processing of the Xsession script will stall at the one of the sourced files where "exec ..." is found. So how do you want to do it? > > If you want to pass on whatever went to ERRFILE so-far, you might want to > "cat" it... > > Cheers > -- t > signature.asc Description: OpenPGP digital signature
How to redirect messages in ~/.xsession-errors to a FIFO device?
Basically, all messages returned by X-applications are redirected to the ~/.xsession-errors file. In some desktop environments this file is emptied with each X session restart. At least that was the case of my Openbox + LightDM setup. Now, I'm trying to migrate to KDE/Plasma5, and as a part of it, I installed the SDDM login manager. I haven't really finished the migration process yet, but since SDDM looks better than LightDM, I wanted to replace it. Unfortunately, the ~/.xsession-errors file grows in size, and after a few hours it's around 20-30 MiB, and the content of the file isn't removed with each X session restart. In the /etc/X11/Xsession file, there's something like this: --- ERRFILE=$HOME/.xsession-errors ... exec >>"$ERRFILE" 2>&1 --- Since I'm using FIFO devices for some rsyslog logs, I thought I also could use one of such devices for the ~/.xsession-errors file content, but changing the ERRFILE variable to some /dev/log-fifo device causes the start of the X session to stall -- it hangs since the FIFO device needs (probably) some process to read the content of the device, for instance, "cat /dev/log-fifo", but unfortunately I can't add anything in the script after the above command so it could "cat" the device (it works when I do it via TTY). Is it even possible to redirect the content of the file to the FIFO device in this way? I'm asking because I temporary created the following systemd .socket file: - # cat /etc/systemd/system/log-xsession-errors.socket [Unit] Description=log-xsession-errors socket DefaultDependencies=no Before=sockets.target PartOf=log-xsession-errors.service [Socket] ListenFIFO=/dev/log-xsession-errors SocketMode=0600 SocketUser=morfik SocketGroup=morfik RemoveOnStop=true PipeSize=1M [Install] WantedBy=sockets.target - And some service for it: - # cat /etc/systemd/system/log-xsession-errors.service [Unit] Description=log-xsession-errors service DefaultDependencies=no [Service] ExecStart=/bin/true RemainAfterExit=yes [Install] Also=log-xsession-errors.socket - And in this solution, systemd creates the device and starts some process to listen on it, and there's no problem with starting the X session because as soon as some X messages show up, they're sent to the FIFO device, and that device has 1 MiB buffer set, and probably that's why it can hold the messages for some time till a terminal with "cat" is started inside of the X session. I'm just wondering whether similar solution can be achieved without systemd. -- Morfik signature.asc Description: OpenPGP digital signature
Re: How to execute user's scripts when upgrading a certain package via apt/aptitude
On 2018-03-30 04:00, John Crawley (johnraff) wrote: > On 2018-03-29 09:15, Abdullah Ramazanoglu wrote: >> On Wed, 28 Mar 2018 20:00:34 +0200 Mikhail Morfikov said: >>> Is there some variable that holds, for instance, a list of the >>> packages that apt wants to upgrade? In such way it would be easy to >>> set this up. > > apt list --upgradable > will print out a list, but the output of 'apt' is not considered suitable for > parsing by scripts (still unstable). > apt-get --simulate upgrade > will also print the packages to be upgraded, along with a lot of noise that > your > script would have to filter. > > But: >> On Wed, 28 Mar 2018 20:18:24 +0200 Mikhail Morfikov said: >>> But I will try to do something with the trigger and see how that will >>> work. > > It looks as if that worked for you. You created a new package > 'firefox-trigger' > with a trigger that looked for upgrades to firefox, right? Yes, it was pretty much it. The trigger also works fine when installing a different version of firefox via "dpkg -i" and also when downgrading the package: -- # dpkg -i firefox_59.0.1-1_amd64.deb dpkg: warning: downgrading firefox from 59.0.2-1 to 59.0.1-1 (Reading database ... 248272 files and directories currently installed.) Preparing to unpack .../firefox_59.0.1-1_amd64.deb ... Unpacking firefox (59.0.1-1) over (59.0.2-1) ... Setting up firefox (59.0.1-1) ... Processing triggers for firefox-trigger (1.0) ... Processing triggers for mime-support (3.60) ... Processing triggers for desktop-file-utils (0.23-2) ... Processing triggers for hicolor-icon-theme (0.17-2) ... Processing triggers for man-db (2.8.2-1) ... -- So I think it won't be causing any problems in the future. > That sounds like the > neatest solution, and I will make a note of it for my personal reference. > Thanks. > signature.asc Description: OpenPGP digital signature
Re: How to execute user's scripts when upgrading a certain package via apt/aptitude
On 2018-03-29 01:03, John Crawley (johnraff) wrote: > On 2018-03-29 03:40, to...@tuxteam.de wrote: >> On Wed, Mar 28, 2018 at 08:18:24PM +0200, Mikhail Morfikov wrote: >>> On 2018-03-28 20:12, Sven Joachim wrote: >>> I really thought there's some easy way to include user's scripts when you >>> want >>> to make some additional changes to the upgraded packages, but it looks like >>> the >>> apt mechanism is a little bit limited. But I will try to do something with >>> the >>> trigger and see how that will work. >> >> I think the trick is to create a (nearly) empty package "my-firefox-custom" >> which depends on firefox and thus pulls it in before its own post-install >> takes over. > This sounds as if it should work, but your custom package would need > upgrading every time Firefox was upgraded, so the automation would be lost. > I think the trigger is working as it should (or am I missing something?). Basically I created the package, installed it and after that I'm upgrading the firefox package, I get the following messages in the log: - # apt-get dist-upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages will be upgraded: firefox 1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B/41.6 MB of archives. After this operation, 3,072 B disk space will be freed. Do you want to continue? [Y/n] Retrieving bug reports... Done Parsing Found/Fixed information... Done (Reading database ... 248259 files and directories currently installed.) Preparing to unpack .../firefox_59.0.2-1_amd64.deb ... Unpacking firefox (59.0.2-1) over (59.0.1-1) ... Processing triggers for mime-support (3.60) ... Processing triggers for desktop-file-utils (0.23-2) ... Setting up firefox (59.0.2-1) ... Processing triggers for man-db (2.8.2-1) ... Processing triggers for hicolor-icon-theme (0.17-2) ... Processing triggers for firefox-trigger (1.0) ... - And as you can see, the trigger "firefox-trigger" is being processed (as many others), but I didn't upgrade my custom package along with firefox. So will it work in the way it should or not? signature.asc Description: OpenPGP digital signature
Re: How to execute user's scripts when upgrading a certain package via apt/aptitude
On 2018-03-28 21:25, David Wright wrote: > On Wed 28 Mar 2018 at 20:00:34 (+0200), Mikhail Morfikov wrote: >> On 2018-03-28 18:58, Andy Smith wrote: >>> On Wed, Mar 28, 2018 at 06:29:06PM +0200, Mikhail Morfikov wrote: >>>> Is there a way to pass some extra commands/script to apt/aptitude so when >>>> the >>>> firefox package is to be upgraded, it would recreate the links >>>> automatically? >>> >>> I've never tried it but looking at "man apt.conf" it seems that >>> setting Apt::Post-Invoke (or possible Apt::Post-Invoke-Success?) >>> might be useful to you, as you could use it to run a script that >>> checks that your firefox setup is as you want it. >> I'm aware of the options, but even if I put some script in Post-Invoke, >> there's >> still a problem concerning how to pass the information to the script that the >> firefox package was upgraded. Is there some variable that holds, for >> instance, a >> list of the packages that apt wants to upgrade? In such way it would be easy >> to >> set this up. But if the script doesn't know which packages are upgraded (or >> just >> the specific one), it has to be run and remove the hard links with each >> upgrade/installation process, and this isn't really what I want to achieve. > > You said these were hardlinks. If so, then the most straightforward > is to look at the link counts. When the old version of the program > and whatever files are involved in the upgrade, is removed (as it > were, because your own links will preserve its existence), the > link count of your hard links will decrease, likely to 1. > > As you probably know, the link count is given by ls -l in the > second field, between the permissions and the owner. > > Cheers, > David. > That could work. signature.asc Description: OpenPGP digital signature
Re: How to execute user's scripts when upgrading a certain package via apt/aptitude
On 2018-03-28 20:12, Sven Joachim wrote: > On 2018-03-28 19:46 +0200, Mikhail Morfikov wrote: > >> On 2018-03-28 19:29, Sven Joachim wrote: >>> On 2018-03-28 18:29 +0200, Mikhail Morfikov wrote: >>> >>>> I have some packages, for instance firefox, which need a little bit of >>>> customization from a user side. So basically when I install the new >>>> version of >>>> firefox, I also have to do some extra steps and so far I've been doing it >>>> manually because I don't know any better way. >>>> >>>> In the case of firefox, I have to create some hard links. Those hard links >>>> are >>>> used as additional executable files to be profiled in AppArmor. But when I >>>> upgrade my system, and firefox is on the package list, the hard links >>>> basically >>>> stop working and they have to be removed and recreated manually after the >>>> upgrade is done. >>>> >>>> Is there a way to pass some extra commands/script to apt/aptitude so when >>>> the >>>> firefox package is to be upgraded, it would recreate the links >>>> automatically? >>> >>> You could use a dpkg trigger for that, a short intro how to do this is >>> on stackoverflow[1]. See also deb-triggers(5). >> Is this a solution for a user or rather for maintainer of the package? I >> think >> it's the second one and hence I can't use it. > > It requires you to create your own package (since there is no other way > to register triggers in dpkg), but it does not have to contain any > files, you only need to include the triggers list and a postinst script > which manages the links. > > An alternative is to use the dpkg's post-invoke option, but that is > rather inefficient, since it will be run on every dpkg invocation and > not only when one of the packages which interest you is > updated/installed/removed. > > Cheers, >Sven > I really thought there's some easy way to include user's scripts when you want to make some additional changes to the upgraded packages, but it looks like the apt mechanism is a little bit limited. But I will try to do something with the trigger and see how that will work. signature.asc Description: OpenPGP digital signature
Re: How to execute user's scripts when upgrading a certain package via apt/aptitude
On 2018-03-28 18:58, Andy Smith wrote: > Hi Mikhail, > > On Wed, Mar 28, 2018 at 06:29:06PM +0200, Mikhail Morfikov wrote: >> Is there a way to pass some extra commands/script to apt/aptitude so when the >> firefox package is to be upgraded, it would recreate the links automatically? > > I've never tried it but looking at "man apt.conf" it seems that > setting Apt::Post-Invoke (or possible Apt::Post-Invoke-Success?) > might be useful to you, as you could use it to run a script that > checks that your firefox setup is as you want it. I'm aware of the options, but even if I put some script in Post-Invoke, there's still a problem concerning how to pass the information to the script that the firefox package was upgraded. Is there some variable that holds, for instance, a list of the packages that apt wants to upgrade? In such way it would be easy to set this up. But if the script doesn't know which packages are upgraded (or just the specific one), it has to be run and remove the hard links with each upgrade/installation process, and this isn't really what I want to achieve. > > Another option could be to build your own firefox package with a > post-inst script that does what you want, but given the size and > complexity of the firefox packages that is perhaps a bit ambitious. > > Then, there is always the option of creating your own firefox > executable which is a script that checks your environment, fixes it > up if necessary, and then calls the real firefox binary. I think hard links are fine, but I need some automatic way to also upgrade them when the firefox package is upgraded. > > Cheers, > Andy > signature.asc Description: OpenPGP digital signature
Re: How to execute user's scripts when upgrading a certain package via apt/aptitude
On 2018-03-28 19:29, Sven Joachim wrote: > On 2018-03-28 18:29 +0200, Mikhail Morfikov wrote: > >> I have some packages, for instance firefox, which need a little bit of >> customization from a user side. So basically when I install the new version >> of >> firefox, I also have to do some extra steps and so far I've been doing it >> manually because I don't know any better way. >> >> In the case of firefox, I have to create some hard links. Those hard links >> are >> used as additional executable files to be profiled in AppArmor. But when I >> upgrade my system, and firefox is on the package list, the hard links >> basically >> stop working and they have to be removed and recreated manually after the >> upgrade is done. >> >> Is there a way to pass some extra commands/script to apt/aptitude so when the >> firefox package is to be upgraded, it would recreate the links automatically? > > You could use a dpkg trigger for that, a short intro how to do this is > on stackoverflow[1]. See also deb-triggers(5). Is this a solution for a user or rather for maintainer of the package? I think it's the second one and hence I can't use it. > > Cheers, >Sven > > > 1. https://stackoverflow.com/questions/15276535/dpkg-how-to-use-trigger > signature.asc Description: OpenPGP digital signature
How to execute user's scripts when upgrading a certain package via apt/aptitude
I have some packages, for instance firefox, which need a little bit of customization from a user side. So basically when I install the new version of firefox, I also have to do some extra steps and so far I've been doing it manually because I don't know any better way. In the case of firefox, I have to create some hard links. Those hard links are used as additional executable files to be profiled in AppArmor. But when I upgrade my system, and firefox is on the package list, the hard links basically stop working and they have to be removed and recreated manually after the upgrade is done. Is there a way to pass some extra commands/script to apt/aptitude so when the firefox package is to be upgraded, it would recreate the links automatically? -- Morfik signature.asc Description: OpenPGP digital signature
