Re: clean Bullseye install, display disappears after "loading initial ramdisk"
On Fri, Nov 5, 2021 at 5:18 PM The Wanderer wrote: > > (Is there a reason why the line after the quote and before your new > text, in both cases where that happened, consisted of a string of 11 tab > characters instead of being empty? I had to delete the tabs manually in > order to avoid having it mess up quoting in this reply.) > > On 2021-11-05 at 19:03, Felix Miata wrote: > > > The Wanderer composed on 2021-11-05 18:25 (UTC-0400): > > > >> There's a specific kernel-command-line parameter (on top of > >> 'nomodeset') for disabling KMS with certain types of Intel > >> integrated GPU; I don't remember it off the top of my head, but I > >> believe it involves the string 'i915'. > > > > Nomodeset disables KMS for all graphics hardware. > > While I have no reason to doubt this statement, it doesn't seem to > entirely line up with what I've observed in the real world. > > I've encountered cases where specifying just 'nomodeset' didn't make the > system stop attempting to switch to a more-advanced display mode (and go > blank, losing the ability to display at all), but specifying both that > and 'i915.whateveritwas' did. > > (With exactly the same live-boot image, on different hardware, > specifying just 'nomodeset' worked just fine. So it wasn't something odd > about the boot environment, or at least not exclusively so.) > > >> Disabling kernel modesetting isn't the greatest thing for long-term > >> use, but if it can let you boot, you may be able to use that as a > >> basis for figuring out what other solutions may be possible. > > > > Nomodeset is primarily intended to be a troubleshooting parameter. > > KMS, which nomodeset disables, is an absolute requirement for > > competent graphics performance from al FOSS drivers supporting AMD, > > Intel and NVidia GPUs, among others. > > I figured it'd be something like that, but didn't have the > (sufficiently-recent) direct experience to be able to say for sure. > > -- >The Wanderer > > The reasonable man adapts himself to the world; the unreasonable one > persists in trying to adapt the world to himself. Therefore all > progress depends on the unreasonable man. -- George Bernard Shaw Thank you. I'd completely forgotten about "nomodeset" although I've had occasion to use it before. Did the job!
Re: unkown root password and mkdir problem.
Thanks, this fixed my problem and as Greg recommended I have reset mkdir ownership and options On 11/5/21 7:35 PM, Jeremy Ardley wrote: On 6/11/21 7:17 am, Thomas George wrote: when installing debian I entered eight digits as the root password. The instillation completed successfully. Later I tried to become root but the eight digits didn't work and many permutations also didn't work. I have used sudo successfully with many commands including mkdir but sudo tar fails to uncompress files because it cannot make the necessary directories. That is sudo tar runs but must use mkdir which fails. I have found mkdir in /usr/bin and changed the ownership to root:tom and given it rwx permissions but this does not solve the problem. If there are no suggested solutions to this email tomorrow I will backup all my files to external drive and reinstall bullseye Try sudo passwd root And reset the root password to a known string
No DNS in Fedora Podman image on Debian 11
So I'm trying to use a fedora Podman image on my Debian 11 machine but for some reason DNS lookups do not seem to be working in the container environment. Specifically: $ podman run --rm -it fedora:latest # dnf install gzip [...] Fedora 35 - x86_640.0 B/s | 0 B 00:00 Errors during downloading metadata for repository 'fedora': - Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=fedora-35=x86_64 [getaddrinfo() thread failed to start] * I have the same issue on two Debian 11 systems (one of which is not administered by me). * The container can retrieve web pages with curl if I type in the IP address. So that confirms it's just the DNS that does not work. * debian:testing containers have no network or DNS issue. So it's just fedora:latest that's broken. * But I also have no issue with fedora:latest if I run it inside a Fedora 35 VM (Libvirt+QEmu specifically). * So it's the combination of a Debian 11 host + a Fedora container that's broken. * For good measure I tested with an "iptables -I (IN|OUT)PUT -j ACCEPT" on the host and it makes no difference. * In the guest /etc/resolv.conf has the domain line and "nameserver 10.0.2.3". * I see mentions of systemd-resolved on the Internet but I see no trace of systemd in the Fedora container. I don't know how to specifically test whever DNS lookups go through systemd-resolved though. Does anyone know what's up? Can anyone reproduce this issue? -- Francois Gouget http://fgouget.free.fr/ Un western sans indien c'est comme une police sans serif. -- John Wayne
Re: unkown root password and mkdir problem.
On Sat, Nov 06, 2021 at 07:35:22AM +0800, Jeremy Ardley wrote: > On 6/11/21 7:17 am, Thomas George wrote: > > I have found mkdir in /usr/bin and changed the ownership to root:tom and > > given it rwx permissions but this does not solve the problem. > Try > > sudo passwd root > > And reset the root password to a known string And after you do that, change the ownership and permissions of /usr/bin/mkdir back to what they are supposed to be: -rwxr-xr-x 1 root root 85184 Sep 24 2020 mkdir If that wasn't what they were originally, then your system is severely broken, and all bets are off.
Re: Is "Debian desktop environment" identical to "GNOME" upon installation?
Brian writes: On Fri 05 Nov 2021 at 17:02:01 +, Andrew M.A. Cater wrote: > On Fri, Nov 05, 2021 at 04:04:17PM +, Brian wrote: > > On Fri 05 Nov 2021 at 13:43:29 +, Tixy wrote: > > > > > On Fri, 2021-11-05 at 07:47 -0500, Nicholas Geovanis wrote: > > > > On Fri, Nov 5, 2021, 7:21 AM Greg Wooledge wrote: [...] > > > > > With the "Live" installers, the default is different. > > > > > > > > And if I may ask: Why is it different? If there is a reason or two. > > > > > > Guessing here... because a live version already has a desktop > > > environment on the disk, so it make sense to default to installing that > > > one. E.g. if you choose, say, the XFCE live iso, it would default to > > > XFCE not Gnome. Would be a bit perverse otherwise. AFAICT it does not only "default" to the DE contained within the live system but rather does not even show the choice screen because it installs by copying/extracting the live system's data and hence, the DE (and other software choices) are already set. See below. > > I rather thought the Live images contained a copy of d-i but am not > > going to download an ISO to refresh my menory. I will offer > > > > https://live-team.pages.debian.net/live-manual/html/live- > > manual/customizing-installer.en.html > > > > I'd see it as a bit unusual for this copy to differ from the regular d-i. > A few things: [...] > 3. The live CDs are designed so that you download the one with the desktop > you want. The "standard" one installs a minimum Debian with standard > packages and no gui. OK, but the relevance to the OP's issue is obscure. Does it need to taken into account for the issue raised? TL;DR: Live Installers do not present the DE selection screen hence it should not relate to the OP. > 4. Live CD install is not guaranteed to be the same as the traditional > Debian installer. Calamares is very significantly different. Live CD/DVD is > maintained by a different libe CD team and not by the Debian media team. Ah! Calamares. It alters the way tasksel behaves in d-i? Heaven help us! Is that is what is meant when it is claimed by Greg Wooledg: With the "Live" installers, the default is different"? Calamares introduces a new ball game? [...] Let me try to clarify this a little bit from my experience as an "advanced" user :) Calamares is an entirely separate installer that can be invoked from within a running (live) system. It is _one_ way to install Debian from a live system but it is not the only one. It is worth stressing that there is _no_ interaction between Calamares and d-i and that they prsent different screens. Behind the scenes, Calamares invokes an `rsync` to copy the data from within the live system to the target. For a typical session in Calamares, see [1] for an example from Debian Buster. Now d-i is separate in that it does not run from within the live system but has to be invoked _instead_ of the respective live system from the boot menu. It is, however, contained on the same ISO image/DVD together with the live system's data. The d-i variant used on live systems does not ask for the choice of DE because its software selection cannot be customized like in the regular d-i. Instead, it simply copies the data from the live file system to the targed drive (? I am not exactly sure on this one ?). See [2] for an example from Debian Buster and note the absence of the tasksel screen. Now the regular d-i shows the tasksel screen and asks for which DE to install. See [3] for an example from the Debian Bullseye Alpha 3 installer. Here are some "real screenshots" :) [1] https://masysma.lima-city.de/37/debian_i386_installation_reports_att/m2-dl1080-i386-lxde-calamares.xhtml [2] https://masysma.lima-city.de/37/debian_i386_installation_reports_att/m2-dl1080-i386-lxde-di.xhtml [3] https://masysma.lima-city.de/37/debian_i386_installation_reports_att/m6-d11a3-i386-netinst.xhtml HTH Linux-Fan öö pgpK1tyhC5AEL.pgp Description: PGP signature
Re: unkown root password and mkdir problem.
On 6/11/21 7:17 am, Thomas George wrote: when installing debian I entered eight digits as the root password. The instillation completed successfully. Later I tried to become root but the eight digits didn't work and many permutations also didn't work. I have used sudo successfully with many commands including mkdir but sudo tar fails to uncompress files because it cannot make the necessary directories. That is sudo tar runs but must use mkdir which fails. I have found mkdir in /usr/bin and changed the ownership to root:tom and given it rwx permissions but this does not solve the problem. If there are no suggested solutions to this email tomorrow I will backup all my files to external drive and reinstall bullseye Try sudo passwd root And reset the root password to a known string -- Jeremy OpenPGP_signature Description: OpenPGP digital signature
unkown root password and mkdir problem.
when installing debian I entered eight digits as the root password. The instillation completed successfully. Later I tried to become root but the eight digits didn't work and many permutations also didn't work. I have used sudo successfully with many commands including mkdir but sudo tar fails to uncompress files because it cannot make the necessary directories. That is sudo tar runs but must use mkdir which fails. I have found mkdir in /usr/bin and changed the ownership to root:tom and given it rwx permissions but this does not solve the problem. If there are no suggested solutions to this email tomorrow I will backup all my files to external drive and reinstall bullseye
Re: clean Bullseye install, display disappears after "loading initial ramdisk"
(Is there a reason why the line after the quote and before your new text, in both cases where that happened, consisted of a string of 11 tab characters instead of being empty? I had to delete the tabs manually in order to avoid having it mess up quoting in this reply.) On 2021-11-05 at 19:03, Felix Miata wrote: > The Wanderer composed on 2021-11-05 18:25 (UTC-0400): > >> There's a specific kernel-command-line parameter (on top of >> 'nomodeset') for disabling KMS with certain types of Intel >> integrated GPU; I don't remember it off the top of my head, but I >> believe it involves the string 'i915'. > > Nomodeset disables KMS for all graphics hardware. While I have no reason to doubt this statement, it doesn't seem to entirely line up with what I've observed in the real world. I've encountered cases where specifying just 'nomodeset' didn't make the system stop attempting to switch to a more-advanced display mode (and go blank, losing the ability to display at all), but specifying both that and 'i915.whateveritwas' did. (With exactly the same live-boot image, on different hardware, specifying just 'nomodeset' worked just fine. So it wasn't something odd about the boot environment, or at least not exclusively so.) >> Disabling kernel modesetting isn't the greatest thing for long-term >> use, but if it can let you boot, you may be able to use that as a >> basis for figuring out what other solutions may be possible. > > Nomodeset is primarily intended to be a troubleshooting parameter. > KMS, which nomodeset disables, is an absolute requirement for > competent graphics performance from al FOSS drivers supporting AMD, > Intel and NVidia GPUs, among others. I figured it'd be something like that, but didn't have the (sufficiently-recent) direct experience to be able to say for sure. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: clean Bullseye install, display disappears after "loading initial ramdisk"
The Wanderer composed on 2021-11-05 18:25 (UTC-0400): > There's a specific kernel-command-line parameter (on top of 'nomodeset') > for disabling KMS with certain types of Intel integrated GPU; I don't > remember it off the top of my head, but I believe it involves the string > 'i915'. Nomodeset disables KMS for all graphics hardware. The moniker i915 for the kernel's Intel support module is derived from a specific Intel graphics version from around 17 or so years ago. So, e.g. i915.modeset=0 limits disabling of KMS to Intel IGPs, like amdgpu.modeset=0 disables only for AMD GPUs, and nouveau.modeset=0 disables KMS only for NVidia GPUs. KMS either is or isn't enabled. There's no in between. Disabling makes X performance dismal, except when using non-FOSS drivers that don't depend on KMS. > Disabling kernel modesetting isn't the greatest thing for long-term use, > but if it can let you boot, you may be able to use that as a basis for > figuring out what other solutions may be possible. Nomodeset is primarily intended to be a troubleshooting parameter. KMS, which nomodeset disables, is an absolute requirement for competent graphics performance from al FOSS drivers supporting AMD, Intel and NVidia GPUs, among others. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
Re: clean Bullseye install, display disappears after "loading initial ramdisk"
On 2021-11-05 at 18:14, Mark Copper wrote: > Where to start diagnosing a problem like this? At first blush: look into ways to disable kernel modesetting. The details tend to vary depending on the GPU involved, but one thing they usually have in common is adding 'nomodeset' to the kernel command line. I think I usually see the changeover to KMS happening later than the point right after "loading initial ramdisk", but there's no guarantee that that will always be the case, and the symptom seems right. > Minimal install -- no desktop. > > No "oops" in syslog though there are some warnings. > > System seems to shut down properly when power button pressed. > Yesterday I could even ssh in, but that facility disappeared. Shut down immediately (hard-power-off style, much like you get when pressing that button during POST), or initiate shutdown and complete after the normal amount of shutdown time (as you get when initiating a shutdown command from the software UI within the booted OS)? The answer should help us tell how far it had managed to boot before the power-button press happened. > Asrock H570M-ITX/ac with Intel i3-10100. More info gladly provided. There's a specific kernel-command-line parameter (on top of 'nomodeset') for disabling KMS with certain types of Intel integrated GPU; I don't remember it off the top of my head, but I believe it involves the string 'i915'. If you're using such a GPU, it might be worth looking into that. Disabling kernel modesetting isn't the greatest thing for long-term use, but if it can let you boot, you may be able to use that as a basis for figuring out what other solutions may be possible. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
clean Bullseye install, display disappears after "loading initial ramdisk"
Where to start diagnosing a problem like this? Minimal install -- no desktop. No "oops" in syslog though there are some warnings. System seems to shut down properly when power button pressed. Yesterday I could even ssh in, but that facility disappeared. Asrock H570M-ITX/ac with Intel i3-10100. More info gladly provided. Thanks for reading.
Re: [Sid] Firefox problem
On 10/19/21 16:21, Grzesiek wrote: On 10/18/21 5:35 PM, Celejar wrote: On Sun, 17 Oct 2021 10:55:45 +0200 Grzesiek wrote: Hi there, On some of machines I use, after opening of Firefox I get empty browser window (with menus, decorations etc) but nothing else is displayed. Its impossible to open menu, type address, etc. The only thing you can do is to close the window. After changing display configuration (rotate to portrait, adding external monitor..) it starts to work as expected. You do not even need to reopen. Moreover, it looks that Firefox was running ok all the time but nothing was displayed. After recent updates on some machines I get the same problem using firefox-esr. The only error mesg I get is: ###!!! [Parent][RunMessage] Error: Channel closing: too late to send/recv, messages will be lost I don't know what that message means, but I frequently get a similar message from Firefox, despite the fact that the program is (mostly) functional. ###!!! [Child][RunMessage] Error: Channel closing: too late to send/recv, messages will be lost So the message is not related to the problem After some more tests I discovered that the problem occurs on all my machines using integrated GPU and intel_drv.so driver (i5-2520M, i5-2450M, i7-2600, i5-8250U). The workaround is to switch to modesetting_drv.so or rotate to portrait. After that Firefox starts to work as expected. On builds based on discrete GPU (in my case Nvidia GTX) Firefox works ok. Any ideas? Could you confirm? Regards Greg
Re: Clé USB Wifi détectée mais pas par Wicd
Le jeudi 4 novembre 2021 à 23:50:03 UTC+1, ajh-valmer a écrit : > Super merci ! Elle à l'air très bien, > sauf que je la trouve un peu chère :-) > > Je vois celle-ci (prix plus modeste) : > TP-Link TL-WN781ND Adaptateur PCI Express Wi-Fi N 150 Mbps > (bien compatible Linux). > > Le slot PCI Express est déjà pris par la carte Vidéo. > La carte fonctionnera t-elle sur l'autre slot PCI ? > > 150Mps de débit est-il suffisant si on a la fibre ? > > Merci, bonne nuit, > > A. Valmer - compatibilité: ça fait longtemps que je n'ai plus bidouillé d'ordinateur de bureau mais seulement des portables, mais il ne me semble pas que tu puisses installer une carte PCIe dans un slot PCI. Même si ça allait en terme de branchement matériel (et je ne crois pas), le PCI c'est très vieux, donc je suppose que le débit ne doit probablement pas être adapté (un peu comme si tu utilisais de l'USB1 pour du wifi) - débit wifi: ça dépend de tes envies/besoins, de ta carte wifi et de ton point d'accès wifi. Vraiment à la louche je dirais que souvent chez moi en zone urbaine chargée en trafic wifi, le débit wifi réel est 3 fois moindre que le débit théorique . Le débit théorique fibre dépend de ton fournisseur et de la téchnologie de raccordement. En tout cas à chaque saut de génération technologique wifi j'ai noté une amélioration appréciable (wifi 802.11G à 54Mb/s, 802.11N à 150Mb/s, 802.11AC à 1200Mb/s (débits théoriques optimaux)). Dans mon cas le 802.11AC en wifi a été comme la 4G en réseau mobile: pour la première fois je ne me sentais pas bridé par le média de transmission (avec la 3G mobile je regrettais de ne pas toujours pouvoir être en wifi, avec le wifi 802.11N je regrettais de ne pas pouvoir toujours être en ethernet) La carte que j'ai est effectivement chère à 50€ (je trouve) mais l'avantage que j'y ai trouvé c'est qu'à l'époque c'était l'une des seules dont je sois sûr qu'elle fonctionne sous linux (j'avais galéré, je ne crois pas que je connaissais la base de données hardware citée plus haut), qu'elle soit dispo sans la commander au bout du monde, et qu'elle soit 802.11AC.
Re: Is "Debian desktop environment" identical to "GNOME" upon installation?
On Fri 05 Nov 2021 at 17:02:01 +, Andrew M.A. Cater wrote: > On Fri, Nov 05, 2021 at 04:04:17PM +, Brian wrote: > > On Fri 05 Nov 2021 at 13:43:29 +, Tixy wrote: > > > > > On Fri, 2021-11-05 at 07:47 -0500, Nicholas Geovanis wrote: > > > > On Fri, Nov 5, 2021, 7:21 AM Greg Wooledge wrote: > > > > > > > > > > Is "Debian desktop environment" identical to "GNOME" upon > > > > > > installation? > > > > > > > > > > > > > > > > > > > > Right now, for the regular official installers (and also for the > > > > > unofficial installer with non-free firmware), that default task > > > > > happens > > > > > to be GNOME. > > > > > > > > > > With the "Live" installers, the default is different. > > > > > > > > > > > > > And if I may ask: Why is it different? If there is a reason or two. > > > > > > Guessing here... because a live version already has a desktop > > > environment on the disk, so it make sense to default to installing that > > > one. E.g. if you choose, say, the XFCE live iso, it would default to > > > XFCE not Gnome. Would be a bit perverse otherwise. > > > > I rather thought the Live images contained a copy of d-i but am not > > going to download an ISO to refresh my menory. I will offer > > > > > > https://live-team.pages.debian.net/live-manual/html/live-manual/customizing-installer.en.html > > > > I'd see it as a bit unusual for this copy to differ from the regular d-i. > > > > A few things: > > 1. GNOME is only the default on AMD64 / i386 - on some of the ARM variants, > it's still XFCE, I think. Fine, but this is not, IMHO, the OP's concern. He is using amd64/i386. Nevertheless, it is something to be aware of. > 2. XFCE _was_ the default for a one CD install until Buster - it's now > too big for one CD so there is no longer a CD which will install as > single desktop by default. Correct, but I do not think we are into CD vs DVD in the OP's issue. This is something to discard from our thinking. > 3. The live CDs are designed so that you download the one with the desktop > you want. The "standard" one installs a minimum Debian with standard packages > and no gui. OK, but the relevance to the OP's issue is obscure. Does it need to taken into account for the issue raised? > 4. Live CD install is not guaranteed to be the same as the traditional > Debian installer. Calamares is very significantly different. Live CD/DVD is > maintained by a different libe CD team and not by the Debian media team. Ah! Calamares. It alters the way tasksel behaves in d-i? Heaven help us! Is that is what is meant when it is claimed by Greg Wooledg: With the "Live" installers, the default is different"? Calamares introduces a new ball game? Alejandro Colomar's observations are quite clear and reprducible. It would be expected he would be along later to expand on them. -- Brian.
Re: Is "Debian desktop environment" identical to "GNOME" upon installation?
On Fri 05 Nov 2021 at 07:43:22 (-0700), Peter Ehlert wrote: > On 11/5/21 4:50 AM, Alejandro Colomar (man-pages) wrote: > > > > I did some test by installing 2 identical virtualbox instances > > (EFI turned on) with the same netinst image > > . > > > > I typically use XFCE, so I wanted to test if leaving "Debian > > desktop environment" marked would affect or not my XFCE > > installation. > > > > It does. > > > > a) > > | [ ] Debian desktop environment > > | [*] XFCE > > > > b) > > | [*] Debian desktop environment > > | [*] XFCE > > > > Using (b), I end up with 12 more installed packages. I checked > > that there weren't any available upgrades after installing both > > (apt-get update && apt-get upgrade showed 0). > > > > The offending list is: > > > > hv3 [ and its dependencies ] > > > > Maybe there's a bug somewhere in tasksel? > > I consider it Faulty Design. > > there is no "Debian desktop environment"... from my superficial > testing it is kinda "Gnome Lite" > (and in My Opinion gnome desktop is rather hateful). > > Being selected by default is a Huge design flaw. > > a simple "select a desktop environment" text message with something > like "without a desktop you only get a terminal" as a suggestion for > the uninformed would be far superior. This particular horse was flogged a year ago. Top of thread: https://lists.debian.org/debian-user/2020/09/msg00238.html It's not something I take great interest in as I don't use a DE. > BTW: I only use net-install because I don't want all that cruft. I wasn't aware that the netinst d-i distinguished itself by not installing "cruft". AIUI, whether you install a DE depends on your replies on this screen: │ Choose software to install: │ │ │ │ [*] Debian desktop environment │ │ [*] ... GNOME │ │ [ ] ... Xfce│ │ [ ] ... GNOME Flashback │ │ [ ] ... KDE Plasma │ │ [ ] ... Cinnamon│ │ [ ] ... MATE│ │ [ ] ... LXDE│ │ [ ] ... LXQt│ │ [ ] web server │ │ [ ] SSH server │ │ [*] standard system utilities │ I've installed non-DE and non-DE, non-X systems from DVDs in the past, and one DE installation from a netinst. > PS: hunting down all swap partitions on very drive and setting them to > Format by default is also a real pain in the tush. I've no idea what is meant by this, nor its relevance to the Subject. I'd mention in passing that I installed bullseye on a 512MB laptop without configuring any swap space, as always. I leave that until the system is up and running. Cheers, David.
Re: Trying to setup obexd but Operation not permitted
Thomas Schmitt wrote:
> Can it be that obexd is allergic to symbolic links ?
>
>
https://discussion.fedoraproject.org/t/cannot-receive-file-over-bluetooth/1813/3
> points to
>
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/obexd/plugins/filesystem.c#n95
> which spews -EPERM if not obex_option_symlinks() is true.
>
> Above discussion raises the question whether option --symlinks with
> manually started obexd does help ?
>
> It is remarkably difficult to find documentation about obexd's options.
> My best catch is source code like:
>
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/obexd/src/main.c#n141
>
> { "symlinks", 'l', [...]
> "Allow symlinks leading outside of the root "
> "folder" },
Yes with this option it is working. I still wonder why this is necessary and
yes it is hard to find documentation.
thanks for the hint
regards
--
FCD6 3719 0FFB F1BF 38EA 4727 5348 5F1F DCFE BCB0
Re: Is "Debian desktop environment" identical to "GNOME" upon installation?
On Fri 05 Nov 2021 at 16:44:04 +, Brian wrote: > On Fri 05 Nov 2021 at 16:28:36 +, Jonathan Dowland wrote: > > > On Fri, Nov 05, 2021 at 12:50:23PM +0100, Alejandro Colomar (man-pages) > > wrote: > > > hv3 > > > > This is a web browser written in TCL/tK. What I suspect is happening is > > it's being pulled in to satisfy a dependency on "www-browser" virtual > > package by one of the desktop metapackages. > > Interesting that hv3 hasn't any Reverse Depends: and that 'apt install > task-desktop task-xfce-desktop' does not propose it for installation'. I forgot firefox-esr is installed. This satisfies the www-browser package dependency. Hence apt install task-desktop task-xfce-desktop apt install task-xfce-desktop show the same number of packages to be installed. Purging the browser gives the twelve package differnece obtianed by Alejandro Colomar. Now it gets more interesting. task-xfce-desktop depends on task-desktop and the later recommends firefox | firefox-esr. The first command above proposes to install firefox-esr. Why propose hv3 too? -- Brian.
Re: Trying to setup obexd but Operation not permitted
Greg Wooledge wrote: > In the absence of a useful error message, you could either source-dive > into obexd and try to figure out what it's actually doing... or you could > *guess* (as I am currently guessing) that it's complaining about > too-loose permissions, and then look at all the permissions of all the > subdirectories along the /home-lisa/user/Downloads path, and see if one > of them is group-writable or world-writable. If so, fix it, and see if > that makes the problem go away. IMO it is obviously the link, because obexd can write to /data/local/Downloads but not to the link to this directory, which is /data/local/Downloads.test I will have a look into the code over the weekend. thanks and BR -- FCD6 3719 0FFB F1BF 38EA 4727 5348 5F1F DCFE BCB0
Re: Trying to setup obexd but Operation not permitted
Hi,
deloptes wrote:
> lstat("/home", {st_mode=S_IFLNK|0777, st_size=10, ...}) = 0
> readlink("/home", "home-lisa/", 4095) = 10
Can it be that obexd is allergic to symbolic links ?
https://discussion.fedoraproject.org/t/cannot-receive-file-over-bluetooth/1813/3
points to
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/obexd/plugins/filesystem.c#n95
which spews -EPERM if not obex_option_symlinks() is true.
Above discussion raises the question whether option --symlinks with
manually started obexd does help ?
It is remarkably difficult to find documentation about obexd's options.
My best catch is source code like:
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/obexd/src/main.c#n141
{ "symlinks", 'l', [...]
"Allow symlinks leading outside of the root "
"folder" },
Have a nice day :)
Thomas
Re: Trying to setup obexd but Operation not permitted
Greg Wooledge wrote: > WHAT application? And how is THAT creature spawned? Sorry for confusion. For testing I run it on the command line, but it is meant to be spawned from one BT manager application. It is spawned as process the same way I start it in the command line. -- FCD6 3719 0FFB F1BF 38EA 4727 5348 5F1F DCFE BCB0
Re: Trying to setup obexd but Operation not permitted
On Fri, Nov 05, 2021 at 06:24:38PM +0100, deloptes wrote:
> I now used strace
> writev(2, [{iov_base="obexd[23074]: PUT(0x2), {iov_base="\n", iov_len=1}], 2) = 40
> sendto(3, "<31>Nov 5 18:04:33 obexd[23074]"..., 59, MSG_NOSIGNAL, NULL, 0)
> = 59
> openat(AT_FDCWD, "/home/user/Downloads/20211105_090338.jpg", O_WRONLY
> O_CREAT|O_TRUNC, 0600) = 8
So... the open actually *worked*.
> fstat(8, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
> lstat("/home", {st_mode=S_IFLNK|0777, st_size=10, ...}) = 0
> readlink("/home", "home-lisa/", 4095) = 10
> lstat("/home-lisa", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> lstat("/home-lisa/user", {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0
> lstat("/home-lisa/user/Downloads", {st_mode=S_IFDIR|0700,
> st_size=4096, ...}) = 0
> lstat("/home-lisa/user/Downloads/20211105_090338.jpg", {st_mode=S_IFREG
> 0600, st_size=0, ...}) = 0
> close(8)= 0
> getpid()= 23074
> writev(2, [{iov_base="obexd[23074]: open(/home/user"..., iov_len=92},
> {iov_base="\n", iov_len=1}], 2) = 93
> sendto(3, "<27>Nov 5 18:04:33 obexd[23074]"..., 112, MSG_NOSIGNAL, NULL, 0)
> = 112
> getpid()= 23074
> writev(2, [{iov_base="obexd[23074]: PUT(0x2), Forbidde"..., iov_len=39},
> {iov_base="\n", iov_len=1}], 2) = 40
But then obexd claimed the open *failed*.
> so you see it resolves the link, but then fails with Forbidden.
If obexd doesn't like the path that you've given it, due to too-loose
permissions or whatever, it ought to give a clearer message to indicate
this.
In the absence of a useful error message, you could either source-dive
into obexd and try to figure out what it's actually doing... or you could
*guess* (as I am currently guessing) that it's complaining about
too-loose permissions, and then look at all the permissions of all the
subdirectories along the /home-lisa/user/Downloads path, and see if one
of them is group-writable or world-writable. If so, fix it, and see if
that makes the problem go away.
Re: Trying to setup obexd but Operation not permitted
David Wright wrote:
> Because both tests are run by hand, that does make it easier to strace
> what's going on in more detail than the debug output. For example, the
> open's flags are listed.
I forgot to mention that home is actually a link to home-lisa which is the
mount point for the NFS share.
I now used strace
writev(2, [{iov_base="obexd[23074]: PUT(0x2), Nov 5 18:04:33 obexd[23074]"..., 59, MSG_NOSIGNAL, NULL, 0)
= 59
openat(AT_FDCWD, "/home/user/Downloads/20211105_090338.jpg", O_WRONLY
O_CREAT|O_TRUNC, 0600) = 8
fstat(8, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
lstat("/home", {st_mode=S_IFLNK|0777, st_size=10, ...}) = 0
readlink("/home", "home-lisa/", 4095) = 10
lstat("/home-lisa", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/home-lisa/user", {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0
lstat("/home-lisa/user/Downloads", {st_mode=S_IFDIR|0700,
st_size=4096, ...}) = 0
lstat("/home-lisa/user/Downloads/20211105_090338.jpg", {st_mode=S_IFREG
0600, st_size=0, ...}) = 0
close(8)= 0
getpid()= 23074
writev(2, [{iov_base="obexd[23074]: open(/home/user"..., iov_len=92},
{iov_base="\n", iov_len=1}], 2) = 93
sendto(3, "<27>Nov 5 18:04:33 obexd[23074]"..., 112, MSG_NOSIGNAL, NULL, 0)
= 112
getpid()= 23074
writev(2, [{iov_base="obexd[23074]: PUT(0x2), Forbidde"..., iov_len=39},
{iov_base="\n", iov_len=1}], 2) = 40
so you see it resolves the link, but then fails with Forbidden.
Now I conducted the same test after createing a symlink to the local
directory (thus exclude NFS as root for the problem)
The result is the same
sendto(3, "<31>Nov 5 18:22:28 obexd[23364]"..., 59, MSG_NOSIGNAL, NULL, 0)
= 59
openat(AT_FDCWD, "/data/local/Downloads.test/20211105_090338.jpg", O_WRONLY
O_CREAT|O_TRUNC, 0600) = 8
fstat(8, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
lstat("/data", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/data/local", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/data/local/Downloads.test", {st_mode=S_IFLNK|0777, st_size=10, ...})
= 0
readlink("/data/local/Downloads.test", "Downloads/", 4095) = 10
lstat("/data/local/Downloads", {st_mode=S_IFDIR|0700, st_size=4096, ...}) =
0
lstat("/data/local/Downloads/20211105_090338.jpg", {st_mode=S_IFREG|0600,
st_size=0, ...}) = 0
close(8)= 0
getpid()= 23364
writev(2, [{iov_base="obexd[23364]: open(/data/local/D"..., iov_len=95},
{iov_base="\n", iov_len=1}], 2) = 96
sendto(3, "<27>Nov 5 18:22:28 obexd[23364]"..., 115, MSG_NOSIGNAL, NULL, 0)
= 115
getpid()= 23364
writev(2, [{iov_base="obexd[23364]: PUT(0x2), Forbidde"..., iov_len=39},
{iov_base="\n", iov_len=1}], 2) = 40
sendto(3, "<31>Nov 5 18:22:28 obexd[23364]"..., 59, MSG_NOSIGNAL, NULL, 0)
= 59
Conclusion: the problem is related to the directory link in the path and to
me it looks like a problem in obexd
How do you see this?
--
FCD6 3719 0FFB F1BF 38EA 4727 5348 5F1F DCFE BCB0
Re: Trying to setup obexd but Operation not permitted
On Fri, Nov 05, 2021 at 06:00:43PM +0100, deloptes wrote: > Greg Wooledge wrote: > > > So, never mind. Continue whatever other investigations you have lined > > up. > > Ah yes, obexd is meant to be run at user level. In my case it is started by > a master application, but anyway thank you for the effort. WHAT application? And how is THAT creature spawned?
Re: Is "Debian desktop environment" identical to "GNOME" upon installation?
On Fri, Nov 05, 2021 at 04:04:17PM +, Brian wrote: > On Fri 05 Nov 2021 at 13:43:29 +, Tixy wrote: > > > On Fri, 2021-11-05 at 07:47 -0500, Nicholas Geovanis wrote: > > > On Fri, Nov 5, 2021, 7:21 AM Greg Wooledge wrote: > > > > > > > > Is "Debian desktop environment" identical to "GNOME" upon > > > > > installation? > > > > > > > > > > > > > > > > Right now, for the regular official installers (and also for the > > > > unofficial installer with non-free firmware), that default task happens > > > > to be GNOME. > > > > > > > > With the "Live" installers, the default is different. > > > > > > > > > > And if I may ask: Why is it different? If there is a reason or two. > > > > Guessing here... because a live version already has a desktop > > environment on the disk, so it make sense to default to installing that > > one. E.g. if you choose, say, the XFCE live iso, it would default to > > XFCE not Gnome. Would be a bit perverse otherwise. > > I rather thought the Live images contained a copy of d-i but am not > going to download an ISO to refresh my menory. I will offer > > > https://live-team.pages.debian.net/live-manual/html/live-manual/customizing-installer.en.html > > I'd see it as a bit unusual for this copy to differ from the regular d-i. > A few things: 1. GNOME is only the default on AMD64 / i386 - on some of the ARM variants, it's still XFCE, I think. 2. XFCE _was_ the default for a one CD install until Buster - it's now too big for one CD so there is no longer a CD which will install as single desktop by default. 3. The live CDs are designed so that you download the one with the desktop you want. The "standard" one installs a minimum Debian with standard packages and no gui. 4. Live CD install is not guaranteed to be the same as the traditional Debian installer. Calamares is very significantly different. Live CD/DVD is maintained by a different libe CD team and not by the Debian media team. All the very best, as ever, Andy Cater > -- > Brian. >
Re: Trying to setup obexd but Operation not permitted
Greg Wooledge wrote: > So, never mind. Continue whatever other investigations you have lined > up. Ah yes, obexd is meant to be run at user level. In my case it is started by a master application, but anyway thank you for the effort. -- FCD6 3719 0FFB F1BF 38EA 4727 5348 5F1F DCFE BCB0
Re: Is "Debian desktop environment" identical to "GNOME" upon installation?
On Fri 05 Nov 2021 at 16:28:36 +, Jonathan Dowland wrote: > On Fri, Nov 05, 2021 at 12:50:23PM +0100, Alejandro Colomar (man-pages) wrote: > > hv3 > > This is a web browser written in TCL/tK. What I suspect is happening is > it's being pulled in to satisfy a dependency on "www-browser" virtual > package by one of the desktop metapackages. Interesting that hv3 hasn't any Reverse Depends: and that 'apt install task-desktop task-xfce-desktop' does not propose it for installation'. -- Brian.
Re: Is "Debian desktop environment" identical to "GNOME" upon installation?
On Fri, Nov 05, 2021 at 12:50:23PM +0100, Alejandro Colomar (man-pages) wrote: hv3 This is a web browser written in TCL/tK. What I suspect is happening is it's being pulled in to satisfy a dependency on "www-browser" virtual package by one of the desktop metapackages. libsqlite3-tcl libtcl8.6 libtk-img libtk8.6 tcl tcl-tls tcl8.6 tcllib tk tk-html3 tk8.6 These are all dependencies from hv3. -- Please do not CC me for listmail. Jonathan Dowland ✎j...@debian.org https://jmtd.net
Re: mobilt 4g bredband
Mattias: > funkar sånt i buster? ... Borde, men det beror på vilken krets du har. Här är exempel på vad man kan få upp om man söker: https://www.thinkpenguin.com/gnu-linux/usb-4g-lte-advanced-modem-gnulinux-tpe-usb4glte https://www.hackster.io/munoz0raul/how-to-use-gsm-3g-4g-in-embedded-linux-systems-9047cf https://www.toradex.com/blog/how-to-use-gsm-3g-4g-in-embedded-linux-systems https://www.linuxquestions.org/questions/linux-networking-3/what-to-use-for-lte-4g-linux-4175546335/ Hälsningar, /Karl Hammar
Re: Trying to setup obexd but Operation not permitted
On Fri 05 Nov 2021 at 11:55:19 (-0400), Greg Wooledge wrote: > On Fri, Nov 05, 2021 at 10:59:46AM -0400, Greg Wooledge wrote: > > On Fri, Nov 05, 2021 at 02:46:18PM +0100, deloptes wrote: > > > Greg Wooledge wrote: > > > > > > > Check whether the systemd unit file is restricting network access for > > > > the service/process. > > > > > > ??? How do I do this - a hint would be helpful. > > > > Start by figuring out the name of the service. > > > > Then try "systemctl cat servicename > somefile". This should produce > > output that represents the entire unit file, possibly concatenating > > multiple real files together, > > > > Once you have that, you can look it over and see if anything pops out > > at you. If not, then you can try digging through the documentation > > for each line, to see what it does. > > Gaaah. I just went back and found your original message. You said > you're starting this daemon *by hand*, not through a systemd unit. > > So, never mind. Continue whatever other investigations you have lined > up. Because both tests are run by hand, that does make it easier to strace what's going on in more detail than the debug output. For example, the open's flags are listed. Cheers, David.
Re: Is "Debian desktop environment" identical to "GNOME" upon installation?
On Fri 05 Nov 2021 at 13:43:29 +, Tixy wrote: > On Fri, 2021-11-05 at 07:47 -0500, Nicholas Geovanis wrote: > > On Fri, Nov 5, 2021, 7:21 AM Greg Wooledge wrote: > > > > > > Is "Debian desktop environment" identical to "GNOME" upon installation? > > > > > > > > > > > > Right now, for the regular official installers (and also for the > > > unofficial installer with non-free firmware), that default task happens > > > to be GNOME. > > > > > > With the "Live" installers, the default is different. > > > > > > > And if I may ask: Why is it different? If there is a reason or two. > > Guessing here... because a live version already has a desktop > environment on the disk, so it make sense to default to installing that > one. E.g. if you choose, say, the XFCE live iso, it would default to > XFCE not Gnome. Would be a bit perverse otherwise. I rather thought the Live images contained a copy of d-i but am not going to download an ISO to refresh my menory. I will offer https://live-team.pages.debian.net/live-manual/html/live-manual/customizing-installer.en.html I'd see it as a bit unusual for this copy to differ from the regular d-i. -- Brian.
Re: Trying to setup obexd but Operation not permitted
On Fri, Nov 05, 2021 at 10:59:46AM -0400, Greg Wooledge wrote: > On Fri, Nov 05, 2021 at 02:46:18PM +0100, deloptes wrote: > > Greg Wooledge wrote: > > > > > Check whether the systemd unit file is restricting network access for > > > the service/process. > > > > ??? How do I do this - a hint would be helpful. > > Start by figuring out the name of the service. > > Then try "systemctl cat servicename > somefile". This should produce > output that represents the entire unit file, possibly concatenating > multiple real files together, > > Once you have that, you can look it over and see if anything pops out > at you. If not, then you can try digging through the documentation > for each line, to see what it does. Gaaah. I just went back and found your original message. You said you're starting this daemon *by hand*, not through a systemd unit. So, never mind. Continue whatever other investigations you have lined up.
Re: Trying to setup obexd but Operation not permitted
On Fri, Nov 05, 2021 at 02:46:18PM +0100, deloptes wrote: > Greg Wooledge wrote: > > > Check whether the systemd unit file is restricting network access for > > the service/process. > > ??? How do I do this - a hint would be helpful. Start by figuring out the name of the service. Then try "systemctl cat servicename > somefile". This should produce output that represents the entire unit file, possibly concatenating multiple real files together, Once you have that, you can look it over and see if anything pops out at you. If not, then you can try digging through the documentation for each line, to see what it does.
Re: Is "Debian desktop environment" identical to "GNOME" upon installation?
On 11/5/21 4:50 AM, Alejandro Colomar (man-pages) wrote: Hi, I did some test by installing 2 identical virtualbox instances (EFI turned on) with the same netinst image . I typically use XFCE, so I wanted to test if leaving "Debian desktop environment" marked would affect or not my XFCE installation. It does. a) | [ ] Debian desktop environment | [*] XFCE b) | [*] Debian desktop environment | [*] XFCE Using (b), I end up with 12 more installed packages. I checked that there weren't any available upgrades after installing both (apt-get update && apt-get upgrade showed 0). The offending list is: hv3 libsqlite3-tcl libtcl8.6 libtk-img libtk8.6 tcl tcl-tls tcl8.6 tcllib tk tk-html3 tk8.6 Maybe there's a bug somewhere in tasksel? I consider it Faulty Design. there is no "Debian desktop environment"... from my superficial testing it is kinda "Gnome Lite" (and in My Opinion gnome desktop is rather hateful). Being selected by default is a Huge design flaw. a simple "select a desktop environment" text message with something like "without a desktop you only get a terminal" as a suggestion for the uninformed would be far superior. BTW: I only use net-install because I don't want all that cruft. PS: hunting down all swap partitions on very drive and setting them to Format by default is also a real pain in the tush. I did some tests running tasksel again after the installation, and were intriguing, but I'll hold the deeper tests for after this is inspected. Cheers, Alex
mobilt 4g bredband
funkar sånt i buster? kopplar in mitt kombinerade router+modem i en usbport verkar som det dyker upp ett interface men det är inaktiverat obs! ingen pinkod på simkortet det funkar fint i win och mac os
Re: Trying to setup obexd but Operation not permitted
Greg Wooledge wrote: > Check whether the systemd unit file is restricting network access for > the service/process. ??? How do I do this - a hint would be helpful. thanks in advance -- FCD6 3719 0FFB F1BF 38EA 4727 5348 5F1F DCFE BCB0
Re: Is "Debian desktop environment" identical to "GNOME" upon installation?
On Fri, 2021-11-05 at 07:47 -0500, Nicholas Geovanis wrote: > On Fri, Nov 5, 2021, 7:21 AM Greg Wooledge wrote: > > > > Is "Debian desktop environment" identical to "GNOME" upon installation? > > > > > > > > Right now, for the regular official installers (and also for the > > unofficial installer with non-free firmware), that default task happens > > to be GNOME. > > > > With the "Live" installers, the default is different. > > > > And if I may ask: Why is it different? If there is a reason or two. Guessing here... because a live version already has a desktop environment on the disk, so it make sense to default to installing that one. E.g. if you choose, say, the XFCE live iso, it would default to XFCE not Gnome. Would be a bit perverse otherwise. -- Tixy
Re: Is "Debian desktop environment" identical to "GNOME" upon installation?
On Fri 05 Nov 2021 at 12:50:23 +0100, Alejandro Colomar (man-pages) wrote: > Hi, > > I did some test by installing 2 identical virtualbox instances (EFI turned > on) with the same netinst image . > > I typically use XFCE, so I wanted to test if leaving "Debian desktop > environment" marked would affect or not my XFCE installation. > > It does. > > a) > | [ ] Debian desktop environment > | [*]XFCE > > b) > | [*] Debian desktop environment > | [*]XFCE > > Using (b), I end up with 12 more installed packages. I checked that there > weren't any available upgrades after installing both (apt-get update && > apt-get upgrade showed 0). > > The offending list is: > > hv3 > libsqlite3-tcl > libtcl8.6 > libtk-img > libtk8.6 > tcl > tcl-tls > tcl8.6 > tcllib > tk > tk-html3 > tk8.6 > > Maybe there's a bug somewhere in tasksel? > > I did some tests running tasksel again after the installation, and were > intriguing, but I'll hold the deeper tests for after this is inspected. Bearing in mind that a bullseye installation of mine does not have a DE but does have xorg, the commands apt install task-desktop task-xfce-desktop apt install task-xfce-desktop tell me that 759 packages are needed in both cases. None of the packages you cite are mentioned in either list or already present on the sytem.. -- Brian.
Re: Is "Debian desktop environment" identical to "GNOME" upon installation?
On Fri, Nov 5, 2021, 7:21 AM Greg Wooledge wrote: > > Is "Debian desktop environment" identical to "GNOME" upon installation? > > > > Right now, for the regular official installers (and also for the > unofficial installer with non-free firmware), that default task happens > to be GNOME. > > With the "Live" installers, the default is different. > And if I may ask: Why is it different? If there is a reason or two.
Re: Is "Debian desktop environment" identical to "GNOME" upon installation?
> Is "Debian desktop environment" identical to "GNOME" upon installation? Assuming you install with one of the REGULAR installers (not one that contains the word "Live" anywhere in its name): yes. Selecting "Debian desktop environment" in the installer simply acts as an alias for whichever desktop environment task happens to be the default for that installer. Right now, for the regular official installers (and also for the unofficial installer with non-free firmware), that default task happens to be GNOME. With the "Live" installers, the default is different.
Re: Is "Debian desktop environment" identical to "GNOME" upon installation?
Hi, I added a few CCs, and added below a quote that I should have added to the original mail. On 11/5/21 12:50, Alejandro Colomar (man-pages) wrote: Hi, I did some test by installing 2 identical virtualbox instances (EFI turned on) with the same netinst image . I typically use XFCE, so I wanted to test if leaving "Debian desktop environment" marked would affect or not my XFCE installation. It does. a) | [ ] Debian desktop environment | [*] XFCE b) | [*] Debian desktop environment | [*] XFCE Using (b), I end up with 12 more installed packages. I checked that there weren't any available upgrades after installing both (apt-get update && apt-get upgrade showed 0). The offending list is: hv3 libsqlite3-tcl libtcl8.6 libtk-img libtk8.6 tcl tcl-tls tcl8.6 tcllib tk tk-html3 tk8.6 Maybe there's a bug somewhere in tasksel? I did some tests running tasksel again after the installation, and were intriguing, but I'll hold the deeper tests for after this is inspected. Sorry, I forgot to quote the previous mail: > I think the goal of the menu design was to accommodate > a first time user who has no experiential background > to chose a specific desktop. If you chose > "Debian desktop environment" AND a specific desktop, > the specific choice overrides. So I proved that this is not what is happening. Cheers, Alex -- Alejandro Colomar Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/ http://www.alejandro-colomar.es/
Re: Is "Debian desktop environment" identical to "GNOME" upon installation?
Hi, I did some test by installing 2 identical virtualbox instances (EFI turned on) with the same netinst image . I typically use XFCE, so I wanted to test if leaving "Debian desktop environment" marked would affect or not my XFCE installation. It does. a) | [ ] Debian desktop environment | [*]XFCE b) | [*] Debian desktop environment | [*]XFCE Using (b), I end up with 12 more installed packages. I checked that there weren't any available upgrades after installing both (apt-get update && apt-get upgrade showed 0). The offending list is: hv3 libsqlite3-tcl libtcl8.6 libtk-img libtk8.6 tcl tcl-tls tcl8.6 tcllib tk tk-html3 tk8.6 Maybe there's a bug somewhere in tasksel? I did some tests running tasksel again after the installation, and were intriguing, but I'll hold the deeper tests for after this is inspected. Cheers, Alex -- Alejandro Colomar Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/ http://www.alejandro-colomar.es/
Re: Trying to setup obexd but Operation not permitted
On Fri, Nov 05, 2021 at 09:32:27AM +0100, deloptes wrote: > Burhan Hanoglu wrote: > > > Could be something about that NFS mount. To narrow down; point it to > > /home/user/something that is not on NFS but on the local FS instead > > and see what happens. > > Hi, > yes it looks like it is somehow related, because on a local FS even with > same directory permissions (700) files are transferred fine. > So ... what is your opinion, where is the bug? Check whether the systemd unit file is restricting network access for the service/process.
Unidentified subject!
Re: how to update the DirectX/OpenGL driver
(Sorry, this should have gone to the list in the first place.) Please search the log for module nvidia. grep -i -C 3 nvidia /var/log/Xorg.0.log If you have installed package nvidia-driver in stable or testing, I can't imagine that it is too old for any software. Nouveau should be blacklisted by it automatically, IIRC. Regards, Christian Am 05.11.21 um 10:08 schrieb lina: > Hi all, > > I was told to "update the DirectX/OpenGL driver" when I tried to use > some software. > One example is > Renderer: Error creating Canvas3D graphics context > > I have general problems with the graphic rendering. > > > $ lspci | grep VGA > 01:00.0 VGA compatible controller: NVIDIA Corporation GK208B [GeForce GT > 730] (rev a1) > > > x11-xserver-utils install > xserver-common install > xserver-xorg install > xserver-xorg-core install > xserver-xorg-input-all install > xserver-xorg-input-libinput install > xserver-xorg-input-wacom install > xserver-xorg-legacy install > xserver-xorg-video-intel deinstall > xserver-xorg-video-nvidia install > > > i965-va-driver:amd64 install > intel-media-va-driver:amd64 install > libreoffice-base-drivers install > mesa-va-drivers:amd64 install > mesa-vdpau-drivers:amd64 install > mesa-vulkan-drivers:amd64 install > nvidia-driver install > nvidia-driver-bin install > nvidia-driver-libs:amd64 install > nvidia-vdpau-driver:amd64 install > va-driver-all:amd64 install > vdpau-driver-all:amd64 install > > cat /var/log/Xorg.0.log | grep -e WW -e EE > (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > [ 5.484] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not > exist. > [ 5.728] (WW) Warning, couldn't open module nouveau > [ 5.728] (EE) Failed to load module "nouveau" (module does not exist, 0) > [ 5.728] (WW) Warning, couldn't open module nv > [ 5.728] (EE) Failed to load module "nv" (module does not exist, 0) > [ 5.729] (WW) Warning, couldn't open module fbdev > [ 5.729] (EE) Failed to load module "fbdev" (module does not exist, 0) > [ 5.729] (WW) Warning, couldn't open module vesa > [ 5.729] (EE) Failed to load module "vesa" (module does not exist, 0) > [ 5.768] (WW) Falling back to old probe method for modesetting > [ 6.091] (II) Initializing extension MIT-SCREEN-SAVER > [ 6.596] (WW) Option "xkb_variant" requires a string value > [ 6.596] (WW) Option "xkb_options" requires a string value > [ 9.230] (WW) Option "xkb_variant" requires a string value > [ 9.230] (WW) Option "xkb_options" requires a string value > [ 30.617] (EE) event2 - PixArt HP USB Optical Mouse: client bug: > event processing lagging behind by 18ms, your system is too slow > [ 31.043] (EE) event2 - PixArt HP USB Optical Mouse: client bug: > event processing lagging behind by 28ms, your system is too slow > [ 904.011] (EE) event2 - PixArt HP USB Optical Mouse: client bug: > event processing lagging behind by 27ms, your system is too slow > > Thanks very much for your advice about how to fix it. > >
how to update the DirectX/OpenGL driver
Hi all, I was told to "update the DirectX/OpenGL driver" when I tried to use some software. One example is Renderer: Error creating Canvas3D graphics context I have general problems with the graphic rendering. $ lspci | grep VGA 01:00.0 VGA compatible controller: NVIDIA Corporation GK208B [GeForce GT 730] (rev a1) x11-xserver-utils install xserver-common install xserver-xorg install xserver-xorg-core install xserver-xorg-input-all install xserver-xorg-input-libinput install xserver-xorg-input-wacom install xserver-xorg-legacy install xserver-xorg-video-intel deinstall xserver-xorg-video-nvidia install i965-va-driver:amd64 install intel-media-va-driver:amd64 install libreoffice-base-drivers install mesa-va-drivers:amd64 install mesa-vdpau-drivers:amd64 install mesa-vulkan-drivers:amd64 install nvidia-driver install nvidia-driver-bin install nvidia-driver-libs:amd64 install nvidia-vdpau-driver:amd64 install va-driver-all:amd64 install vdpau-driver-all:amd64 install cat /var/log/Xorg.0.log | grep -e WW -e EE (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 5.484] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [ 5.728] (WW) Warning, couldn't open module nouveau [ 5.728] (EE) Failed to load module "nouveau" (module does not exist, 0) [ 5.728] (WW) Warning, couldn't open module nv [ 5.728] (EE) Failed to load module "nv" (module does not exist, 0) [ 5.729] (WW) Warning, couldn't open module fbdev [ 5.729] (EE) Failed to load module "fbdev" (module does not exist, 0) [ 5.729] (WW) Warning, couldn't open module vesa [ 5.729] (EE) Failed to load module "vesa" (module does not exist, 0) [ 5.768] (WW) Falling back to old probe method for modesetting [ 6.091] (II) Initializing extension MIT-SCREEN-SAVER [ 6.596] (WW) Option "xkb_variant" requires a string value [ 6.596] (WW) Option "xkb_options" requires a string value [ 9.230] (WW) Option "xkb_variant" requires a string value [ 9.230] (WW) Option "xkb_options" requires a string value [30.617] (EE) event2 - PixArt HP USB Optical Mouse: client bug: event processing lagging behind by 18ms, your system is too slow [31.043] (EE) event2 - PixArt HP USB Optical Mouse: client bug: event processing lagging behind by 28ms, your system is too slow [ 904.011] (EE) event2 - PixArt HP USB Optical Mouse: client bug: event processing lagging behind by 27ms, your system is too slow Thanks very much for your advice about how to fix it.
Re: bluetooth audio
Luis Mochan wrote: > After a recent update/upgrade in debian/bookworm my bluetooth > earphones and my bluetooth earphones stopped working. > I found a solution in the discussion of at > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=997862=no=no=no > > related to bug #997862 which seemed to work for me, that is, > installing a package libspa-0.2-bluetooth. FYI: Same is up on the pulseaudio devel list Bug#993011: pulseaudio-module-bluetooth: no longer detects bluetooth headphones
Re: grub2 uefi et raid
Le 20/10/2021 à 06:43, Jean-Michel OLTRA a écrit : Bonjour, Le mardi 19 octobre 2021, Kohler Gerard a écrit... Le problème : je ne me rappelle plus quel est le Debian qui gère le Grub, ni sur quel disque et quelle partition il est installé. comment faire pour avoir ces réponses ? Avec `fdisk -l` ou au menu de grub lors du boot (commande `find` de grub). habituellement pour installer une nouvelle version je clone ma partition système et je fais un upgrade. comment faire pour réinstaller Grub et sur quelle partition/DD ? Avec grub-install, je pense. je vous remercie avec retard !, après sauvegarde j'ai du tout réinstallé, avec un grub tout neuf. le problème de base venais du fait que je clonais mes partitions avec gparted, et celui-ci marque les partitions clonées avec le même UUID que la partition d'origine, d’où un petit mélange. Gérard
Re: Trying to setup obexd but Operation not permitted
Burhan Hanoglu wrote: > Could be something about that NFS mount. To narrow down; point it to > /home/user/something that is not on NFS but on the local FS instead > and see what happens. Hi, yes it looks like it is somehow related, because on a local FS even with same directory permissions (700) files are transferred fine. So ... what is your opinion, where is the bug? BR -- FCD6 3719 0FFB F1BF 38EA 4727 5348 5F1F DCFE BCB0
Re: Récupérer le résultat d'une commande sed dans une variable ou un fichier : problème...
salut, Le Fri, Nov 05, 2021 at 12:31:13AM +0100, roger.tar...@free.fr a écrit : > Et je n'ai même pas de fichier mais une variable à traiter. de manière générale: * passe par des pipes ou des fichiers plutot que des variables * utilise tee et mkfifo quand le probleme d'aiguillage est complexe. > J'avais créé un fichier pour tenter de débloquer la situation avec une > situation plus connue avec sed. Ca n'est pas la plus connue: c'est la seule :) et presque tous les filtres fonctionnent de même sed 'des trucs a faire' fichier1 fichier2 ... fichierN awk 'des trucs a faire' fichier1 fichier2 ... fichierN grep 'un motif à trouver' fichier1 fichier2 ... fichierN stdin est le fichier par defaut: ls | sed 's/.*/* [&](&)/' | cmark > TRUC est fournie par un traitement précédent du script. alors utilise un fichier plutot qu'une variable ./ton_precedent_script > TRUC < TRUC sed '...' si tu n'as pas besoin de truc, tu peux directement piper a sed ./ton_precedent_script | sed ... enfin si tu veux les 2 (enregistrer TRUC et passer a sed en meme temps), tu peux faire un tee qui est une maniere efficace de dupliquer un flot (ca fait appel à l'appel système du meme nom) ./ton_precedent_script | tee TRUC | sed '...' -- Marc Chantreux Direction du numérique de l'Université de Strasbourg Pôle de Calcul et Services Avancés à la Recherche (CESAR) http://annuaire.unistra.fr/p/20200
