Bug#872057: The problem in flexbackup has to do with tar
Further tests have shown that the bug in flexbackup seems to surface only when using tar. I did not test all other tools supported by tar but several backups using cpio and zip all went through without the problem. Debian Jessie used tar 1.27 while Debian Stretch uses tar 1.29. I can't tell if the problem exists because there was a change in the way tar parses its input or commands or if there is a problem in tar itself. Maybe somebody who is better than me looking at “long command lines” (do flexbackup ... -n to make a dry run and see the command line) can tell what is wrong.
Bug#849525: Bug also confirmed in version 1.28.2
On Mon, 14 Aug 2017 21:41:20 -0500 Jason Crain wrote: On Mon, Aug 14, 2017 at 05:15:56PM -0400, Markus Hamilton wrote: > The bug is still there using version 1.28.2 now ... in fact there are forum > discussions and bug reports all over the internet about this problem for > years now. Could we at least get a statement from the maintainers whether > this will ever get fixed or is there some policy we could implement to allow > this. SOME information would really help to figure out where this is going. From the gvfs-mount manpage: -a, --anonymous Use an anonymous user when authenticating This option was added in gvfs version 1.23.90 so gvfs-mount (or gio mount) should work on stretch or later. On earlier versions you can try entering a fake username and password depending on how you have samba set up. About pcmanfm and caja - I don't see any problem with anonymous smb shares using nautilus so this is likely something that pcmanfm and caja need to add support for. I think we misunderstand each other. I am not talking about anonymous access. I am talking about accessing a samba server which does not have anonymous (guest) access enabled. So users do have to provide a username to be able to login. Some of these usernames (aka smb accounts) just have no (or in other words an empty) password. Using anonymous access will not work (disabled on the server). A fake username will not work either (unknown to the server). It has to be a valid username and an empty password. Using mount via command line works fine. Here's an example - "markus" is a valid smb account at the server. The password is empty. sudo mount -t cifs //servername/sharename /mnt -o username=markus,password="" But when I try the same operation using gvfs-mount like this: gvfs-mount smb://servername/sharename Then the first thing gvfs-mount does is spitting out a message saying "Password required for share sharename on servername". It then asks for username, then domain and finally password. Just hitting "enter" doesn't cut it. gvfs-mount asks again for the password. So far I have not managed to mount a smb share using gvfs-mount if the valid smb account simply is passwordless. If you can tell me how to do that then I'm ready to shift the blame to pcmanfm and caja. "mount -t cifs..." is living proof that it's not a samba (or Windows, for that matter) problem. So again: how do I gvfs-mount a smb share with a non-anonymous, valid smb username but without entering (because there is none) a password? Thank you for reading here. There are so many users out there with the same problem. It used to work. It stopped working at some point during the life of jessie.
Bug#872057: flexbackup stores multiple copies of files in backup archive
Package: flexbackup Version: 1.2.1-6.3 Flexbackup used to work for me for years, the last version included in Debian 8 works without problems. The version for Debian 9 had changes made due to a new version of perl. Seems like nobody ever tested the software ... Here's how to reproduce the problem: 1. Setup flexbackup to use "tar". 2. Setup any directory for backup which contains a multilevel structure, like /etc 3. Run a backup job 4. Inspect the resulting *.tar.gz file using an archive manager like engrampa level 1 files will be backed up twice level 2 files will be backed up three times level 3 files will be backed up four times and so on ... Also, $exclude_expr[] which worked in the last version are not working anymore. As of now, flexbackup is pretty much unusable.
Bug#784579: [REGRESSION] vmwgfx black screen until X started
Hi Bernhard, I'm so sorry for the long delay in getting back to you. Somehow I was not notified that there was a new (your) message waiting to be read. The good news is that adding "vmwgfx.enable_fbdev=1" to the kernel command line definitely solves the problem! The system works as expected now. The fix has been tested with 3 different computers and 2 different VMWare versions (Workstation 7 and 11) and everything is good now. Thanks again for the quick solution! Markus
Bug#784579: linux-image-3.16.0-4-amd64: Boot process / DRM initialization causes blank console
If I disable the "GRUB_GFXPAYLOAD_LINUX" parameter then GRUB does not tell Linux anything. I assume that GRUB (or is it the Linux kernel?) switches back to 80x25 text mode and the whole boot process completes without problems. No black screen. Markus Hamilton. On 5/6/2015 17:46, Ben Hutchings wrote: > Control: retitle -1 [REGRESSION] vmwgfx black screen until X started > > On Wed, 2015-05-06 at 16:43 -0400, Markus Hamilton wrote: >> Package: src:linux >> Version: 3.16.7-ckt9-3~deb8u1 >> Severity: important >> >> The installation has been a Debian 7 system in a VMware Workstation 11 >> environment which runs under Windows 7x64 on a HP G61 laptop. There is no >> display manager installed. Linux just boots to a console login prompt. X11 is >> started manually after login using "startx". The vesa mode for Linux is set >> in >> /etc/default/grub using "GRUB_GFXPAYLOAD_LINUX=1366x768x8". The kernel >> package >> used in Debian 7 was linux-image-3.2.0-4-amd64. > [...] > > Does this also happen if you don't tell GRUB to set the screen mode for > Linux? > > Ben. > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org