Bug#830303: mmc0: Unexpected interrupt 0x04000000.
MICRO SDHC CARD (WORKS WITHOUT THE WORKAROUND) - SYSTEMD JOURNALD - Relevant messages: kernel: mmc0: new high speed SDHC card at address b368 kernel: mmcblk0: mmc0:b368 SD15.4 GiB kernel: mmcblk0: kernel: FAT-fs (mmcblk0): Volume was not properly unmounted. Some data may be corrupt. Please run fsck. udisksd[596]: Mounted /dev/mmcblk0 at /media/USERNAME/disk on behalf of uid 1000 udisksd[596]: Cleaning up mount point /media/USERNAME/disk (device 179:0 is not mounted) udisksd[596]: Unmounted /dev/mmcblk0 on behalf of uid 1000 kernel: mmc0: card b368 removed ADATA 32GB SDHC CARD (WORKS WITHOUT THE WORKAROUND) - SYSTEMD JOURNALD - Relevant messages: kernel: mmc0: Skipping voltage switch kernel: mmc0: new high speed SDHC card at address b368 kernel: mmcblk0: mmc0:b368 SD30.2 GiB kernel: mmcblk0: p1 kernel: FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck. udisksd[596]: Mounted /dev/mmcblk0p1 at /media/USERNAME/NIKON on behalf of uid 1000 udisksd[596]: Cleaning up mount point /media/USERNAME/NIKON (device 179:1 is not mounted) udisksd[596]: Unmounted /dev/mmcblk0p1 on behalf of uid 1000 kernel: mmc0: card b368 removed All three MICRO SD cards were connected via ADATA and SAMSUNG MICRO SD to SD adapters as the card reader slot only accepts SD cards. But it seems that various SD cards or adapters brands do not make a difference, instead the "ultra high speed" mode selected for more modern SD cards seems to cause the buggy behavior (the workaround forces such SD cards to use the slower "high speed" mode only). Regards, Bakhelit
Bug#990190: Debian installer 10.10 for ARM64 fails to boot on QEMU (Synchronous Exception at 0x0000000078465288)
Thank you for such a fast reaction and also for some nice info about SB in Debian (it will be useful for my future Debian installations:). I switched my scripts to generate my ISO from the Debian 10.9 ARM64 installer for now and will test the new Debian netinstall ISO for ARM64 when it arrives.
Bug#990190: Debian installer 10.10 for ARM64 fails to boot on QEMU (Synchronous Exception at 0x0000000078465288)
Package: debian-installer Version: 10.10.0-arm64-netinst Dear Maintainers, The "debian-10.10.0-arm64-netinst.iso" fails to boot on QEMU "virt" machine - it only produces this output: Synchronous Exception at 0x78465288 Other netinst ISO files seem not to have this problem - I tested: debian-10.9.0-arm64-netinst.iso WORKS OK debian-testing-arm64-netinst.iso WORKS OK debian-10.9.0-amd64-netinst.iso WORKS OK debian-10.10.0-amd64-netinst.iso WORKS OK USED QEMU COMMANDS (All options should be on single line; SCSI seems necessary for Debian installer to detect CD-ROM properly on ARM64): qemu-system-aarch64 -nographic -machine type=virt -bios /usr/share/qemu-efi-aarch64/QEMU_EFI.fd -netdev user,id=vnet,ipv4=on,ipv6=off,hostfwd=tcp::60010-:6 -device e1000,romfile=,mac=52:54:00:12:34:56,netdev=vnet -cpu max -smp cores=1 -m 1024 -device virtio-scsi-pci -blockdev driver=raw,node-name=hd,file.driver=file,file.filename=HD.img -device scsi-hd,drive=hd -blockdev driver=file,node-name=cd,filename=DEBIAN-NETINST.iso -device scsi-cd,drive=cd qemu-system-x86_64 -display gtk,gl=on,grab-on-hover=on,zoom-to-fit=on -full-screen -no-quit -enable-kvm -machine type=q35,accel=kvm -netdev user,id=vnet,ipv4=on,ipv6=off,hostfwd=tcp::60010-:6 -device e1000,romfile=,mac=52:54:00:12:34:56,netdev=vnet -cpu max -smp cores=1 -m 1024 -device virtio-scsi-pci -blockdev driver=raw,node-name=hd,file.driver=file,file.filename=HD.img -device scsi-hd,drive=hd -blockdev driver=file,node-name=cd,filename=-DEBIAN-NETINST.iso -device scsi-cd,drive=cd QEMU PACKAGES VERSIONS (all from Debian stable 10.10): qemu-system-arm 3.1+dfsg-8+deb10u8 qemu-system-gui 3.1+dfsg-8+deb10u8 qemu-system-x86 3.1+dfsg-8+deb10u8 qemu-utils 3.1+dfsg-8+deb10u8 Also I am unable to get the Debian installer for ARM64 working on QEMU with graphical display (GTK window). Replacing "-nographic" option with: -display gtk,gl=on,grab-on-hover=on,zoom-to-fit=on -full-screen -no-quit produces a QEMU GTK display window which unfortunately does not react to any keyboard input. The Debian installer for AMD64 seems not to work with "-nographic" option for a change and works with QEMU GTK display window:). Best Regards Bakhelit
Bug#974969: The "-full-screen" option causes guest display to overflow outside the host screen
After, further testing (basically 2 days of reading all QEMU docs and changelogs I found and messing around with various QEMU options:) I was able to solve my problems with the "-full-screen" option. The solution was to add the following option to my QEMU command: -display gtk,gl=on,grab-on-hover=on,zoom-to-fit=on The important bit that solved the display overflowing behavior is the "zoom-to-fit=on" suboption. This lets my VM to have the screen resolution I configure in it (e.g. 1920x1080) and when not in full screen mode it zooms the VM display to fit any QEMU window size without changing the screen resolution inside my VM. Although, the "-full-screen" option should probably work correctly on its own, so my solution is just a workaround. Also, remember the problem with "-soundhw hda" option, which prevented VM from starting with QEMU version from Debian Backports (5.0-14~bpo10+1)? It seems to occur in a different way also in QEMU version from Debian Stable (3.1+dfsg-8+deb10u8). In QEMU version 3.1+dfsg-8+deb10u8 my VM can start with the "-soundhw hda" option, but unfortunatelly the VM cannot produce any usable sound. I noticed there is already bug 949111 for this, so I described the details I observed in that bug (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949111#15). Finally, the initial delay on VM start is still there and it still shortens after repeated VM starts. Taken together, I guess QEMU is now usable enough for me on Debian 10, but it could be better if at least some of the problems I described are fixed properly. Anyway, here is my QEMU test command (updated with the display overflowing workaround) if someone wants to try reproduce and debug the problems I described (it is single line in case email reformats it): QEMU_PA_SERVER='/run/user/1000/pulse/native' QEMU_AUDIO_DRV='pa' qemu-system-x86_64 -display gtk,gl=on,grab-on-hover=on,zoom-to-fit=on -full-screen -enable-kvm -machine type=q35,accel=kvm -soundhw hda -netdev user,id=vnet -device e1000,netdev=vnet -cpu host -smp cores=2 -m 2048 -drive file=DISK.raw,format=raw,index=0,media=disk -drive file=IMAGE.iso,index=2,media=cdrom Regards Bakhelit
Bug#949111: Qemu soundhw hda is broken
I can confirm that the "-soundhw hda" option is still broken in 3.1+dfsg-8+deb10u8. When playing a movie or a song with VLC Media Player inside a guest (running Debian 10) one can hear very short bits of audio from time to time as Teran McKinney describes. Also, when I open Pulse Audio Volume Control in my host Debian 10 system, I can see in the "Playback" tab that the stream for QEMU very frequently appears and disappears - as if it was activated and immediately deactivated in some kind of broken loop. This is why one can probably hear those short bits of audio from the guest (= when the stream is active it all works). The GUI monitoring for PulseAudio used in my test is provided by "pavucontrol" package in Debian. Regards Bakhelit
Bug#974969: The "-full-screen" option causes guest display to overflow outside the host screen
Ok, I was able to test "qemu-system-x86" from Debian Backports - the following packages were upgraded on my system: libpmem11.5.1-1 (new installed package) libslirp0 4.3.1-1~bpo10+1 (new installed package) liburing1 0.6-3~bpo10+1 (new installed package) qemu-system-common 5.0-14~bpo10+1 (upgraded package) qemu-system-data5.0-14~bpo10+1 (upgraded package) qemu-system-gui 5.0-14~bpo10+1 (upgraded package) qemu-system-x86 5.0-14~bpo10+1 (upgraded package) qemu-utils 5.0-14~bpo10+1 (upgraded package) Unfortunately, the problem persists - the "-full-screen" option still behaves exactly as described in the initial bug report (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974969#5). Further more another option seems to be broken in the backports version. The "-soundhw hda" option seems to prevent VM from starting at all. The following modified test command (it is single line in case email reformats it): QEMU_PA_SERVER='/run/user/1000/pulse/native' QEMU_AUDIO_DRV='pa' qemu-system-x86_64 -full-screen -enable-kvm -machine type=q35,accel=kvm -soundhw hda -netdev user,id=vnet -device e1000,netdev=vnet -cpu host -smp cores=2 -m 2048 -drive file=DISK.raw,format=raw,index=0,media=disk -drive file=IMAGE.iso,index=2,media=cdrom Results in QEMU processes appearing in HTOP for a while and then disappearing. No QEMU window appears and no output is produced by QEMU (not even a warning or error). Only after QEMU processes disappear PULSEAUDIO complains with the following: pulseaudio: Wrong context state pulseaudio: Reason: Timeout pulseaudio: Failed to initialize PA contextaudio: warning: Using timer based audio emulation Aborted Looks like I will have to finish tuning my Debian 10 configs on my old Debian 9 system, where QEMU is working without problems. But, I hope to make QEMU usable on my Debian 10 systems eventually, so let me know if you need some more info:). Thanks Bakhelit
Bug#974757: The "-no-frame" option no longer works with qemu-system-* in Debian 10.
The "-full-screen" option problems are described in separate bug 974969 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974969). Regards Bakhelit
Bug#974969: The "-full-screen" option causes guest display to overflow outside the host screen
Package: qemu-system-x86 Version: 3.1 Dear Maintainers, On each VM start with the "-full-screen" option there is a delay. Duration varies from about a minute to a few seconds. With repeated VM starts the delay seems to shorten. Then the following message quickly appears (usually for less than 1 or 2 seconds) before the real guest display is shown: "Guest has not initialized display (yet).". When guest display is shown it is expanded and overflows outside the host screen. Using "Ctrl+Alt+f" two times to toggle the QEMU fullscreen seems to rescale the guest display correctly. Also after the first "Ctrl+Alt+f" the QEMU non-fullscreen window is expanded and overflows outside the host monitor. The QEMU non-fullscreen window seems to rescale the guest display correctly after using "Ctrl+Alt+2" followed by "Ctrl+Alt+1". I tested this with my dual monitor setup (laptop screen + external monitor both with the same resolution 1920x1080) for which I use the following "xrandr" commands: xrandr --output "$displayOne" --below "$displayTwo" # <- Extended xrandr --output "$displayOne" --same-as "$displayTwo" # <- Mirrored The described overflowing of the VM display was identical in both dual monitor modes and also in a single monitor setup. Single monitor test was with just the laptop screen and without any "xrandr" commands. HOW TO REPRODUCE: The overflowing behavior is reproducible with the following simplified "qemu-system-x86" command when I run it manually from terminal (it is single line in case email reformats it): qemu-system-x86_64 -full-screen -enable-kvm -machine type=q35,accel=kvm -netdev user,id=vnet -device e1000,netdev=vnet -cpu host -smp cores=2 -m 2048 -drive file=DISK.raw,format=raw,index=0,media=disk -drive file=IMAGE.iso,index=2,media=cdrom Test is reproducible with empty/formated "DISK.raw" and for example Debian 10 Netinst ISO as "IMAGE.iso" (= no need to install VM just start the empty one:). Then it is very easy: if you do not see the Debian swirl in bottom right corner after starting VM, the guest display overflows outside the host screen:). RELEVANT SYSTEM DETAILS: My system has enabled only the integrated graphics in Intel Core i7-3632QM CPU and uses XFCE with "xfwm4" window manager. All packages are automatically updated from Debian 10 "main" repository - current versions for relevant packages are: linux-image-4.19.0-12-amd64 4.19.152-1 qemu-system-gui 3.1+dfsg-8+deb10u8 qemu-system-x86 3.1+dfsg-8+deb10u8 qemu-utils 3.1+dfsg-8+deb10u8 xfce4-session 4.12.1-6 xfdesktop4 4.12.4-2 xfwm4 4.12.5-1 xserver-xorg7.7+19 xserver-xorg-video-fbdev0.5.0-1 xserver-xorg-video-vesa 2.4.0-1 Let me know if you need any more info. I will try to test "qemu-system-x86" 5.0 or 5.1 from Debian Backports or Unstable when I have more time. Best Regards Bakhelit
Bug#974757: The "-no-frame" option no longer works with qemu-system-* in Debian 10.
Thanks for correcting my understanding of the "-no-frame" option situation. In that case feel free to close the bug. I will test the "-full-screen" option more and report the problems in a separate bug. Regards Bakhelit
Bug#974757: The "-no-frame" option no longer works with qemu-system-* in Debian 10.
Package: qemu-system-x86 Version: 3.1 Dear Maintainers, the "-no-frame" option that works nicely with qemu-system-x86 2.8 (in Debian 9 - Stretch) is not usable with qemu-system-x86 3.1 (in Debian 10 - Buster). This is, because qemu-system-* no longer uses SDL for default display and uses GTK instead. I was unfortunately unable to find any alternative that would allow me to run my virtual machines in a graphical window that has no decoration/border and thus can take the exact screen size (e.g. 1080x1920) like my physical display. I tested the "-full-screen" option, which resulted in qemu-system-* window that stretched outside of visible screen. Maybe this was so, because my dual monitor setup confused QEMU:), but it is just a laptop screen + external monitor and both have same size 1080x1920. I was also not successful when using "xprop" commands intended to disable window decoration/border (but I probably used wrong ones). I am using XFCE and I could not find any info that would help me force xfwm4 to disable window decorations for specific windows. This means I cannot use my virtual machines easily for testing my Debian configs before deploying them on my laptops (as many applications have this nasty habit of saving screen/window size or position in their configs:). Also, I really do not need any functionality that is provided by the GTK window decoration/border or its menus, so I would prefer if the "-no-frame" capability or some other usable alternative was implemented for qemu-system-* GTK display. If someone can point me to a workaround or solution of this problem I would be very grateful. Even an "xprop" command or something similar is acceptable for me as I will add it to my script that runs qemu-system-*. Also, thanks for all good work you do to bring us QEMU:). Best Regards Bakhelit
Bug#913345: Video seek causes video track to lag when the "Hurry up" setting is not enabled in VLC 3.X
As I already reported in the upstream bug: I tested this again with VLC 3.0.11 on Debian 9.13 and 10.6 and video seek seems to work fine now. However, I am not sure which exact VLC version resolved my problem (it could be any of the following versions: 3.0.7, 3.0.8, 3.0.10 or 3.0.11). Anyway, feel free to close the bug. Regards, Bakhelit
Bug#960848: The GVFS dialog "Enter a passphrase to unlock the volume" shows radio buttons when there is no keyring
Package: gvfs Version: 1.38.1-5 Dear Maintainers, the GVFS dialog "Enter a passphrase to unlock the volume" shows radio buttons with passphrase saving options even when there is no keyring running or installed. Obviously this is just a non-critical wishlist type bug report, but I think it would be less confusing for the user if the radio buttons are displayed only if there is an available keyring that can actually save the passphrase. Otherwise the default action should be "Forget password immediately" without showing the radio buttons. Also perhaps the dialog should use just the word "passphrase" or "password" but not both. Regards, Bakhelit
Bug#960846: The "path-exclude" and "path-include" configurations are not taken into account on package removals
Package: dpkg Version: 1.19.7 Dear Maintainers, The "path-exclude" and "path-include" configurations in "/etc/dpkg/dpkg.cfg.d/00path-exclude-and-include" are not taken into account on package removals. To reproduce you can for example: - Install the package "xfwm4". - Add "path-exclude /usr/share/themes/*" to "/etc/dpkg/dpkg.cfg.d/00path-exclude-and-include". - Remove or reinstall the package "xfwm4". - See that "xfwm4" themes in "/usr/share/themes/*" are gone. This is obviously problematic when one wants to modify some files from a given package while preserving their names/paths. Then any update, reinstall or removal of the given package removes also the customized files even if those files are excluded using the "path-exclude" configurations in "/etc/dpkg/dpkg.cfg.d/00path-exclude-and-include". Currently I need to use custom workaround scripts to periodically restore the such modifications and try to minimize such modifications, but still it would be nice if the current "path-exclude" and "path-include" mechanisms could be improved in this regard. Regards, Bakhelit
Bug#903393: [initramfs-tools] update-initramfs -u warns: Unknown X keysym "dead_belowmacron"
Dear Maintainer, On Debian 9 (with console-setup 1.164) running "sudo update-initramfs -u" produces: update-initramfs: Generating /boot/initrd.img-4.9.0-12-amd64 WARNING: Unknown X keysym "dead_belowbreve" WARNING: Unknown X keysym "dead_belowbreve" WARNING: Unknown X keysym "dead_belowmacron" WARNING: Unknown X keysym "dead_belowmacron" WARNING: Unknown X keysym "dead_belowring" WARNING: Unknown X keysym "dead_belowring" WARNING: Unknown X keysym "dead_belowcircumflex" WARNING: Unknown X keysym "dead_belowcircumflex" WARNING: Unknown X keysym "dead_greek" WARNING: Unknown X keysym "dead_greek" WARNING: Unknown X keysym "dead_greek" WARNING: Unknown X keysym "dead_greek" WARNING: Unknown X keysym "dead_belowdiaeresis" WARNING: Unknown X keysym "dead_belowdiaeresis" WARNING: Unknown X keysym "dead_belowtilde" WARNING: Unknown X keysym "dead_belowtilde" WARNING: Unknown X keysym "dead_belowtilde" WARNING: Unknown X keysym "dead_belowtilde" On Debian 10 (with console-setup 1.193~deb10u1) running "sudo update-initramfs -u" produces: update-initramfs: Generating /boot/initrd.img-4.19.0-9-amd64 This is with my custom XKB keyboard layout where I included the quite a few "dead_*" X keysyms. The problem is indeed caused by the Perl script "/usr/bin/ckbcomp" because: - The script does not support all X keysyms. - Despite not supporting all X keysyms the supported X keysyms are used as if the remaining unknown X keysyms are potentially invaild X keysyms. - On Debian 9 the "/usr/share/initramfs-tools/hooks/keymap" script calls "/bin/setupcon" via "setupcon --save-keyboard ..." which causes it to call "/usr/bin/ckbcomp". - On Debian 10 the "/usr/share/initramfs-tools/hooks/keymap" script calls "/bin/setupcon" via "setupcon --setup-dir ..." which causes it to not call "/usr/bin/ckbcomp". Perhaps the Perl script "/usr/bin/ckbcomp" should be updated to support all X keysyms or the current supported X keysyms should be used as just an incomplete whitelist, where the remaining unknown X keysyms are also potentially vaild keysyms. In other words an info or warning about unsupported X keysym could be printed only in verbose or debug mode or not at all. Regards, Bakhelit
Bug#913344: The "Headphone virtual spatialization effect" setting not working in VLC 3.X when the "Force detection of Dolby Surround" setting is enabled
Seems, no longer present in VLC 3.0.6+ in Unstable - see my comments in https://trac.videolan.org/vlc/ticket/21439 for details.
Bug#913344: Bug#913345: Video seek causes video track to lag when the "Hurry up" setting is not enabled in VLC 3.X
As requested I reported both issues to VLC upstream. Links are: https://trac.videolan.org/vlc/ticket/21440 https://trac.videolan.org/vlc/ticket/21439 I also added the output of "vlc -vvv" to the issue where at least something relevant to the bug report seemed to be in the VLC output. Regards, Bakhelit
Bug#913348: Locale "i18n" has possibly a wrong value in LC_ADDRESS category
Package: locales
Version: 2.24-11
Locale "i18n" may have a bug in LC_ADDRESS category as it has the value:
"/
/
/
/
"
that gives "%a%N%f%N%d%N%b%N%s %h %e %r%N%C-%z %T%N%c%N"
instead of "%n%N%a%N%f%N%d%N%b%N%s %h %e %r%N%l%N%C-%z %T%N%S%N%c%N"
which I found in ISO/IEC TR 14652:2002 at
"http://www.open-std.org/jtc1/sc22/wg20/docs/n972-14652ft.pdf;
(on page 55). Missing fields seems to be "%n%N", "%l%N" and "%S%N".
Probably this should be verified with the current version of the
standard full text which I did not find easily available. But it seems
logical that an address begins with "Person's name" ("%n%N") and
contains also the "%l%N" and "%S%N" fields.
Also the "locales" package from Debian unstable (version 2.27-8) has the
same and possibly wrong value "%a%N%f%N%d%N%b%N%s %h %e %r%N%C-%z
%T%N%c%N" in the LC_ADDRESS category in the
"/usr/share/i18n/locales/i18n" file.
Anyway I am not sure if any software on my Debian systems actually uses
the LC_ADDRESS category, so I probably cannot test what problems this
causes (if any). I just noticed this problem by accident when fighting
an uphill battle with Mozilla Thunderbird about formating dates and
times using a clear ISO way instead of crazy ambiguous formats in
various locales (e.g. en_US or cs_CZ etc.). Well maybe when the Borg
assimilate us we will finally be able to agree on doing basic things in
one standard and most efficient way:D. Until then lets enjoy arguing
about miles vs kilometers, AM/PM vs 24H, date formats, timezones,
languages and other nonsense:).
Regards,
Bakhelit
Bug#913345: Video seek causes video track to lag when the "Hurry up" setting is not enabled in VLC 3.X
Package: vlc
Version: 3.0.3-1
Since Debian stable switched to VLC 3.X I started to notice the problem
with video seek. I was able to reproduce the problem consistently with
VLC 3.0.3 from Debian stable repository and with VLC 3.0.4 from Debian
unstable repository.
Video seek causes video track to lag (as if it is slightly paused and
resumed extremely frequently). After disabling and then enabling the
video track again it plays normally until one performs a seek again.
This seems to be caused by the "avcodec-hurry-up=0" setting in the
"~/.config/vlc/vlcrc" file. When this is switched to the default value
("avcodec-hurry-up=1") video seek works normally. However I would prefer
using "avcodec-hurry-up=0" to be sure that VLC does not skip frames as
my CPU is fast enough and previous VLC versions worked great with
"avcodec-hurry-up=0".
Mostly noticed with various MP4/MKV files with H264 MPEG-4 AVC codec
(all files which I tested up to now, so sample should be easy to obtain).
Regards,
Bakhelit
Bug#913344: The "Headphone virtual spatialization effect" setting not working in VLC 3.X when the "Force detection of Dolby Surround" setting is enabled
Package: vlc Version: 3.0.3-1 Since Debian stable switched to VLC 3.X I started to notice the problem with "Headphone virtual spatialization effect" setting. I was able to reproduce the problem consistently with VLC 3.0.3 from Debian stable repository. I did not test this in Debian unstable as I have no sound enabled in my test VM (but my guess is that the problem should be also reproducible in unstable). Enabling the "Headphone virtual spatialization effect" setting causes audio tracks (including in songs not just in videos) to become garbled and especially speech is not understandable. After disabling the setting the audio tracks play normally. In previous versions (before VLC 3.X) the "Headphone virtual spatialization effect" setting enabled a usable surround sound experience even for stereo audio tracks with normal stereo headphones, so it is missed greatly. Noticed with various files and various audio/video codecs (all files which I tested up to now, so sample should be easy to obtain). The "Headphone virtual spatialization effect" setting can be found in VLC advanced/all settings in "Audio > Filters". The specific settings in the "~/.config/vlc/vlcrc" file are: audio-filter=headphone force-dolby-surround=1 headphone-compensate=1 headphone-dim=3 and after further testing i noticed that the combination of the "audio-filter=headphone" with "force-dolby-surround=1" is what causes the problem. I had both settings enabled because the following extract from the "Force detection of Dolby Surround" option tooltip seemed to be true: "... Even if the stream is not actually encoded with Dolby Surround, turning on this option might enhance your experience, especially when combined with the Headphone Channel Mixer." (assuming "Headphone virtual spatialization effect" is "Headphone Channel Mixer" as I found no other similar VLC setting that contains string "Headphone"). Regards, Bakhelit
Bug#863642: [Pkg-xfce-devel] Bug#863642: Thunar shows all fstab entries in devices in the Shortcuts Side Pane
On Mon, 05 Nov 2018 13:25:57 +0100 Yves-Alexis Perez
wrote:
- - not sure what you mean by “Root Thunar”, but just in case: don't run Thunar
as root user
- - you can declutter the side-pane as you wish by right-clicking on the
“Devices” text and selecting what items you want or not.
Thanks for info, although I already know about that workaround. Anyway,
I run Thunar as root ("Root Thunar") only when editing some system files
not for general usage.
I also reported this bug upstream about a week ago
(https://bugzilla.xfce.org/show_bug.cgi?id=14812) together with another
Thunar bug (https://bugzilla.xfce.org/show_bug.cgi?id=14811) that is not
reported for Debian so far I think.
Regards
Bakhelit
Bug#863642: [Pkg-xfce-devel] Bug#863642: Thunar shows all fstab entries in devices in the Shortcuts Side Pane
Dear Maintainer, I just did some testing with Thunar 1.6.11 (on my main system - Debian Stretch) and with Thunar 1.8.2 (on my VM system - Debian Stretch + Thunar and its dependences from Sid/Stretch Backports). Root Thunar (both versions) still shows unwanted entries in DEVICES in the Shortcuts Side Pane. That is both "Filesystem root" and "boot" entries are still present (and add redundant clutter in UI) in addition to the standard "File System" entry. This should be reproducible even on a system that uses just the single root partition. Then only the redundant "Filesystem root" entry should be there in addition to the standard "File System" entry. Regards Bakhelit
Bug#837708: Various Thunar frezes/crashes in bugs 837708, 868704, 862397, 884799, etc.
Dear Maintainer, I just did some testing with Thunar 1.6.11 (on my main system - Debian Stretch) and with Thunar 1.8.2 (on my VM system - Debian Stretch + Thunar and its dependences from Sid/Stretch Backports). It seems that various random freezes/crashes do not happen with Thunar 1.8.2 - I used the following Bash script to test: #!/usr/bin/env bash declare -i loopNumber=0 declare -i continueLoop=1 echo 'Testing started.' while true; do echo 'TEST' > ./a mkdir ./d mv ./a ./d/b tar -cf ./a.tar ./d mv ./d ./f tar -xf ./a.tar cp ./d/b ./a rm ./a shred -zu ./d/b rm -rf ./d ./f ./a.tar loopNumber+=1 continueLoop=$(($loopNumber % 100)) if [ $continueLoop -eq 0 ]; then echo "Loop number $loopNumber passed." echo 'Sleping for 5 seconds so you can safely hit CTRL+C.' sleep 5 echo "Testing started again." if [ -f ./Document.odt ]; then echo "Testing ODT extract and archive." mv -f ./Document.odt ./Document.odt.extracted.zip unar -f -q ./Document.odt.extracted.zip mv -f ./Document.odt.extracted.zip ./Document.odt cd ./Document.odt.extracted zip -0 -X ../New.zip ./mimetype zip -r -q ../New.zip ./* -x ./mimetype cd .. mv -f ./New.zip ./Document.odt echo "Tested ODT extract and archive." echo 'Sleping for 5 seconds so you can safely hit CTRL+C.' sleep 5 fi fi done The script causes Thunar 1.6.11 on my main system to freeze very soon when testing ODT extract and archive (any ODT file can be used for testing). In general Thunar 1.6.11 regularly stops responding when scripts or custom actions manipulate contents of directories opened with Thunar on my main Debian Stretch system. With Thunar 1.8.2 this seems not to happen, but maybe it would be good to adapt/improve the test script just to be more sure before closing the bugs. Regards Bakhelit
Bug#544651: Bug 794971 + 544651 - lvm2 - Volume group not found, unable to find LVM during boot
I can confirm the mentioned warnings about LVM volume groups on all my
Debian Stretch systems. Messages seems to be caused by the running order
of initramfs scripts in "/usr/share/initramfs-tools/scripts/local-*" -
"lvm2" script seems to be run before "cryptroot" script. This is caused
by lines 10 to 16 in
"/usr/share/initramfs-tools/scripts/local-*/cryptroot" - when scripts
run in a default alphabetic order ("cryptroot" then "lvm2") no warnings
seems appear.
Note that I made more modifications to my "lvm2" and especially
"cryptroot" initramfs scripts, so if somebody can confirm that just
changing the run order of default scripts is enough to avoid the
warnings about LVM volume groups it would be nice. Also note the
modified initramfs scripts should be in
"/etc/initramfs-tools/scripts/local-*" and you need to rebuild your
initramfs to test the changes.
When this is confirmed maybe the package for bugs 794971 and 544651
should be changed to "cryptsetup" instead of "lvm2"?
Regards
Bakhelit
Bug#799295: Bug 799295 - lvm2 - Errors about lvmetad on boot
I can also see the mentioned warnings about lvmetad on all my Debian
Stretch systems. Messages seems to be indeed caused by lvm "vgscan",
"vgchange" and may be also "lvchange" commands in "cryptroot" and "lvm2"
initramfs scripts in "/usr/share/initramfs-tools/scripts/local-*".
Because I wanted to achieve the silent boot with just the password
prompt from cryptsetup I modified the workaround mentioned by Matti
Kurkela (as it seemed not to work for my systems). Instead of adding "
--config 'global{use_lvmetad=0}'" to the lvm commands I now redirect
their output to a log file by adding " >>/run/log/initrd-lvm 2>&1".
(Note that the "/run/log" directory must exist when the output is
redirected. Also the modified initramfs scripts should be in
"/etc/initramfs-tools/scripts/local-*" and you need to rebuild your
initramfs as described by Matti Kurkela above.)
It would be nice to have a "--quiet" option for lvm commands, maybe?
Regards
Bakhelit
Bug#863642: [Pkg-xfce-devel] Bug#863642: Thunar shows all fstab entries in devices in the Shortcuts Side Pane
Looked at it again, and I also cannot reproduce showing devices on desktop - probably because only root Thunar shows the fstab entries in DEVICES in the Shortcuts Side Pane. On my current testing system (installed from Stretch RC3 installer but fully updated) root Thunar shows in DEVICES (when no USB, network or other devices are connected): File System (this is ok -> non-root Thunar shows only this entry) Filesystem root (this is LVM for "/" with BTRFS) boot (this is BTRFS partition for boot which I can even unmount:) When I had a separate LVM for "/home" it was shown also as "home" in root Thunar DEVICES (at that time EXT4 was used instead of BTRFS). Current partitions on my test system are: sda1 (BTRFS boot), sda2_crypt (ENCRYPTED LVM for SWAP and "/" with BTRFS). If libglib2.0-0 is installed from stable (version 2.42.1-1) both root and non-root Thunar show just the "File System" entry in DEVICES in the Shortcuts Side Pane.
Bug#863642: Thunar shows all fstab entries in devices in the Shortcuts Side Pane
Package: thunar Version: 1.6.3-2 or 1.6.11-1 As reported in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836355 after upgrading from stable (Jessie) to testing (Stretch), Thunar shows all fstab entries in devices or on desktop (depending on the user configuration). This seems to be caused by upgrading the libglib2.0-0 to version 2.50.3-2 in testing. Because solving this in libglib2.0-0 seems unlikely, I am reporting this here so that Thunar maintainers/developers can look at the issue. Best regards, A Happy Debian User
Bug#836355: libglib2.0-0: makes all entries of fstab show up as desktop items
Package: thunar Version: 1.6.3-2 or 1.6.11-1 Package: libglib2.0-0 Version: 2.50.3-2 I can confirm similar behavior of Thunar on my test system. The system has encrypted disk using dm-crypt and LVM (3 LVM volumes in 1 volume group on the encrypted disk and an unencrypted boot partition). When I use Thunar as root it now shows the boot partition and LVM volumes in devices (in the Shortcuts Side Pane - on my system showing removable devices on desktop is disabled). These are all the entries from /etc/fstab on that system (with the exception of the swap entry). This started after I recently upgraded some packages to testing/unstable versions. By downgrading packages back to stable (Jessie) versions I found that the problem is caused by upgrading the libglib2.0-0 from version 2.42.1-1 in stable to version 2.50.3-2 in testing/unstable. I also tested it with different versions of thunar (stable 1.6.3-2 and testing/unstable 1.6.11-1) and the behavior was always the same as described above (complete upgrade of the test system from stable to testing also did not change the described behavior). I suggest that showing all the entries from /etc/fstab (LVM volumes, etc.) is disabled as with the stable version, because it just adds clutter in file manager's GUI and could confuse the user to even accidentally unmount the volume. I was able to unmount the boot volume while the attempt to unmount the home and root volumes failed with error describing that the volume is in use. By the way adding "comment=x-gvfs-hide" or "x-gvfs-hide" options to fstab entries is not working for me. The only way I found for hiding these devices is to hide them using the right click context menu in the Thunar Shortcuts Side Pane. This adds type="array">... to "~/.config/xfce4/xfconf/xfce-perchannel-xml/thunar.xml". But since sometimes UUIDs are used, it is very difficult to create a general config for multiple systems. Can any one explain what device ID types can be used in the "hidden-devices" property in "thunar.xml" or what options to add to fstab entries to hide them from devices in Thunar? Best regards, A Happy Debian User
Bug#808602: USB 3 regression - external HDD disconnects immediately after connecting
Package: linux-image-3.16.0-4-amd64 Version: 3.16.7-ckt20-1+deb8u1 Severity: normal Dear Maintainer, the recent kernel update (to version 3.16.7-ckt20-1+deb8u1) introduced a regression on my systems - my HDDs in the external USB 3.0 box are disconnected immediately after I connect them to any USB port on my laptop. In other words connecting to USB 3.0 or 2.0 port does not make a difference - it is not possible to use the external HDD in both cases. After downgrading the kernel (to version 3.16.7-ckt11-1+deb8u3) the HDDs in the external USB 3.0 box work normally. On both kernel versions my USB 2.0 devices (flash disks, mouse etc.) seems to work ok. For now as a workaround I use the previous kernel version 3.16.7-ckt11-1+deb8u3, because I need to use the external HDDs often, however it would be nice to resume the security updates for the kernel as soon as this issue is fixed. If needed I will be able (in a day or two) to test whether the problem occurs also with another USB 3.0 flash disk and on a different laptop. Thanks Your Happy Debian User -- Package-specific info: ** Version: Linux version 3.16.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt20-1+deb8u1 (2015-12-14) ** Kernel log (lines related to this USB problem): [ 254.846529] usb 4-1: new SuperSpeed USB device number 2 using xhci_hcd [ 254.864086] usb 4-1: New USB device found, idVendor=152d, idProduct=0539 [ 254.864093] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=5 [ 254.864096] usb 4-1: Product: USB to ATA/ATAPI Bridge [ 254.864099] usb 4-1: Manufacturer: JMicron [ 254.864101] usb 4-1: SerialNumber: 2461937287FF [ 254.864596] usb 4-1: Set SEL for device-initiated U1 failed. [ 259.867742] usb 4-1: Set SEL for device-initiated U2 failed. [ 259.867867] usb-storage 4-1:1.0: USB Mass Storage device detected [ 259.868398] scsi7 : usb-storage 4-1:1.0 [ 264.872900] usb 4-1: Set SEL for device-initiated U1 failed. [ 269.878233] usb 4-1: Set SEL for device-initiated U2 failed. [ 292.514162] usb 4-1: reset SuperSpeed USB device number 2 using xhci_hcd [ 292.540524] usb 4-1: device descriptor read/8, error -71 [ 292.641985] usb 4-1: reset SuperSpeed USB device number 2 using xhci_hcd [ 292.668663] usb 4-1: device descriptor read/8, error -71 [ 292.826931] usb 4-1: USB disconnect, device number 2 [ 292.827371] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 880036e60040 [ 292.827378] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 880036e60088 ** Loaded modules: nls_utf8 nls_cp437 vfat fat ctr ccm pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) ip6t_REJECT xt_hl ip6t_rt nf_conntrack_ipv6 nf_defrag_ipv6 ipt_REJECT xt_LOG xt_limit xt_tcpudp xt_addrtype nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack ip6table_filter ip6_tables nf_conntrack_netbios_ns nf_conntrack_broadcast nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack iptable_filter ip_tables x_tables uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core v4l2_common videodev snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic media arc4 ath9k ath9k_common ath9k_hw joydev ath mac80211 snd_hda_intel snd_hda_controller snd_hda_codec iTCO_wdt snd_hwdep iTCO_vendor_support acer_wmi cfg80211 x86_pkg_temp_thermal snd_pcm_oss intel_powerclamp evdev intel_rapl sparse_keymap psmouse serio_raw rfkill snd_mixer_oss snd_pcm i915 drm_kms_helper drm snd_timer i2c_i801 i2c_algo_bit i2c_core video processor shpchp snd soundcore lpc_ich mfd_core mei_me mei thermal_sys battery ac kvm_intel kvm button wmi coretemp fuse autofs4 ext4 crc16 mbcache jbd2 sha256_ssse3 sha256_generic algif_skcipher af_alg dm_crypt dm_mod hid_generic usbhid hid sg sd_mod sr_mod crc_t10dif cdrom crct10dif_generic usb_storage crct10dif_pclmul crct10dif_common crc32_pclmul crc32c_intel ghash_clmulni_intel ahci aesni_intel libahci aes_x86_64 lrw gf128mul glue_helper ablk_helper ehci_pci cryptd libata xhci_hcd ehci_hcd tg3 sdhci_pci scsi_mod sdhci ptp pps_core mmc_core libphy usbcore usb_common ** PCI devices (USB related): 00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller [8086:1e31] (rev 04) (prog-if 30 [XHCI]) Subsystem: Acer Incorporated [ALI] Device [1025:0647] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Latency: 0 Interrupt: pin A routed to IRQ 40 Region 0: Memory at c060 (64-bit, non-prefetchable) [size=64K] Capabilities: Kernel driver in use: xhci_hcd 00:1a.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 [8086:1e2d] (rev 04) (prog-if 20 [EHCI]) Subsystem: Acer Incorporated [ALI] Device [1025:0647] Control: I/O- Mem+ BusMaster+ SpecCycle-
