Bug#927946: python-audit: SWIG-related type errors render module unusable
Package: python-audit Version: 1:2.8.4-2 Severity: grave Tags: upstream Justification: renders package unusable Dear Maintainer, The following operations fail due to a SWIG-related type error: ``` % sudo python Python 2.7.16 (default, Apr 6 2019, 01:42:57) [GCC 8.3.0] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import audit >>> fd = audit.audit_open() >>> audit.audit_set_enabled(fd, 1) Traceback (most recent call last): File "", line 1, in TypeError: in method 'audit_set_enabled', argument 2 of type 'uint32_t' >>> ``` Relevant discussion: http://swig.10945.n7.nabble.com/SWIG-vs-uint32-t-td15045.html Best regards, Michael -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python-audit depends on: ii libaudit11:2.8.4-2 ii libauparse0 1:2.8.4-2 ii libc62.28-8 ii python 2.7.16-1 python-audit recommends no packages. python-audit suggests no packages. -- no debconf information signature.asc Description: Digital signature
Bug#788543: bareos-sd will silently corrupt backups when using multi-volume disk-based jobs
Package: bareos Version: 14.2.1+20141017gitc6c5b56-4 Severity: critical Justification: causes serious data loss In March 2015 bareos fixed a bug which caused silent corruption of backups when the following conditions are met: * backups are written to disk (tape backups are not affected) * autolabelling is enabled * a backup spans over multiple volumes * the additional volumes are newly created and labeled during the backup. Bug: https://bugs.bareos.org/view.php?id=437 Announcement: http://www.bareos.com/en/company_news/items/Bareos-14.2.4-published.html Fix for 14.2: https://github.com/bareos/bareos/commit/263240eaa911563a8468ecdaf7d4957201b41426 Given that the above conditions are met in most bareos installations I've tagged this as critical. While I'm at it I'd like to point out that Joerg Steffens, an upstream maintainer, employee and/or partner of bareos.com and co-maintainer of this package in Debian, hasn't found the time to inform the Debian community of this issue, lest providing a patched package. best, Michael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#504747: fdisk gpt bug
Robert Lemmen wrote: hi michael, could you explain how to create such a partition? i have created a small loopback with a GPT partition, but i don't see that behaviour... Not using a loopback device but a plain file: # create a sparse file, ~200GB in this case dd if=/dev/zero of=fakedisk bs=1 count=0 seek=21990232 # write gpt label parted fakedisk mklabel gpt # create a partition fdisk fakedisk # commands: n/return/return/asdf/return/+10G/w # verify that gpt label exists (look for 01 00 ee fe ff ff in line 1c0) dd if=fakedisk bs=512 count=1 | hexdump -C -v # write MBR dd if=/dev/urandom of=fakedisk bs=440 count=1 conv=notrunc # verify MBRs existence (random data before partition marker) dd if=fakedisk bs=512 count=1 | hexdump -C -v # create another partition fdisk fakedisk # commands: n/return/return/fdsa/return/+10G/w # notice absence of random data dd if=fakedisk bs=512 count=1 | hexdump -C -v For the record: mirror02:~# dpkg -l gnu-fdisk coreutils parted libparted1.8-10 linux-image-2.6.26-1-amd64 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++--- ii coreutils6.10-6 The GNU core utilities ii gnu-fdisk1.0-3+b1 Linux fdisk replacement based on libparted ii libparted1.8-10 1.8.8.git.2008.03.24-11 The GNU Parted disk partitioning shared library ii parted 1.8.8.git.2008.03.24-11 The GNU Parted disk partition resizing program mirror02:~# Hope that's clear enough, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#504747: gnu-fdisk: It is normal to wipe out MBR :-) You asked for it.
Osamu Aoki wrote: At least this bug should be important (or wishlist) severity bug if we consider only the bug reported here. But I am happy to keep this as RC. Here is the situation: Although some of the way gnu-fdisk works (bug#504099) is not something I like, this Bug #504747 behavior of gnu-fdisk is normal and expected. Expected? By someone who is a systems developer with reference to EFI or a HPUX/IA64 Windows administrator, maybe. From the users perspective (and I guess that i386 and amd64 are combined well over 95% of the Debian installations out there) your statement is of laughable ignorance. I'll present some facts, please correct me if I'm wrong. *) As of now (12/2008) the amount of x86 commodity hardware which is able to boot EFI is close to nil. *) The tools/toolchains to prepare a clean disk to be able to boot EFI on x86 do not exist or are highly experimental *) Partitioning disks with MBR/MS-DOS Style partitioning isn't feasible for RAID-Devices with 2 or more disks already due to it's 2TB addressing limit and will become unfeasible for single Disks in 2009, with Multi-Terabyte drives around the corner. *) Using the Code Area of the Legacy MBR of a GPT to load the second stage of a bootloader is perfectly fine in the scenarios outlined above. *) The Lenny D-I will automatically use GPT partitioning when confronted with block devices = 2TB. *) gnu-fdisk is a tool which is an alternative to fdisk, closely imitating it's interface, not hinting on any fundamental differences between it's predecessor or GPT. I understand your reasoning behind the original behaviour, but the industry (and thusly the community) failed to pick up on EFI support. By now time has caught up with us and we do have to do something about it. Ignoring the situation won't make it go away. If you want to avoid a lot of unhappy users during the Lenny lifecycle I'd suggest that you take this issue seriously and think about the actual use case. People use your software, not reference implementations. I'd be happy if there were any feasible alternatives, but from what I've seen so far it seems as if we're all alone out in the cold on this one. GNU parted also wipes out MBR when editting GPT. Basically, running GPT managing software will reset and clean MBR record to the GPT used by EFI. So it fails identically for this use case ;). best regards, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#504747: gnu-fdisk: It is normal to wipe out MBR :-) You asked for it.
Osamu Aoki wrote: Hi Michael, You are quick :-) Please understand I am all for removing this package. And this is why I don't want to discuss this issue with you anymore. *) gnu-fdisk is a tool which is an alternative to fdisk, closely imitating it's interface, not hinting on any fundamental differences between it's predecessor or GPT. But when we are dealing with different beast such as GPT, we should not fake its situation almost as MBR. This is the thing most bad about gnu-fdisk. Why is this a problem? If your issue is with installer, please put it there. Please note important bug is not RC. I thought I clearly laid out what the issue is. I'll try it again. There is currently _NO WAY_ to _SANELY_ edit _THE ONLY_ partition table available on x86 systems for devices larger than 2TB (which are available Real Soon Now), without _DESTROYING YOUR BOOT CHAIN_. When the device in question happens to be your boot device. Also I think this is not just Debian problem. If you know other distro doing it right, please point it out. They may be using some patch to the libraries used by gnu-fdisk/parted. I'm not much of a community guy. The only distribution I actively use is Debian because it gets stuff most of the times right. I hoped that somebody would eventually notice the reach of the situation and take care of it. I general, new hardwares (be it huge disk space or new design), causes issues. They are not RC but quite annoying. Please don't argue about the importance of the bug if you fail to understand the situation. Have a good night, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#504747: gnu-fdisk: wipes out MBR when used on GPT partitions
Package: gnu-fdisk Version: 1.0-3+b1 Severity: grave Justification: causes non-serious data loss gnu-fdisk wipes out the Code Area in the MBR of a given device when modifying a GPT partition. If this happens to be the boot device, this can cause serious trouble. The behaviour can be easily verified with dd and hexdump. Create a blockdevice with a gpt label, then write data to the code area, e.g.: dd if=/dev/urandom of=/dev/sdc bs=440 count=1 and verify that it's there: dd if=/dev/sdc bs=512 count=1 | hexdump -C -v Then get fdisk to rewrite the partition table (starting and immediately (re)writing the partition table works); a verification with dd/hexdump should show an empty Code Area. The free encyclopedia has a nice layout of the MBR, for verification: http://en.wikipedia.org/wiki/Master_boot_record best regards, Michael -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gnu-fdisk depends on: ii libc62.7-15 GNU C Library: Shared libraries ii libncurses5 5.6+20080830-1 shared libraries for terminal hand ii libparted1.8-10 1.8.8.git.2008.03.24-11 The GNU Parted disk partitioning s ii libuuid1 1.41.2-1universally unique id library gnu-fdisk recommends no packages. gnu-fdisk suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
