Bug#1070339: libata bug after resume from suspend
After updating to the -21 kerenl, I could not reproduce this anymore. I went back and forth between -21 and -20 a few times, and found the exact steps to reproduce it, but it only works under -20: 1) enable runtime PM on the disks 2) wait for runtime PM to suspend the disks 3) suspend the system So it seems that this has been fixed.
Bug#1051903: gparted: Warning symbol when formatting in FAT32 in all removable disks
jpedro writes: >* What led up to the situation? > Creating or formating fat32 partitions in any removable disk (usb > disks > and SD cards) shows a warning symbol. At the information menu appears > to be a possible bad disk. Also the disk is not properly formatted or > the partition not properly created. Are you sure that you *formatted* the partition? Just creating the partition without formatting it results in the warning symbol. Can you post the output of parted print on such a drive?
Bug#1025568: gparted: diff for NMU version 1.3.1-1.1
Hugh McMaster writes: > I didn't see a need to build-depend on libpolkit-gobject-1-dev, but > I'm not overly familiar with gparted's requirements. I think something changed in 1.5 that made it require a file that moved to this package in trixie, so I had to add it to get it to build. > Please let me know if I should submit a PR for the NMU on salsa > (noting you'd have to update the changelog to account for your recent > changes), or whether I should cancel the upload. Sorry for the late reply. I would have said cancel it but it looks like it already went through. It sounds like it shouldn't hurt for me to just upload my build though, so I'll do that now that I sorted out my new signing subkey.
Bug#1025568: gparted: diff for NMU version 1.3.1-1.1
Hugh McMaster writes: > Control: tags 1025568 + patch > Control: tags 1025568 + pending > > Dear maintainer, > > I've prepared an NMU for gparted (versioned as 1.3.1-1.1) and > uploaded it to DELAYED/2. Please feel free to tell me if I > should delay it longer. I have an upload of 1.5 pending my sorting my gpg key out again. Could you submit any changes as a PR on salsa? I think I saw someone had done that for some minor issues ( was that you? ) but the CI failed.
Bug#1043290: ITS policy lost in transition?
Package: src:policykit-1 Version: 123-1 I'm trying to package a new upstream of the gparted package and respond to bug #1025568 involving a policykit transition. It appears that gparted uses gettext which is failing to build because it requires /usr/share/gettex/its/policy.its and policy.loc. These files used to be provided by policykit-1, but no longer appear to be packaged at all in Trixie. Were these files supposed to be migrated to another package and forgotten? I would imagine this should be causing ftbs in a number of packages that use gettext. Then again, I wonder if gettext needs these files, why were they part of policykit before? Why aren't they shipped with gettext or a package that it depends on?
Bug#983357: Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel
Chuck Zmudzinski writes: > If it doesn't work, I am also willing to try approach a by patching > the Linux kernel xen-kbdfront driver by removing the for loops that > advertise those 654 keys. I tend to agree with Philip that this is > totally unnecessary, but I suppose I could be wrong about that. > I read the discussion Philip had with the Xen developers and they > seemed to want to keep the Xen keyboard driver as it is. That was the first thing I tried and the libinput maintainer pointed out that if you don't advertise the keys, you can't use the keys. In other words, somebody presses that key on their keyboard and the domU won't recognize it.
Bug#983357: Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel
Ben Hutchings writes: > I think a proper fix would be one of: > > a. If the Xen virtual keyboard driver is advertising capabilities it >doesn't have, stop it doing that. > b. Change the implementation of modalias attributes to allow longer >values. > > It's not clear to me whether the Xen driver is advertising correctly or > not. If it is, then the solution should be b, but that may be too > disruptive a change to the kernel. So a reasonable workaround might > be: > > c. Change the input subsystem to limit the length of the >capabilities part of the modalias. The problem with a) is that the Xen keyboard is not a physical keyboard and so it has no way of knowing what keys it actually has. It is a fake input device designed to pass through whatever input the Xen hypervisor sends down. As such, any key could come in. If it doesn't advertise that it has all of these keys, then they would not be accepted by libinput when the hypervisor sends them down. This seems to be the heart of the problem: libinput was designed assuming that all keyboards can and must report what keys are actually present, and then libinput tries to cram that information into the modalias rather than some other sysfs attribute as it should ( or not at all... I still don't see how this information is actually supposed to be useful to userspace ). As for b), the problem isn't with the modalias attribute itself, but when the kernel tries to copy it into the environment block for the udev callout. The environment block is only a single page, and so limited to 4 KB. And that's for everything else that goes into the environment, not just the modalias.
Bug#989656: Xen misusing syslog
Package: xen-utils-common Version: 4.14.1+11-gb0b734a8b3-1 My syslog has entries that look like this: Jun 09 10:54:26 hyper1 root[621]: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/1/768 The third field is supposed to be the program name, which I would expect to either be xen or xl or something, but instead it appears to be passing $USER.
Bug#983357: Netinst crashes xen domU when loading kernel
Michael Biebl writes: > So this is a change in behaviour in the kernel? Yes, this commit fixed the kernel to report the error instead of silently failing: commit df44b479654f62b478c18ee4d8bc4e9f897a9844 Author: Peter Rajnoha Date: Wed Dec 5 12:27:44 2018 +0100 kobject: return error code if writing /sys/.../uevent fails Propagate error code back to userspace if writing the /sys/.../uevent file fails. Before, the write operation always returned with success, even if we failed to recognize the input string or if we failed to generate the uevent itself. With the error codes properly propagated back to userspace, we are able to react in userspace accordingly by not assuming and awaiting a uevent that is not delivered. Signed-off-by: Peter Rajnoha Signed-off-by: Greg Kroah-Hartman > What happens if you boot the installed system? Does udevadm trigger fail > there as well? Yes, it does; that is how I was able to track down the problem. > I feel a bit uneasy changing the udev start script this late in the > release cycle (especially when it appears like covering up an issue > someplace else). > > I'll let Marco make the judgement on this though, as he has the most > experience with those udev udeb start scripts as the original author. So far I have been removing the -e from the shbang line in the start-udev script and remastering the iso so I can get it to boot. It would probably be a better idea to just add a || true to the udevadm trigger call. I feel fairly certain that no matter what the cause of the coldplug failure, the user is going to be better off ignoring it and trying to proceed than a kernel panic.
Bug#983357: Netinst crashes xen domU when loading kernel
The discussion upstream does not seem to be converging on a proper fix in the kernel, so I'm going to clone this bug and suggest that debian-installer patch the start-udev script to ignore the failure of the udevadm trigger command. To summarize: init ends up calling start-udev which calls udevadm trigger to cold plug all devices. Both scripts are set -e. The Xen Virtual Keyboard driver and at least one other driver have always failed to trigger due to having absurdly long modalias, but the error used to be ignored. The kernel now returns the error to udevadm, so it exits with an error, so start-udev exits with an error, so init exits with an error, causing the kernel to panic.
Bug#962214: (no subject)
julien forest writes: > Package: policykit-1 > Version: 0.105-30 > State: not installed > Multi-Arch: foreign > Priority: optional > Section: admin > Maintainer: Utopia Maintenance Team > Architecture: amd64 > Uncompressed Size: 335 k > Depends: ... default-logind | logind ... > > which itself depends on libpam-systemd or libpam-elogind > > There is no need IMHO to add such a dependency (maybe a recommend). gparted depends on policykit-1 to get run as root. Unless there's some other way that still works these days to do that, removing this depenency will break the desktop icon. That depends on either systemd or elogind, which AFAIK, are already requirements for any of the supported desktops. Then again, if policykit-1 is already installed in all of the desktops, the depenency may be redundant? On the other hand, if it is redundant, then how will removing it help you? If it isn't redundant, then what configurations will break because they don't have policykit-1 and so launching gparted from the desktop icon will fail?
Bug#983357: Netinst crashes xen domU when loading kernel
I dug down to the the -ENOMEM coming from the fact that the modalias is over 2KB of crap so it won't fit in the environment block when the input core tries to add it for the uevent. I don't see how it gets this way though because the MODULE_ALIAS() statement in the code just says it should be "xen: vkbd". When I read the modalias in sysfs, it says: input:b0001v5853pe-e0,1,k71,72,73,74,75,76,77,78,79,7A,7B,7C,7D,\ 7E,7F,80,81,82,83,84,85,86,87,88,89,8A,8B,8C,8D,8E,8F,90,91,92,93,94,95,\ 96,97,98,99,9A,9B,9C,9D,9E,9F,A0,A1,A2,A3,A4,A5,A6,A7,A8,A9,AA,AB,AC,AD,\ AE,AF,B0,B1,B2,B3,B4,B5,B6,B7,B8,B9,BA,BB,BC,BD,BE,BF,C0,C1,C2,C3,C4,C5,\ C6,C7,C8,C9,CA,CB,CC,CD,CE,CF,D0,D1,D2,D3,D4,D5,D6,D7,D8,D9,DA,DB,DC,DD,\ DE,DF,E0,E1,E2,E3,E4,E5,E6,E7,E8,E9,EA,EB,EC,ED,EE,EF,160,161,162,163,16\ 4,165,166,167,168,169,16A,16B,16C,16D,16E,16F,170,171,172,173,174,175,17\ 6,177,178,179,17A,17B,17C,17D,17E,17F,180,181,182,183,184,185,186,187,18\ 8,189,18A,18B,18C,18D,18E,18F,190,191,192,193,194,195,196,197,198,199,19\ A,19B,19C,19D,19E,19F,1A0,1A1,1A2,1A3,1A4,1A5,1A6,1A7,1A8,1A9,1AA,1AB,1A\ C,1AD,1AE,1AF,1B0,1B1,1B2,1B3,1B4,1B5,1B6,1B7,1B8,1B9,1BA,1BB,1BC,1BD,1B\ E,1BF,1C0,1C1,1C2,1C3,1C4,1C5,1C6,1C7,1C8,1C9,1CA,1CB,1CC,1CD,1CE,1CF,1D\ 0,1D1,1D2,1D3,1D4,1D5,1D6,1D7,1D8,1D9,1DA,1DB,1DC,1DD,1DE,1DF,1E0,1E1,1E\ 2,1E3,1E4,1E5,1E6,1E7,1E8,1E9,1EA,1EB,1EC,1ED,1EE,1EF,1F0,1F1,1F2,1F3,1F\ 4,1F5,1F6,1F7,1F8,1F9,1FA,1FB,1FC,1FD,1FE,1FF,200,201,202,203,204,205,20\ 6,207,208,209,20A,20B,20C,20D,20E,20F,210,211,212,213,214,215,216,217,21\ 8,219,21A,21B,21C,21D,21E,21F,220,221,222,223,224,225,226,227,228,229,22\ A,22B,22C,22D,22E,22F,230,231,232,233,234,235,236,237,238,239,23A,23B,23\ C,23D,23E,23F,240,241,242,243,244,245,246,247,248,249,24A,24B,24C,24D,24\ E,24F,250,251,252,253,254,255,256,257,258,259,25A,25B,25C,25D,25E,25F,26\ 0,261,262,263,264,265,266,267,268,269,26A,26B,26C,26D,26E,26F,270,271,27\ 2,273,274,275,276,277,278,279,27A,27B,27C,27D,27E,27F,280,281,282,283,28\ 4,285,286,287,288,289,28A,28B,28C,28D,28E,28F,290,291,292,293,294,295,29\ 6,297,298,299,29A,29B,29C,29D,29E,29F,2A0,2A1,2A2,2A3,2A4,2A5,2A6,2A7,2A\ 8,2A9,2AA,2AB,2AC,2AD,2AE,2AF,2B0,2B1,2B2,2B3,2B4,2B5,2B6,2B7,2B8,2B9,2B\ A,2BB,2BC,2BD,2BE,2BF,2C0,2C1,2C2,2C3,2C4,2C5,2C6,2C7,2C8,2C9,2CA,2CB,2C\ C,2CD,2CE,2CF,2D0,2D1,2D2,2D3,2D4,2D5,2D6,2D7,2D8,2D9,2DA,2DB,2DC,2DD,2D\ E,2DF,2E0,2E1,2E2,2E3,2E4,2E5,2E6,2E7,2E8,2E9,2EA,2EB,2EC,2ED,2EE,2EF,2F\ 0,2F1,2F2,2F3,2F4,2F5,2F6,2F7,2F8,2F9,2FA,2FB,2FC,2FD,2FE,ramlsfw
Bug#983357: (no subject)
I bisected the problem to this commit: commit df44b479654f62b478c18ee4d8bc4e9f897a9844 Author: Peter Rajnoha Date: Wed Dec 5 12:27:44 2018 +0100 kobject: return error code if writing /sys/.../uevent fails Propagate error code back to userspace if writing the /sys/.../uevent file fails. Before, the write operation always returned with success, even if we failed to recognize the input string or if we failed to generate the uevent itself. With the error codes properly propagated back to userspace, we are able to react in userspace accordingly by not assuming and awaiting a uevent that is not delivered. Signed-off-by: Peter Rajnoha Signed-off-by: Greg Kroah-Hartman So it appears that the Xen Virtual Keyboard driver was always broken but the error in triggering the uevent was not previously reported. The upstream bug report notes another driver failing. There are probably other drivers too. I will continue to try to find and fix the Xen keyboard error so it no longer fails anyway, but it is probably a good idea to patch the start-udev script in d-i to ignore errors. It is better to continue with some device not triggering a cold plug event than to instantly panic the kernel in early boot.
Bug#987688: Please add more filesystem drivers to hd-media
Package: debian-installer Version: 20210415 I just tried using the hd-media build to boot from an existing hard disk and install without using removable media and was not able to do so because I used btrfs on the hard disk, and most filesystems are packaged as separate udebs rather than being built into the initrd. I think it was only iso9660, fat, and ext4 that were in there. Please consider moving btrfs and probably a few other filesystem modules into the hd-media initrd so that it can be used outside of ext4 and fat.
Bug#983357: #983357: Netinst crashes xen domU when loading kernel
affects 983357 + debian-installer severify 983357 serious thanks It appears that the root cause of this bug has been reported upstream here: https://bugzilla.kernel.org/show_bug.cgi?id=207695 It seems that there is an error trying to udev trigger the Xen virtual keyboard, and this causes start-udev to bail out, which causes init to bail out and the kernel to panic. Removing the set -e from start-udev appears to be a viable workaround that d-i might want to consider.
Bug#983357: #983357: Netinst crashes xen domU when loading kernel
reopen 983357 thanks I don't know what happened, but it is back to not working, even with the install.amd/xen/ kernel. Phillip Susi writes: > The netinst image I had contained the -3 kernel. I rebuit the image > with the current -6 kernel and it worked. I downloaded the latest > weekly netinst iso and it already contains the -6 kernel, so it appears > that this has been fixed in -4, -5, or -6.
Bug#962214: Needles dependencies to policykit
julien forest writes: > Is there any hope to remove this dependency to policykit-1 which > prevents users who do not want to use systemd to install the current > version of gparted ? What does policykit have to do with systemd? AFAIK, that is the mechanism that all desktops can use to run a program as root.
Bug#983357: #983357: Netinst crashes xen domU when loading kernel
reassign 983357 linux severity grave thanks I rebuilt the iso using the version of isolinux from stable and it still crashed the domU. When I rebuilt it using the vmlinux and initrd.gz from the stable iso, it successfully boots, so it appears to be caused by the kernel. Interestingly, there appears to be a different kernel build just for use under xen in install.amd/xen and using that one also works. Maybe we need a menu option in isolinux to load that kernel instead?
Bug#983357: Netinst crashes xen domU when loading kernel
Package: debian-installer Version: 20201202 Every bullseye netinst image I have tried to boot in a xen domU has crashed and rebooted the domU after choosing any entry from the boot menu. I thought there might have been something wrong with my xen server, which was running Ubuntu 18.04, but I rebuilt it the other day using bullseye as the dom0, and I still can't install bullseye in a domU.
Bug#981692: Try to use the gain value and set it to 512 (one sector) instead of default 1MiB. Its a bug in sfdisk BTW.
Eric Valette writes: > Its and very old SSD that has been partitionned at time where thedefault > 1MiB space limit between partition was was no there. Apart that I did > partition probably usinf cfisk at that time. > > What is strange is that in my case sfdisk -V reports no error and the > partitions are correctly detected so the EBR are obviously stored... It is theretically possible to say, store multipe EBRs in the start of the extended partition before the first logical partition, then have no space between each logical partition, but parted does not support this. It requires the EBR to be between the previous partition and the next, so there must be at least one unused sector between them. I have seen reports over the years of people running into disks built this way but never been able to figure out how they got that way. > I guess that it happens that the default size for sfdisk "grain" value > (see man sfdisk) has chnaged from one sector to one MiB. I created the > following output. see the gain value below. I still get an error: img6: /dev/sdb6 : start= 158203904, size= 9762816, type=83 Start sector 158203904 out of range. Failed to add #6 partition: Numerical result out of range
Bug#981692: parted: crash when printing device partitions
When I tried to recreate this, sfdisk gave me an error that the numerical result was out of range. When I looked closely at the numbers, it appears that you have no space between partitions 5 and 6, so there is no room to place the EBR. Do you know how you managed to generate a partition table that is broken in this way?
Bug#948739: gparted should not mask .mount units
Control: reopen -1 Ivo De Decker writes: > This new upstream version doesn't remove the code masking the systemd units. > It just changes it a little. So it doesn't fix this bug. Woops... you're right.
Bug#948739: Bug #948739: gparted should not mask .mount units
John Paul Adrian Glaubitz writes: > Hello! > > It looks like this particular issue has been fixed in gparted 1.2.0 which > was just released a few days ago [1]: > >> - Don't try to mask non-existent Systemd \xe2\x97\x8f.service (#129, !64) > > Might be an idea to update gparted to version 1.2.0 before the Bullseye freeze > which is coming in Mid-February [2]. Thanks... on it.
Bug#979596: Missing fonts from package
Package: kbd Version: 2.3.0-3 The t and drdos fonts provided by the upstream kbd package are missing in the debian binary package.
Bug#979532: Wrong man page installed for gdm(8)
Package: gdm3 Version: 3.38.2.1-1 /usr/share/man/man8/gdm3.8.gz actually contains a copy of of the man page for gdm-screenshot(1) rather than gdm3.
Bug#977411: gdm does not recognize keyboard input
I disabled wayland in /etc/gdm3/daemon.conf and and keyboard input works fine in X11.
Bug#977411: gdm does not recognize keyboard input
I just made a clean install in a new vm from 10.7 netinst, then did a dist-upgrade, and once again, keyboard input is not being recognized. This may be a release-critical issue? My host system is Ubuntu 18.04 running Xen 4.9.2, and I'm using vnc to access the virtual console.
Bug#977411: gdm3: gdm does not recognize keyboard input
Package: gdm3 Version: 3.38.2-1 Severity: important X-Debbugs-Cc: ph...@thesusis.net Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? After not using it for some time, I fired up my testing VM ( in a Xen DomU ) and ran a dist-upgrade. Since then ( last week ), I can't log into the gui because it does not recognize any keyboard input. libinput-debug from the xen console recognizes the input, but not gdm3. * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-4-amd64 (SMP w/8 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gdm3 depends on: ii accountsservice 0.6.55-3 ii adduser 3.118 ii dbus 1.12.20-1 ii dconf-cli 0.38.0-1 ii dconf-gsettings-backend 0.38.0-1 ii debconf [debconf-2.0] 1.5.74 ii gir1.2-gdm-1.03.38.2-1 ii gnome-session [x-session-manager] 3.38.0-3 ii gnome-session-bin 3.38.0-3 ii gnome-session-common 3.38.0-3 ii gnome-settings-daemon 3.38.1-2 ii gnome-shell 3.38.2-1 ii gnome-terminal [x-terminal-emulator] 3.38.1-2 ii gsettings-desktop-schemas 3.38.0-2 ii konsole [x-terminal-emulator] 4:20.08.3-1 ii kwin-x11 [x-window-manager] 4:5.19.5-3 ii libaccountsservice0 0.6.55-3 ii libaudit1 1:2.8.5-3.1+b1 ii libc6 2.31-5 ii libcanberra-gtk3-00.30-7 ii libcanberra0 0.30-7 ii libgdk-pixbuf2.0-02.40.2-2 ii libgdm1 3.38.2-1 ii libglib2.0-0 2.66.3-2 ii libglib2.0-bin2.66.3-2 ii libgtk-3-03.24.24-1 ii libkeyutils1 1.6.1-2 ii libpam-modules1.3.1-5 ii libpam-runtime1.3.1-5 ii libpam-systemd247.1-3 ii libpam0g 1.3.1-5 ii librsvg2-common 2.50.2+dfsg-1 ii libselinux1 3.1-2+b2 ii libsystemd0 247.1-3 ii libx11-6 2:1.6.12-1 ii libxau6 1:1.0.8-1+b2 ii libxcb1 1.14-2 ii libxdmcp6 1:1.1.2-3 ii lsb-base 11.1.0 ii mutter [x-window-manager] 3.38.2-1 ii plasma-workspace [x-session-manager] 4:5.19.5-5+b1 ii policykit-1 0.105-29 ii procps2:3.3.16-5 ii ucf 3.0043 ii x11-common1:7.7+21 ii x11-xserver-utils 7.7+8 ii xterm [x-terminal-emulator] 362-1 Versions of packages gdm3 recommends: ii at-spi2-core2.38.0-2 ii desktop-base10.0.3 ii x11-xkb-utils 7.7+5 ii xserver-xephyr 2:1.20.10-1 ii xserver-xorg1:7.7+21 ii zenity 3.32.0-6 Versions of packages gdm3 suggests: pn gnome-orca pn libpam-fprintd ii libpam-gnome-keyring 3.36.0-1 -- debconf information: * shared/default-x-display-manager: gdm3 gdm3/daemon_name: /usr/sbin/gdm3
Bug#948739: Bug #948739: gparted should not mask .mount units
Just wanted to note in this copy of the bug that the recommendation from upstream systemd was that gparted should not be masking mounts but instead should take a bsd lock on the device to prevent auto mounts.
Bug#955858: gparted: does not start, 'unable to init server', tmp.mount does not exist
Kyle B writes: > (gpartedbin:11049): Gtk-WARNING **: 09:04:39.901: cannot open display: What display server / desktop environment are you using?
Bug#916260: gparted mounts partition without protection
Marc Lehmann writes: > No, it just means gparted has a security bug, because the permissions > did work as the user intended before gparted changed them without the > users knowledge, and they would have worked if gparted wasn't insecurely > exposing the files. Claiming that the side effect of keeping the fs either unmounted or mounted somewhere users can't see is part of the permissions is like claiming that keeping power from reaching the computer is part of the security system. I mean, without the ability to power on the computer, people can't access the files, so by your logic, if I plug the computer in then I'm the problem. Any setup that relies on directory traversal to prevent people from reaching files that they otherwise are given access to is very fragile and badly set up. If an admin later builds a chroot environment for isntance, and sets up some bind mounts, they can inadvertently give access to the wrong users because they now can see the files that have poorly configured permissions. It's just not smart to do things that way. > The reason why your logic doesn't work is that you claim *every* debian > root fs has the wrong permissions, because some directories might be > world-writable (such as /tmp) which might not be what the user > intended It isn't /tmp that is wrong, but whatever files you are storing in the btrfs volume and have left set to 777. Don't do that. > by not having the fs mounted in an insecure location (and thus allowing a > DoS attack). It would also mean filesystems such as fat, without intrinsic > permissions, would somehow have "wrong" permissions. That's why fat has mount options to set the permissions on the fs globally. >> When gparted mounts it somewhere that isn't traverse proof, yes, that >> does allow access where it was not previously, but that's really only >> exposing the underlying bug that was always there: that the permissions >> on the files are too loose. > > Well, I have asked you for the source of this claim, but you haven't given > one - and I claim you just made it up, because I can't believe you have a > source. Source? The source is the givens of the scenario we are discussing -- a file or files in a filesystem with mode 777 so that everyone can access it, but mounted in a directory that is traverse restricted. That is de facto too loose. If you are just going to make an appeal to authority fallacy in continued attempts to semantically redefine loose to tight and wrong right, then this is just a waste of time.
Bug#916260: gparted mounts partition without protection
Marc Lehmann writes: > Maybe it helps when you realise thta chown can also modify a file... Only root can do that. In any case, I was ceeding the point that it is essentially the same thing. > You yourself mentioned some - in any case, does this lead somewhere? I was just curious if there were some that I didn't know about. >> In both cases the permissions on the file itself are wrong, > > You keep making this false claim, but that doesn't lend it more > credence. POSIX permissions work the way they work, and if you think some > combination of permissions are wrong, what are the rules to determine > right and wrong and what is your source for this repeated statement? Simple... right doesn't allow access to the people you don't want to have it. Wrong permissions do allow access to those you don't intend to have it. Working around that by other means ( to deny access to the entire filesystem ) does not change the fact that the permissions on the file are not configured correctly to carry out your intent. >> >> The permissions allow access that you do not wish it to. Ipso facto, >> the permissions are incorrect. > > Ah, maybe I see where you are copming from - gparted changes effective > permissions, so they are wrong. No, I didn't say anything about gparted. When gparted mounts it somewhere that isn't traverse proof, yes, that does allow access where it was not previously, but that's really only exposing the underlying bug that was always there: that the permissions on the files are too loose. If you are running an unpatched kernel that is vulnerable to a remote exploit and aren't connected to the network, then you don't have to worry about it, but if I plug in an Ethernet cable, it doesn't mean that the breach of security is my fault.
Bug#916260: gparted mounts partition without protection
Marc Lehmann writes: > When you recreate a file with different contents you have modified it. > Anything else is weird word twisting, and not useful in this context - it > doesn't matter how exactly I change a file, as long as I can change it > when I shouldn't be, it is a security bug. True, you can delete the file and replace it, but then it is now owned by you instead of the original owner. It's a fair argument that it amounts mostly to the same thing. > No, there are other possibilities, but that is one way, yes. Other possibilities like what? >> looser permissions, and that amounts to the same thing as just not >> keeping it mounted most of the time. > > No, these are very different things. How so? In both cases the permissions on the file itself are wrong, and you are relying other mechanisms to stop access before it gets to checking the wrong permissions. > Your question is loaded, because it presumes that the correct permissions > are somehow incorrect (a contradiction that any answer would have to > accept, which makes it impossible to answer your question). That is > not The permissions allow access that you do not wish it to. Ipso facto, the permissions are incorrect.
Bug#916260: gparted mounts partition without protection
Marc Lehmann writes: > It happens also for filesystems with correct permissions - maybe this is > the point you have problems with? > > The effective permissions for a path depend on more than just the > permissions of the file it refers to. For example, a root-only readable > file can still be changed by normal users if the directory is writable for > them. No, it can't. If the directory is writable, then the user can modify the directory, i.e. to rm the file, but they can't modify the file itself. > That means the whole access path needs to be taken into account, and > this is why the security issue is in gparted, because gparted changes > effective permissions in ways not expected by the user, by mounting it in > an insecure location. The only way it can change the effective permissions are if you normally have it mounted in a directory that uses the traverse/execute permission to restrict who can traverse it with the files inside otherwise having looser permissions, and that amounts to the same thing as just not keeping it mounted most of the time. Or I suppose you could use a filesystem namespace so that it is only mounted to the one user and not visable to the rest of the system. Either way, it begs the question: why not just set the permissions correctly instead? Come to think of it, maybe using filesystem namespaces would be a better idea than chmod()ing the /tmp mount point ( and then creating another subdirectory in which to actually mount the fs ).
Bug#916260: gparted mounts partition without protection
Nicolas Braud-Santoni writes: > The scenario at play is the following: > > 1. I am a user with some level of administrative privileges, and run gparted. > 2. I resize a partition (btrfs, in Marc's initial report), >causing it to be mounted under /tmp, with a mountpoint that's chmod 0777. > 3. Now *another user* on the same machine can access that file system, >which I unwittingly mounted and exposed. I get it, I just don't understand why you would have a filesystem around whose internal permissions were not already set up correctly but instead you relied on not mounting it to protect it. > I agree with Marc that the simplest way to negate the issue would be > for gparted to make a private, temporary directory (chmod 0700) and put > all its temporary files and mountpoints there, so they cannot be accidentally > exposed to other users. Yea, I suppose it's a simple enough change.
Bug#948710: openssh-server: Fail to upgrade "ssh.service: Unit -.mount is masked"
I brought this up on systemd-devel the other day and Lennart agreed that it is a bug in systemd that it refuses to start services that depend on masked mount units when the mount is active. He advised me to file a bug report on github, but github insisted on emailing me before allowing me to log in even though I know my login and password, and they seem to still have my no longer existing ubuntu email address, and so I am locked out. Their contact us page also does not seem to work nor have they replied to my attempts to email support@, so I am unable to file the upstream bug. He also advised that gparted should be using a bsd file lock instead of masking mount units. Curtis Gedack wasn't sure about making the change at least for the upcoming release of gparted. Perhaps after that.
Bug#883812: Gparted under Wayland
I tested the exp version under wayland and not only does it work natively now with gtk3, but even when forced to use Xwayland, it still works because it seems they finally fixed the bug with gdm and it is now properly configuring XAUTHORITY. As a result, the --enable-xhost-root workaround is no longer needed.
Bug#932138: minissdpd fails to upgrade from Stretch to Buster
The NEWS mentioned that the service is disabled by default and that if you want to enable it you can, but things will still work ( but slowly ) without it. That's fine, but the configure script then should not be trying to start it, and be surprised when it won't start ( since it's disabled ), and fail to configure as a result. Please change the configure script to either not try to start the service when it knows that it is disabled, or to ignore the failure.
Bug#928546: /etc/fstab.d
Don't forget that these days most distros are using systemd, in which case it is in charge of boot time mounts instead of util-linux's mount -a. Thus any attempt to add /etc/fstab.d would require modifying systemd, and probably udisks and probably plenty of other utilities, which is probably why it was abandoned. On the other hand, maybe something similar to what happend with /etc/resolv.conf may be a solution: replace /etc/fstab with a symlink to /run/fstab, and let systemd dynamically genereate that file based on its view of mounts. Then you'd control mount options with systemd units and /etc/fstab would just be a compatability file for other utilities like mount and udisks. john.pseudonym1 writes: > Package: util-linux > Version: 2.29.2-1 > Severity: normal > > Hi, > > As part of the hardening of an anonymity focused operating system called > Whonix, we need to add different mount options for different filesystems e.g. > hidepid=2 on /proc or noexec on /home. To make sure that a user's own fstab > configurations are not messed up, we cannot use /etc/fstab for this. > /etc/fstab.d would be the perfect thing for this but it seems that support > for it has been > [abandoned](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=663623). Will > support for this ever be brought back? If not, are there any good > alternatives? > > Best regards.
Bug#923561: parted: Incorrect optimal alignment for USB device
On 3/5/2019 5:49 PM, Kevin Locke wrote: >> md does it using the stripe size. Not sure if anything other the md or >> dm would make sense to populate the value. Well, I guess hardware raid >> drivers. > > Sounds reasonable to me. Feel free to propose it to the kernel > maintainers. I'd have to check to be sure, but I think hardware raid drivers already do this. > Documentation/ABI/testing/sysfs-block does not say "normal disks > generally leave it 0", it says "If no optimal I/O size is reported > this file contains 0." SCSI disks report an optimal I/O size via VPD. My copy says "This is rarely reported for disk drives." then mentions raid. The full description I have is: Storage devices may report an optimal I/O size, which is the device's preferred unit for sustained I/O. This is rarely reported for disk drives. For RAID arrays it is usually the stripe width or the internal track size. A properly aligned multiple of optimal_io_size is the preferred request size for workloads where sustained throughput is desired. If no optimal I/O size is reported this file contains 0. > I still think the documentation here is correct. If you disagree, > feel free to report it to the kernel maintainers. What defines "correct"? I don't think it is a question of whether it is correct, but whether it is clear and unambiguous, and whether various components have understood it the same way. I think the text is ambiguous since it specifically mentions that raid uses it to represent the stripe size, which is a hint that the intended use is for optimal alignment, despite the fact that the prescriptive text makes it sound like it does not have anything to do with alignment. After all, as a general rule, the larger IO you use, the better the performance, so if it had nothing to do with alignment, everyone should just set it to a silly large value like your USB stick does, and then it would kind of be useless, wouldn't it? > Are there cases where the optimal partition alignment is not a > multiple of the physical sector size? If so, lets consider whether > they can be worked into the sanity checking logic. If not, are there > other risks that you foresee which are not shared by util-linux and > cryptsetup, which have been using such a sanity check for years? No, there aren't, and I agree that this sanity check isn't likely to hurt anything and will fix your USB stick issue. What concerns me is that drives which are not 512e like yours will report an absurdly large optimal_io_size that *is* sector aligned, and this sanity check won't help with those. > Also, if "your USB stick" was intended to suggest that this is not a > common problem, I would disagree. I suspect it occurs on most/all > Seagate UAS drives (which share some other known problems[1]). I simply meant that yours seems to be 512e and that is the only reason it is even possible to have an optimal_io_size that is not a multiple of the physical block size. I think it may be worth starting another discussion upstream about this to clarify and perhaps have the documentation improved, but I suspect that in the end, this value is just going to remain a clusterfudge and maybe parted should only rely on it if the disk in question is an md device. Then again, that might leave out hardware raids if they use the stripe size too. Maybe a size sanity check? Anything above say, 8M or 16M maybe should be ignored? It's a shame that this value is unreliable and we have to resort to second guessing it.
Bug#923561: parted: Incorrect optimal alignment for USB device
On 3/5/2019 10:58 AM, Kevin Locke wrote: > Sounds great. How do you propose that the kernel determine the > optimal alignment? md does it using the stripe size. Not sure if anything other the md or dm would make sense to populate the value. Well, I guess hardware raid drivers. > I disagree that what you quoted says that that the md driver uses > optimal_io_size for anything, much less unconditionally. Also, since Now that I read it again, it just says raid arrays, not md specifically, so I guess that means md plus hardware raid drivers. I know from experience that md does use it that way. > the disk on which I am running parted is not a RAID array, I don't > think the documentation above says that it is anything more than > "preferred unit for sustained I/O". Yes, the first part says that, but then it goes on to say that normal disks generally leave it zero, and raid disks set it to the stripe width. >> Wait, how can optimal_io_size NOT be a multiple of the block size? > > For my disk, the logical block size is 512 bytes, the physical block > size is 4,096, opt_xfer_blocks is 65,535, so optimal_io_size is > 65,535*512=33,553,920 which is not a multiple of 4,096. I considered > advocating that the kernel check this, but decided against it. Oh, that is weird. I guess such a sanity check would fix the issue for your USB stick, but what about others? > SCSI devices can report any value (measured in logical blocks) for VPD > Optimal Transfer Length. It is not restricted to multiples of the > physical block size. For my disk, it is not, which is the cause of > the current issue. So for 512e disks basically, the optimal transfer length can be not a multiple of physical block size and foolish drives try to specify the maximum possible value in logical 512 byte sectors, and that ends up being 1 logical sector too small to align to 4k. For 512n 4kn disks, the optimal size can never not be a multiple of the sector size, so the sanity check would pass and still give you a massive alignment you don't want.
Bug#923561: parted: Incorrect optimal alignment for USB device
On 3/4/2019 5:29 PM, Kevin Locke wrote: > After a bit more research, I found that this issue has been mentioned > on linux-usb[1] and that Martin K. Petersen weighed in on the issue in > a util-linux-ng thread[2]: > > On 17 June 2015 at 01:08, Martin K. Petersen > wrote: >> There's only so much we can do about devices that report garbage. >> >> Also, the kernel only reports things. It is up to Karel to decide >> whether to sanity check the values before he uses them. > > If we are going to bring it up again, I'd like to have a specific > recommendation or request. More discussion below: It sounds like it wasn't intended to have anything to do with alignment, but since MD used it that way, parted interpreted it that way. If optimal_io_size is just that, then maybe a new variable needs to be created to expose optimal alignment? > Could you point me to the kernel documentation that mentions how the > md driver uses optimal_io_size? Documentation/ABI/testing/sysfs-block: Storage devices may report an optimal I/O size, which is the device's preferred unit for sustained I/O. This is rarely reported for disk drives. For RAID arrays it is usually the stripe width or the internal track size. > My current reading is that optimal_io_size has the same definition as > SCSI VPD Optimal Transfer Length. It has a loosely defined meaning, > but its value for any particular use is contingent on sanity checking. I'm not sure how you can sanity check it. Either it has meaning relevant to alignment or it doesn't. It sounds like it wasn't supposed to even though md used it that way. > Do you have a particular proposal for how to improve the kernel > documentation or how optimal_io_size behaves? I worked up a patch > which only uses logical_to_bytes(sdp, sdkp->opt_xfer_blocks) for > io_opt if it is a multiple of sdkp->physical_block_size, but I am not > convinced enough that it is universally applicable to advocate for it. > Any alternative suggestions? Wait, how can optimal_io_size NOT be a multiple of the block size?
Bug#923561: parted: Incorrect optimal alignment for USB device
On 3/4/2019 11:50 AM, Kevin Locke wrote: > optimal_io_size is defined in the kernel ABI[1] as "the preferred > request size for workloads where sustained throughput is desired". In > this case, I think it comes from scsi_disk.opt_xfer_blocks[2] which > comes from the VPD block limits page[3] which my disk reports as 65535 > blocks (according to sg_vpd). Yes, I was looking over the definition earlier in the kernel documentation, and it seems to me that part of the definition indicates it is simply an optimal size to transfer in, and has nothing to do with alignment. But parted treats it as having to do with alignment, because the same kernel documentation mentions that is what the md driver uses the field for. > The definition seems reasonable, but it would not surprise me if 65535 > were bogus. I am not familiar enough with USB+UAS to know if this > might be an optimal size for the protocols involved. I can raise the > issue on linux-scsi/linux-usb. I think the issue needs raised in a few places; I just couldn't decide where. > However, whether or not this is changed in the kernel, I would argue > it should be handled in parted. Both to support previous+current > kernels and because I think the optimal_io_size ABI definition allows > optimal_io_size which is not a multiple of minimum_io_size for > transports where that truly is the case. Unfortunately, that means parted needs to simply ignore the value of optimal io size as totally meaningless garbage, and I don't much like the thought of that. If parted has always been wrong and the intended meaning of the kernel parameter has never had anything to do with alignment, then yes, parted needs to ignore it because it read meaning into it that was never intended. But if it is supposed to have something to do with optimal alignment, then md is right and usb is wrong, and usb needs to be fixed.
Bug#923561: parted: Incorrect optimal alignment for USB device
On 3/1/2019 6:04 PM, Kevin Locke wrote: > Presumably the error occurs because parted is using the optimal_io_size > for alignment. Since optimal_io_size is based on USB constraints rather > than disk constraints, it does not seem suitable for partition layout. > > I would suggest ignoring optimal_io_size if it is not a multiple of > minimum_io_size, as done by cryptsetup[1]. Alternatively, 33553920 > could be ignored specifically, since it seems common for USB disks. > > This issue has been discussed elsewhere: > https://www.saout.de/pipermail/dm-crypt/2016-January/004934.html > https://bugzilla.redhat.com/show_bug.cgi?id=1513820 > https://unix.stackexchange.com/q/340484 > https://linux-blog.anracom.com/2018/12/03/linux-ssd-partition-alignment-problems-with-external-usb-to-sata-controllers-i/ Interesting. It sounds like USB and MD are using optimal_io_size in fundamentally incompatible ways. The question then is: is USB doing the wrong thing ( and should be fixed ), or is the very definition of optimal_io_size fundamentally broken?
Bug#916260: gparted mounts partition without protection
On 12/12/2018 11:59 PM, Marc Lehmann wrote: > As you say, there are several ways, some where the user can choose to > make the files accessible and some where she can choose to not make them > available. I'm not sure what you mean by this. > The point is that the user should be in control of whether files are > accessible to other users or not. They are; if you don't want files to be accessible to someone then set up the permissions so they don't have access and/or don't give them access to mount the volume and/or run programs like gparted as root. > gparted doesn't allow that choice, and what's worse, it's not even obvious > that it potentially makes files available that normally wouldn't. Resizing a > filesystem should not expose files to other users that normally wouldn't. If you can run gparted, then you can mount the filesystem at will. While it isn't immediately obvious that resizing a btrfs filesystem will cause it to be mounted temporarily, it isn't getting you any more access than you already had. Also your typical desktop environment these days lets users click on unmounted volumes and they will auto mount them, which brings us back to setting the permissions correctly inside the volume. > Your argument could be applied to users homedirectories as well - if > gparted temporarily did "chmod 777 ~" it wouldn't be a bug according to > your logic as well. No, it wouldn't. Your argument is more like saying my home directory is 777 but I normally don't keep it mounted so nobody can access it, so now it is a problem that anyone can click on the volume to mount it and then have full access to my files. The problem is the permissions, not the mounting. > Or maybe I misunderstood you, but it seems you are saying "since the user > could choose to make files available to other users, it's not a bug that > gparted silently does it without asking or notifying the user that it would > do so". No; I'm saying that if you don't want the files available then set the permissions correctly, and if you don't want users to be able to mount the filesystem, then don't let them run gparted or mount filesystems using other tools. signature.asc Description: OpenPGP digital signature
Bug#916260: gparted mounts partition without protection
On 12/12/2018 3:50 AM, Marc Lehmann wrote: > Package: gparted > Version: 0.25.0-1+b1 > Severity: normal > > Dear Maintainer, > > for some operations, gparted mounts partitions under /tmp/gparted-XX > without any protection > against access. This makes these partitions potentially accessible to other > users on the system while > the operation runs. > >* What led up to the situation? > > Resizing a btrfs partition. > >* What was the outcome of this action? > > While resizing, the partion was mounted under /tmp/gparted-BSeLY6, > accessible to all users, potentially allowing other users to read or write > the data: I'm not sure this can be considered a bug. There are several ways the user could have the filesystem mounted in a non temporary manner and if the permissions of the filesystem allow them access, then they can access it. signature.asc Description: OpenPGP digital signature
Bug#906136: closed by Bastien ROUCARIES (sensible-browser doesn't seem to have a user local way of changing it)
reopen 906136 thanks > hi, > > You could set BROWSER variable... > > could you retest That's not a reason to close. After testing, it appears this does work, however it is not documented in the man page. It should be. signature.asc Description: OpenPGP digital signature
Bug#905528: Bug #905528,mount: nofail
On 9/16/2018 4:40 PM, Andreas Henriksson wrote: > I don't think it's util-linux place to document how systemd (or any > other similar system) works. Certainly not as a downstream debian patch. > > In my opinion this is basically a misdirected bug report that I'd > suggest tag wontfix and close. Ofcourse if someone comes up with > a suggested wording and submits it to the upstream mailing list > chances are probably high that something fruitful will come out of > that. The util-linux man page for mount has always mentioned peculiarities of the various other mount helpers, even though they aren't part of util-linux. I'm not sure whether that has been a debian deviation, but if you think it better to get upstream to adopt such a change first, then the bug should be marked as upstream,forwarded ( and forward the issue to upstream ), not wontfix and closed.
Bug#907194: su: yields breakage without "-", not properly documented
On 9/16/2018 4:30 PM, Andreas Henriksson wrote: > If you really want to help, I think the first best step would be > to lobby the debian installer team to make the 'root password' prompt > only show up in 'expert level' installs and thus giving everyone > sudo installed and setup by default (as far too few users are aware > of that they'll get today by leaving the root password prompt blank). I've been wondering for a decade now why debian hasn't done this. Wow, I didn't realize you could leave the prompt blank and it would just install sudo.
Bug#887225: gparted should also suggest e2fsprogs
Control: reopen -1 thanks On 8/29/2018 3:15 AM, Daniel Vacek wrote: > Package: gparted > Version: 0.32.0-1 > Followup-For: Bug #887225 > > I only see udftools added to suggests but e2fsprogs is still missing. What the hell? I swear I added it. No idea how that got lost. signature.asc Description: OpenPGP digital signature
Bug#905528: Bug #905528,mount: nofail
reopen 905528 reassign 905528 util-linux retitle 905528 nofail flag description misleading thanks I misunderstood the description before. I interpreted it as using nofail still causes boot failure. After offline discussion with the reporter, he was saying that the man page for mount and fstab both say that the nofail flag means "do not report errors for this device if it does not exist". This is true for mount as it simply reports an error ( or not ) and moves on. However, since systemd is doing the mounting these days, its behavior without nofail is not to simply report an error and move on, but to hold up the boot process waiting for the device to appear. It would be nice if at least the fstab man page would note the systemd behavior so it does not make it sound like the only thing that will happen if you don't use nofail is to get an error message. signature.asc Description: OpenPGP digital signature
Bug#906136: sensible-browser doesn't seem to have a user local way of changing it
Package: sensible-utils Version: 0.0.12 Unlike for editor and pager, sensible-browser does not appear to have an environment variable for a user to choose their sensible browser ( as opposed to the admin making system wide symlink changes ). signature.asc Description: OpenPGP digital signature
Bug#905528: mount: nofail
sysvinit called mount -a to handle mounting devices at boot. Unless you are still refusing to move to systemd, mount is on longer responsible for this so the problem must be in systemd. On 8/5/2018 11:44 AM, Seamus de Mora wrote: > Package: mount > Version: 2.29.2-1+deb9u1 > Severity: normal > > Dear Maintainer, > > I have modified the file at `/etc/fstab` to add instructions to `mount` for > mounting a "USB thumb drive" (LABEL=SANDISK16GB); please see the file > contents below. Note the use of the `nofail` option. When I omit this > option, and that USB thumb drive is not plugged in, my system will no > longer complete the boot process. This behavior is contrary to the signature.asc Description: OpenPGP digital signature
Bug#902224: parted: bogus rounding of exact sizes
On 6/23/2018 11:12 AM, Adam Borowski wrote: > Start? 100mib > End? 100% > Warning: You requested a partition from 100MiB to 14772MiB (sectors > 204800..30253055). > The closest location we can manage is 100MiB to 14772MiB (sectors > 204801..30253055). This is because the first partition includes sector 204800 so the closest that can be allocated to the new partition is the next sector. This behavior has been changed upstream already by the following commit, which was released in parted 3.1, and so should be in debian, so I'm not sure why you are seeing it: commit 961abca12d1766264651dbe08284aeec3c0396c6 Author: Petr Uzel Date: Sat Oct 22 15:22:09 2011 +0200 parted: mkpart: DWIM for IEC ending sector numbers like 2MiB and 9GiB Before, if the user specified start and end in mkpart command using IEC units, parted created a partition that starts and ends exactly on these positions. With such behavior, it is impossible to create partitions as follows: 1MiB-2MiB, 2MiB-3MiB - parted would complain that it cannot create the second partition, because the first one occupied sectors 2048-4096 and the second one sectors 4096-3072, so they would overlap at sector 4096. With this patch, if the user uses IEC units to specify end of the partition, parted creates the partition which ends one sector before the specified position. See also https://lists.gnu.org/archive/html/bug-parted/2011-10/msg9.html * parted/ui.c (command_line_get_sector): Add parameter to retrieve raw input from user. * parted/ui.h (command_line_get_sector): Adjust prototype of function. * parted/parted.c (_adjust_end_if_iec): New function. (_strip_trailing_spaces): New function. (_string_ends_with_iec_unit): New function. (do_mkpart): Call _adjust_end_if_iec(). Use new parameter of command_line_get_sector function. (do_rescue): Adjust call to command_line_get_sector. * bootstrap.conf (gnulib_modules): Add these: c-ctype, c-strcase. * tests/t0207-IEC-binary-notation.sh: Adjust to new semantics. * NEWS: Mention the changed behavior. Notable adjustments: - s/isspace/c_isblank/ so that parsing is locale-independent - avoid an array-bounds error: * parted/parted.c (_strip_trailing_spaces): Don't deref str[-1] for an empty string. signature.asc Description: OpenPGP digital signature
Bug#901887: build-depend should not list xtem
On 06/19/2018 05:08 PM, Jeremy Bicha wrote: > The xterm dependency is only used for the build tests and it's marked > correctly for that. So the test suite does not work on servers without a gui? And why doesn't it seem to run the test suite or fail without xterm?
Bug#901887: build-depend should not list xtem
Package: glib2.0 Version: 2.56.1-2 I noticed while trying to build glib that it claims to build-depend on xterm, which is insane; no package should require xterm to build. I forced it to build anyway without xterm installed, and it built fine, so this dependency should be removed. signature.asc Description: OpenPGP digital signature
Bug#822367: partman should check and warn if missing bios_grub partition
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Package: partman-partitioning Version: 111 When installing to a GPT partitioned disk in bios mode, a bios_grub partition is required to install grub. Partman should warn the user of this if they do not have one. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCgAGBQJXG+AXAAoJEBB5UWFcu6UW2v8H/i/cK7EDTjQzijzf20V+wvLJ Z2bnCejkzvLfd/58lZ6ECHj/Vlp4Ab3ooyzrIsOr+fmLXeaPdD/hiE8/7NrHnoF8 K0jiXvfNC5GE6CLbhGb5LteArXPLIabAZboMklkPwlTobI55Xp/A3b4wzIQvu8JW Ar4LMUOhPC6AF9W9YuBYB8AcfI02O0cQf5zd75qNtNJg9NZ3PuZ4wVwqGhYHH3zl PZJOxCWWId/0gjhSf++3xOoJVLjYJVUUAc9Iry/pm0Usj57sofKx8ZhWM5TdCaGP eD+9oWshHn+MfIWMRRNHstWEriQAvJoBgeXr92DlYcc1856F9TqiqMmaYNIulF4= =wrti -END PGP SIGNATURE-
Bug#819488: gparted crash with a libparted backtrace
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04/11/2016 02:13 PM, Mattia Rizzolo wrote: > On Mon, Apr 11, 2016 at 11:52:32AM -0600, Curtis Gedak wrote: >> If I recall correctly, libparted was not able to handle when >> there was only one unallocated sector between logical partitions >> (it expects at least two). I believe that is exactly it Curtis. > well, that's really not a reason to crash like that! ;) For the last 3 decades, it has not been a problem since every disk partitioner has worked this way. I have sen a few bug reports about this recently though, and the others have reported using something called Easeus disk partitioning software. Have you used this? It would be good to confirm this is the source of the problem and I'll see if I can't fix parted to handle it. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCgAGBQJXDEi5AAoJEBB5UWFcu6UW1cgH/2ReOLJAbvtm6ZCVLd+S8VFG /T42BG64dbtp5PEEeLt+fE7hYRQkTb+Kmnv5YEApJ39Sucihi3yx2EWUqwxmEZ9Y QElVEbIBB82GUJtGEIhgOiCZKfSvqyDocOZ6Gm4n8ZQScOEzKMeNCb48F1mTBc5i CVlCS1ynlfa0IoYqSx4EwH2K5Q6CNQhQiOrJtvGkiXryp7GkVwt37lrOpuR0z+D0 jThfBq7ULE7YPUXEgIwquBpxUWaHvU2eQdSKAhS9mQ4DvoAyHkn+YCWy8z5yjkE8 iY6uCMw70mtnG0nTF+m52TBbRb4KTrRno4MuF+2OMFttTyLVyblOFCm8bp08/7Y= =wouG -END PGP SIGNATURE-
Bug#807323: [Pkg-utopia-maintainers] Bug#807323: Bug#807323: gparted needs policykit-1 but its neither in depends or recommends
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 12/22/2015 09:19 PM, Michael Biebl wrote: >> Why? The BTS forwards the message automatically doesn't it? >> > No it doesn't. Sigh... that's another absurd failling in debian bts that requires constant workarounds... added to my list. > And I would appreciate if you would stop reopening bug reports for > packages you don't maintain. The entire community would appreciate it if you would stop closing valid, or likely valid bug reports without a good explanation. The only thing you have suggested thus far ( after closing the bug several times ) that is even a possible candidate for a legitimate reason to do so is the use of policykit-1 from experimental with an otherwise sid based system. Until this has been confirmed, or unless it is a known error that you can be reasonably confident is the case, and you clearly describe that is what the user has done wrong, it is inappropriate to dismissively close the bug report out of hand. That said, I have managed to test your hypothesis and confirmed that indeed, this does result from doing what you suggest, and that is why I will no longer reopen this bug report. It is now up to Shirish to deny that he did install policykit-1 from experimental on an otherwise unstable/testing system and if not, reopen the bug. Coming to this conclusion should not have taken several rounds of closing and reopening the bug, but rather is something you should have clearly spelled out when closing the bug in the first place so that Shrish could have simply said "oh yea, my bad" and let the matter rest, rather than contacting me privately wondering why his report had been summarily dismissed. Please bear this in mind when closing bug reports in the future so that such confusion can be avoided. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCgAGBQJWe28EAAoJEBB5UWFcu6UWeqoH+wYdRutwix8qyiGEpLf25iSF CllrkhLQ6q2LoUoomIQ4b04CQmHKC/g2D8qnRPnDnh4dzLZYcDdyqTSTTisxMJxW UfEY0reTO22GhbqQwGABgzpSL6LJ8p17kNldJIs9j0As4CVajs155LxCAnOW/ddw B2DzPGJ0INThIVAGESxlqJzc+5r1XyGdZT0CM++DDGG1rVGlxWs4O2RDNb38NQyQ aniSJ/PTSvUUXJu8ejHUo+hwm42PeqjvVIVzsGaXGrIovU+t590g3+49IAf+788f WKf0wG6IkbBrtxGI4fOMLZwitX1NqmgPRCPHVaHLIS3ESQzGxraUgXivQD+3UTc= =CGXU -END PGP SIGNATURE-
Bug#807323: [Pkg-utopia-maintainers] Bug#807323: gparted needs policykit-1 but its neither in depends or recommends
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Control: reopen -1 On 12/22/2015 08:11 PM, Michael Biebl wrote: > First, please CC the package when you re-assign a bug report. Why? The BTS forwards the message automatically doesn't it? > Second, please don't use inflated severities. Third, this bug > report was titled "Missing depends or recommends on policykit-1" > which is highly misleading and not an issue for udisks2. > > > All in all, a badly done bug report. Enough reason to close it and > let the bug reporter file a new one. That is entirely incorrect; you can not just close a bug and expect the user to try again and do better without knowing what is wrong. If there is something wrong, you fix it. If the title is wrong, you retitle it. If you disagree with the severity, then change it. If it is assigned to the wrong package, you reassign it. > My guess is, and I can only guess since I don't have any version > information for neither udisks2 nor policykit-1, is that the bug > reporter has policykit-1 from experimental installed. That is a good thing to ask the user to check rather than assume and close. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCgAGBQJWegGOAAoJEBB5UWFcu6UWt0gH/jTdXjaQ3R8HgGZywneufMZC /cpUwvv38myQOQG1ozHqO2mxIo60eJicAj/g7mlsLaiCaVO2/IBoudqSD0yQn7hf rZhRI4v1QnsEfy3C7brysr7jT4v9Z3pSqum/zh1HUCY+ZqU274wFYipPAHchzeQC rAHLgmltBCPYLjlEPK22fEVPoPz3ySX0ORM6jgGmY+RuywAFh1OeqCIwMSBZdoAS G4mCpU+cUVSOHabHVoHemJnyAuAijAVyFXEuM3++A/ccdh4NcNeCv4PWPTPQVpTB g5WJH7MkmooL2WhCXmQznuPz408DPb+voA4OCMF5GwKL5ufajhgrjh67EhgBKuU= =NT+V -END PGP SIGNATURE-
Bug#808793: test, please ignore
Package: general This is a test of the BTS, please ignore.
Bug#807323: gparted needs policykit-1 but its neither in depends or recommends
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Control: reopen -1 Control: affects -1 gparted On Tue, 22 Dec 2015 19:29:39 +0530 =?UTF-> > And that's why udisks2 has a Recommends policykit-1. >> >> Closing the bug report. >> >> Not installing recommends means you need to know what you are >> doing. Closing is not appropriate. If udisks2 functions except for udisks2-inhibit, then gparted needs the hard depends on policykit-1. Are you saying that the only thing udisks2 needs policykit-1 for is inhibit? I would think it needs it for everything. >> > > Miichael, > > Did you read the whole bug-report. I have installed it. It is > there. > > $] aptitude search policykit-1 i A policykit-1 - framework for > managing administrative policies and privileges > > The error is even after it is installed. Then the reason for closing is certainly incorrect. Maybe the real problem is not policykit-1 then but something unknown? -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCgAGBQJWefGKAAoJEBB5UWFcu6UWC1YH+gPMU3InktrfuM6RzrW5tRqq +tXOE+DUnjzqLeob8HVbrXJt01TDXzf3876oYC6c1Sx1M1+MzEcfk7CQCNCHimYV QLHKpAQgI/9Y+RJfGb8yki1t3yXkafC75Q62gjx9sVTGXKbZ8y/J5EPhTaB/8ypZ bWn6dsGNUDiskJl464DeTAhoqKpBeGKrU95/LmPd8WLXYIT5tMgy/qEi9U1SOklb ilAzp42byKNUIWfuYEaxCwlpfHu2GU1qruzD31sbmd7eWIygFxUhPmBBadAEuFmK XB1Q7eYlY8kyINKA2bZlg2MNNMWCeLZOxBMl9zoxyqLIwg2oHRILzqbDQq3wkO4= =0ccK -END PGP SIGNATURE-
Bug#808380: mount: unknown filesystem type 'vfat'
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 12/22/2015 02:47 PM, Sven Joachim wrote:
> Both the original report ("Kernel: Linux 3.16.0-4-amd64 (SMP w/4
> CPU cores)") and the followup in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808380#25 show
> that Jacob had already running 3.16.0-4. If he had been using
> 3.16.0-3, the problem would not have shown up since modprobe does
> not try to load 3.16.0-4 modules into a 3.16.0-3 kernel.
That's what I've been saying.
> Debian does not do this, to avoid uncontrolled proliferation of
> kernels. In fact, the 3.16 kernel has been at the 3.16.0-4 ABI for
> over a year (the last ABI bump was in November 2014, version
> 3.16.7-1).
If that is the case, then they screwed up and broke the ABI without
bumping its revision and the bug should be reopened and reassigned to
linux so they know they broke the ABI and need to bump the revision.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBCgAGBQJWefMMAAoJEBB5UWFcu6UWhvMH/iVmGGTEOnfmbgpFQRt58qr/
R03ZuXt7eqQgtkwnBrKG7JmzhByv5u4rmn1oxPHf6E+6PPU1UeRMkEpVVfkEKbPd
68PtdHeU7gpf9DdmrMjR0qYu5xmZ9yvpBdJrV7pdu1zyXiOyxBlBhrLV4liiCggh
+mnr0wxTt9GAI7rsp2D/DJtnQnX9b7/SjJJHr9HG/5qxCRg0P1/yNHmZ37tOnsX1
nZaXtQOWtJZOobEzD7Fz5dvaHn/DY021aIRNsgikKfXsOuAt5H8TFJDO49mSw2/a
YEfEgtfpEVLw7TwSWy7QUn8dr8KTOc/iAB1YxLQ3MGioR5FliGvSlAPyxFkZDLs=
=zdp3
-END PGP SIGNATURE-
Bug#807323: gparted needs policykit-1 but its neither in depends or recommends
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Control: reassign -1 udisks2 On 12/21/2015 03:54 PM, shirish शिरीष wrote: > Yup, > > get it here - > > [$] sudo /usr/lib/udisks2/udisks2-inhibit true [sudo] password for > shirish: /var/lib/polkit-1/localauthority/90-mandatory.d does not > exist. Please install policykit-1 -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCgAGBQJWeJOJAAoJEBB5UWFcu6UWNPQH/i2COnhWV8Wj/lGJO4f5AKE+ 2U9daaLlqKN+krA/ABUqtoMx3O1d2YIloh33OxgKnLjFGoQMCXyNua/qF670EiXk fyqDnDAaoDHRgP98od3MK0A+CwxDkyu2mepYbFBzgGv9h4HG6RbBPuG9Z9gtFebK tFLeFSGsoezAF59qT7+j3j2srVmYu0e3TdMV9cvTS5t0T1gqyIHfmf0b/6bk6Oq5 SwTdt5ZIbK/LwK3jYdKsDNM8tOFacMkSWoIhRoxmEHT6xKA5/QDHVJMkZ7ckZCHj s/wtau8kDtRYYuhSZmH8mfzTxyKExIaiq7xakLsJJ5K0PqDf5lQs53F7tbeMb14= =/j5W -END PGP SIGNATURE-
Bug#808380: mount: unknown filesystem type 'vfat'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 12/21/2015 05:29 PM, Sven Joachim wrote: > Wrong, both the old and the new kernel provide their modules in > /lib/modules/3.16.0-4-amd64. Jacob upgraded the > linux-image-3.16.0-4-amd64 package, he did no install a new > package. No... if the new kernel is 3.16.0-4, then the old one was 3.16.0-3. This is the reason why debian adds the extra digit to the version number and bumps it each time the kernel is updated. This goes out the window of course, if you build your own patched kernel and don't bump the version number. It it weren't for this, then you would not be able to choose to boot into the previous kernel version after an upgrade, as it would try to use the modules from the new version and fail. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCgAGBQJWeJURAAoJEBB5UWFcu6UWnbEH/RIk0ftRxlbI55/wLf3XGS+i hYSAjRnxcRYOG0FiOcgbJ+b5KcRPmtMhz1CDVYKQkmt3iIYwYuaJGBEpEk0h34dL MUFYRitWUM1FM9No4EHzeAHlx83C0YtxiBqofJMp4r5ugAzoXwRNgjSslx9AM+i4 i5ZORZkoB8UAyfbCfWhggeK4Wn2YUm310SQDLMiFdjcN/PlxGqXKKdhdabfisdjs nqsIthELcJDphGW6pRhtBoUWpzx7nryXR37dj5l87BZcjJCUAwgRiEfCb3TVU3pf 7aByZpy/6a85aCbWX/QBT/9N1i2GN3GPiDDiQsVhHcu9wVCGtXes62jZuyM/vgE= =NN+Z -END PGP SIGNATURE-
Bug#808380: mount: unknown filesystem type 'vfat'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 12/19/2015 06:11 AM, Jacob Sparre Andersen wrote: > Package: mount Version: 2.25.2-6 Severity: important > > Dear Maintainer, > > My system does not allow me to mount 'vfat' formatted devices any > more: > > # LANG=C mount -t vfat /dev/sdc1 /media/rgncm ; echo $? mount: > unknown filesystem type 'vfat' 32 # Please post the output of `modinfo vfat` and the last few lines of `dmesg` after getting this error. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCgAGBQJWdfVUAAoJEBB5UWFcu6UW8gkH/2aHfKyhdsBLeHlbjq4vA0cn /FmjRbH83RMgISc9fvH/2p0OZRuMQOKTpYG7aRVIAp5nUcknNVVlOlhSaki+rLth Fw00BeTXAyov3fht7PYl4uREWBdRrpClWFu3Q+r6O/ZgGTD9Nt6BAutM+gDmNh2s LZjc/e2b0nPW/LYk4c0Fh1RfKOl/u7INNpaNgXmzlKfUKCLn4FRiAEPX4Xkz8ODu RTRb4DY529mbpKD6vUiZI+aT9J6+Pseg50RG30bN2QEIIibzRGO7wzzZNjLs08hv LSUJdrGAnEdwXvVrVS+XWqidxZhKn8uFI2KjddqvkKni+EamihyOiyJ1QEgUw6A= =JD71 -END PGP SIGNATURE-
Bug#808085: util-linux: cfdisk creates gpt partition tables which are not recognized in Windows
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 12/15/2015 04:11 PM, Hannes Diethelm wrote: > You may notice the difference in "First usable sector is" which is > 2048 or 34. I think you need to report this bug to Microsoft as it is perfectly valid for a GPT to designate sector 2048 ( or any other sector that does not conflict with reserved areas ) as the first usable sector. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCgAGBQJWcMi3AAoJEBB5UWFcu6UWJZUIAJ7tX17Kmp1iDVaCbBEdRtOa 6F+wZF+BP+plBgzx+F9Z8XhCgv5nhzV2fSCLLPQqmJNJBLGnWYZ9MwvaZ3Mrekts NWOAfNWTe9zUXLRxcK6fvxYQ2/suBvyPNXba60FabPai5cmOuWRK8afoDGki3eW/ jqWRv2jBJ+1M7im0twvLSyc+6ZnQNA4xIt38d1RQ+2g3Qw47v9cQEyu/lDmFy+o3 QjZ/HGWTX7NFsYDw1sIqoqdjo3otmdlkCKzcWyz300PCzMPksJqNz0CigsXQg4XX Rp6UBFvkkRCL1sXe7/vdo9F11C3rWH4gGz45/ZTSHnkvGkkFlWN8jHfS0oHRPUY= =mlg0 -END PGP SIGNATURE-
Bug#807323: gparted needs policykit-1 but its neither in depends or recommends
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 12/08/2015 04:49 AM, shirish शिरीष wrote: > You would have to share the whole command, because I'm not so > familiar with udisks2-inhibit. I tried to see if there was a > manpage or something but came up nada :( /usr/lib/udisks2/udisks2-inhibit true -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCgAGBQJWbLXMAAoJEBB5UWFcu6UWbsAH/ikeM8MRBYcdyW1uo9/mDVbH lOzpAibZpxJt3TvsXhcVWVeH2X3Q2yzr6ksJkMAxqJLz/NMPAiKk97Y6/TpioZxc HzfGTfZMsP3ScLmHNELNwzV0/7OCBd4zt9ZGWHDC+oI6li140tp7riCteoRe2DGl iZ+q1S0f4oTmHX656oh2lTSJLbR8qnvxnndwp44vbWlxwJvlTKYhWmhQTomnpYO7 ZPcTDuZU3xwg+7hTvytkBY3uABJ/sx+RDraDORkULtkYj97tfPFzX/ffMpHLWDlN w/HfZQeW8YHxEtu7g1ikzmhB3dv6NQKDvVgcaDG3nh+SEJ4O4xGO9cUp/gGD5mo= =BWih -END PGP SIGNATURE-
Bug#807323: gparted needs policykit-1 but its neither in depends or recommends
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 12/07/2015 11:57 AM, shirish शिरीष wrote: > Yup, have udisks2 installed. Just to confirm, can you run /usr/lib/udisks2/udisks2-inhibit and verify that you get that error? -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCgAGBQJWZiC8AAoJEBB5UWFcu6UWdjoH/R9bl1ScxaDvNw0dAw5hYTjQ xVOJ/zbk9DiC11H4xrPC2sLCKlomQnP9Vd7OFbVgX7tOZs0ANly270/VuB1nzqlv AtfkOy1NEyoAuUXvLPh8CR/kV4a81qFej2wuh+PuyJuUyvBy4/pcSLkcWBvYCkQD cQZzzXFtxE44u7M3tWr3odYWcg0S7vduUVg12GmnB6yqZYTIVFmjv5FUo/S8IXFW Sw8WLE3Vzl/m8lLKjeh9Xk3whdcAoLWVpTUC5zbC5pCUw2/qGBUrEwR6hbYWDbim 9FSAnBHydoE8L+cDEh8mOl1IHLoqnWp7JdF0JWWFSZ58qFfAe6iGxGFU12x0xUQ= =t2mk -END PGP SIGNATURE-
Bug#789950: fixed upstream
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Sounds like this needs to be reassigned to systemd; it should just
pass the flag.
On 12/01/2015 05:35 PM, Kevin Locke wrote:
> Hello util-linux Maintainers,
>
> Although this bug has been closed for a few months, I just
> encountered the issue on one of my systems and would like to
> discuss the solution a bit. Although sulogin supports the --force
> option to allow passwordless root login (so the util-linux part of
> this issue may be fixed) the issue still appears to be present for
> users.
>
> If a user chooses to disable the root account when prompted during
> installation, it appears that they are still unable to use sulogin
> for emergency/rescue boot (from the kernel command-line) or when
> fsck fails, since --force is not passed to sulogin by
> /lib/systemd/system/{console-shell,emergency,rescue}.service (from
> systemd) and /etc/init.d/checkroot.sh (from initscripts) and
> presumably others. This can be particularly problematic since it
> may be difficult for users to add a root password when they are
> first presented with this problem by whatever issue necessitated a
> recovery shell.
>
> Is there a way that we can avoid booby-trapping systems in this
> way? This could be done by prompting users about enabling
> passwordless root login once they have opted to disable the root
> account (although this would require coordination across packages
> calling sulogin). Alternatively, although less conveniently for
> users, by documenting the files which need to be edited to add
> "--force" and/or adding a warning to the installer prompt for
> disabling the root account so users know that their systems will be
> broken in this way.
>
> Thanks for considering!
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBCgAGBQJWXkoXAAoJEBB5UWFcu6UW8ZcIAKQxWTeDrYx2ZHe4cpg8ji3a
uBpXKcgghWFtte+6tS2J/waNZheQ72mUuoO3fvdGYBksdI2qJZJxCH8bJ96iyNP6
SOCqEfslMc5lHgJ0W9a3d2QCJe9kKM69iR4nwZAiR9d5OtZRi33jp3GsuYOqS/p9
hcQN975zuZdz9aB9vGxWMyrYwOiWQ7wyc8gu/gt8y3qEfwYU7Fm5s7kyYrQEn1ek
8HcU7WADz0KkCzrUFVgnwbF5lxpyKvUBLkrNvsjTCgC4o9qEhVw370xsEWoxkFj4
xQuzFe55Z1JXfS0ubVupp+qS5fss6P0VhpbLsAVTw6Yl+UU6G44Wtd90IlDXpO8=
=VBp9
-END PGP SIGNATURE-
Bug#806496: ramsize/rdev/rootflags/vidmode prematurely removed from util-linux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 11/27/2015 05:01 PM, Elliott Mitchell wrote: > Package: util-linux Version: 2.20.1-5.3 > > Sorry, I hate to have to report it, but as of 4.2 the x86 (both > ia32 and amd64) Linux kernel still supports the features > manipulated by these commands. Until the Linux kernel removes > these features, removal of the commands is quite premature. I'm > cringing at having to report it, but under the right circumstances > they're still handy to have. Seriously? These tools were only useful for booting linux directly from floppy disk with no boot loader, which went out of style what? 15 years ago? The last time I used this must have been 1998 or so. I don't think I have *seen* a floppy drive in 10 years. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCgAGBQJWWh8WAAoJEBB5UWFcu6UWTJMIAJ/7fhy9DwLvlDg5bCmc8i25 vKF4P+KS3/1T1mM8bMRrSIsyih3iU4iQ0YdwrTMwB0Pjc8jiv5WXhHGUsYLOeVIK mtpkk5ditD6riBGkh7jAVtSbtAZiO7gzJaKJK155WjW2czvVxjWU9UiNCrSUwEP9 Tl9XqQ550iIVaot5by89W//3sVm+MX16s3NAmnPcMigCAhMPwnqF//d7liYcoKPa Kk52thn0JDh1/n0xTfjoZ2WIKNHmdynt+weuwENqP9W4tyV9j/3yl/CrxfEsbNP6 v0MtHm6YxYvphlnmmKiqgZl0RTxjHofEnJY9sIWzVrOOuS+BUTAcar9Xo7kVtnc= =YImB -END PGP SIGNATURE-
Bug#806180: Mouse does not work in qemu
On 11/26/2015 02:44 AM, Julien Cristau wrote: > Please provide logs when filing X bugs. Here you go. [12.836] X.Org X Server 1.16.4 Release Date: 2014-12-20 [12.836] X Protocol Version 11, Revision 0 [12.836] Build Operating System: Linux 3.16.0-4-amd64 x86_64 Debian [12.836] Current Operating System: Linux debian 3.10-2-amd64 #1 SMP Debian 3.10.5-1 (2013-08-07) x86_64 [12.836] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.10-2-amd64 root=UUID=253233d1-05c3-44d8-aa3f-806959b574d0 ro quiet [12.836] Build Date: 11 February 2015 12:32:02AM [12.836] xorg-server 2:1.16.4-1 (http://www.debian.org/support) [12.836] Current version of pixman: 0.32.6 [12.836] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [12.836] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [12.836] (==) Log file: "/var/log/Xorg.0.log", Time: Mon Nov 23 19:08:54 2015 [12.836] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [12.862] (==) No Layout section. Using the first Screen section. [12.862] (==) No screen section available. Using defaults. [12.862] (**) |-->Screen "Default Screen Section" (0) [12.862] (**) | |-->Monitor "" [12.871] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [12.871] (==) Automatically adding devices [12.871] (==) Automatically enabling devices [12.871] (==) Automatically adding GPU devices [12.871] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [12.871] Entry deleted from font path. [12.871] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, built-ins [12.871] (==) ModulePath set to "/usr/lib/xorg/modules" [12.871] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [12.872] (II) Loader magic: 0x7f943e25ad80 [12.872] (II) Module ABI versions: [12.872] X.Org ANSI C Emulation: 0.4 [12.872] X.Org Video Driver: 18.0 [12.872] X.Org XInput driver : 21.0 [12.872] X.Org Server Extension : 8.0 [12.874] (--) PCI:*(0:0:2:0) 1b36:0100:1af4:1100 rev 4, Mem @ 0xf400/67108864, 0xf800/67108864, 0xfc054000/8192, I/O @ 0xc100/32, BIOS @ 0x/65536 [12.875] (II) LoadModule: "glx" [12.875] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [13.021] (II) Module glx: vendor="X.Org Foundation" [13.021] compiled for 1.16.4, module version = 1.0.0 [13.021] ABI class: X.Org Server Extension, version 8.0 [13.021] (==) AIGLX enabled [13.021] (==) Matched qxl as autoconfigured driver 0 [13.021] (==) Matched modesetting as autoconfigured driver 1 [13.021] (==) Matched fbdev as autoconfigured driver 2 [13.021] (==) Matched vesa as autoconfigured driver 3 [13.021] (==) Assigned the driver to the xf86ConfigLayout [13.021] (II) LoadModule: "qxl" [13.021] (II) Loading /usr/lib/xorg/modules/drivers/qxl_drv.so [13.039] (II) Module qxl: vendor="X.Org Foundation" [13.039] compiled for 1.15.99.904, module version = 0.1.1 [13.039] Module class: X.Org Video Driver [13.039] ABI class: X.Org Video Driver, version 18.0 [13.039] (II) LoadModule: "modesetting" [13.039] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so [13.043] (II) Module modesetting: vendor="X.Org Foundation" [13.043] compiled for 1.16.4, module version = 0.9.0 [13.043] Module class: X.Org Video Driver [13.043] ABI class: X.Org Video Driver, version 18.0 [13.043] (II) LoadModule: "fbdev" [13.043] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so [13.048] (II) Module fbdev: vendor="X.Org Foundation" [13.048] compiled for 1.15.99.904, module version = 0.4.4 [13.048] Module class: X.Org Video Driver [13.048] ABI class: X.Org Video Driver, version 18.0 [13.048] (II) LoadModule: "vesa" [13.049] (II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so [13.058] (II) Module vesa: vendor="X.Org Foundation" [13.058] compiled for 1.15.99.904, module version = 2.3.3 [13.058] Module class: X.Org Video Driver [13.058] ABI class: X.Org Video Driver, version 18.0 [13.058] (II) qxl: Driver for QXL virtual graphics: QXL 1 [13.058] (II) modesetting: Driver for Modesetting Kernel Drivers: kms [13.058] (II) FBDEV: driver for framebuffer: fbdev [13.058] (II) VESA: driver for VESA chipsets: vesa [13.058] (++) using VT number 7 [13.071] (II) [KMS] drm report modesetting isn't supported. [13.071] (WW) Falling back to old
Bug#785138: gparted: Upstream has a new version, v0.24
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 11/26/2015 01:39 PM, famrlz wrote: > Hi. Is there any way I could help speeding up the process of > uploading a newer version of gparted? I actually built it the other night but have run into some problems testing it due to bugs in sid. Working through them now and will try to upload tonight. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCgAGBQJWWOcCAAoJEBB5UWFcu6UW7CsH/1fnyjmElyEG907hwr29swh1 BnBmGyjijuKWUPbSanhmjPr/Qu1qe0uXoLvOjL3Otz3jmu1qbvlligorspqIMCxD Gzjd8AedcbXTrqUNGG0G8V8Qw2G2lSKL7qUzDPaOMlEp9WO4rb/MUkXYLyENF8tS qfestVEFCWrU9JyL03w+ZsVpD3Ssrtxe5vE9aYeubylsgcw8uM2hxG4/NDaqisCg X/qW8sVT3a/pUBao3ZH/KwqDfnBXzSwM24NnBbt/76hNloyKQRUYPaI/p6JvgR+7 2o/2tSyZKSu6PpKZS2GR61xLDthixCPrNNcenaaWSvHQlDDJ8DInnzjV6MPI5u8= =NTwV -END PGP SIGNATURE-
Bug#805845: mount --move broken
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Control: reassign -1 linux So it seems the problem is that systemd makes the root shared by default, and mounts can only be moved if the parent mount is private. Running mount --make-private fixes the issue. I'm still not sure why the kernel can't move mounts in a shared namespac e. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCgAGBQJWWOeqAAoJEBB5UWFcu6UWFkQH/iSdiLHoHEc5tv0z/OdeXo+w 1Oa3mgh7EJb9qlxTD2B/aE+atFW4jBW8smeMyunytvvUTH67EeVgE2aS89QdaenK zd732/5m1zP92GpqUNkScdpwc5V/oZ7nFbttYoy2H3Ccq9rO59SRSuzSPfi+F8gk j1ZGN0M73+MQ2luo/9EJhfpX0n7jNm+NEzR5Ief5BRSAWP0Lw0junYmvttMZsSpQ RIuRIo1TzJQ4XYP5v2fp8t9moHozEw/wFKyGL0/ZVTtMVb3dNrRLle2XlzI3FWQK 8m3JoJ4Q7dHwIDi4HBfgn63VkOZZq9pWttM9yI9M9qPkXw79KVkBtNi2P4Tb1Jg= =JJg/ -END PGP SIGNATURE-
Bug#806180: Mouse does not work in qemu
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Package: xserver-xorg-input-mouse Version: 1:1.9.1-1 After upgrading from jessie to testing in a qemu virtual machine, the mouse no longer works. gpm works fine on tty1. Running with: qemu-system-x86_64 -m 1024 --enable-kvm -drive file=/dev/faldara/sid,format=raw -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCgAGBQJWVRxgAAoJEBB5UWFcu6UWGKgIAIBCnoet/DZUQipzo2h1b4+d 3wvpFVmLKWCr53xZsSAta4iWe4h6Y6so1Yg7mmfJ3W09Ic6wYqC7+XcmNexEoNFL 8mzxB1eQNmgc+hwgYMayOSWTKHLJvChCASzQ27JfcmETcAgjijK7pyucKXHoy+fS M5i7D09O647amzW6HXlFx1joKG001rBKVRqQ0ED8hEKMTQBruDUS3AQrw2V2aO0n NQh8jdhkEhAGHc2Z5ox1WWBziMeworuMrzqdxfEg8K/4ihdIIbFkGj8rSO5paKDh UM+pgMJ1cQKrgV08dxMQthGpsc79vYquE2e4JH7VnG16agid5sCcOCrmJX1adIg= =FDBM -END PGP SIGNATURE-
Bug#805845: mount --move broken
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Package: util-linux Version: 2.25.2-6 Control: affects -1 +udisks2 +gparted gparted runs udisks2-inhibit, which runs mount --move /a /b, and this fails with "mount: bad option...". Manually running mount --move /a /b ( where /a is a tmpfs mount and /b is a directory ) likewise fails. Running mount --bind /a /b, then umount /a works however. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCgAGBQJWUmptAAoJEBB5UWFcu6UWhmEH/1dCLGXsWFElNLOvRLDF3q4L M9DL6TzZDX5PPN2GdKswuGLEhgbAaMufz2wLxo8/UpBKGpA9WrbfsciCVWTyGOFl Y2ze/TPUa3ZfyWC3y1QCDSAqT1EIPKGHPsTjBfUaMXoM0qo0J5j95EuCT/b/K9hi bCNGsNTjQej65F7ctwmkUGD8ZI/F3qO7r8tcwTIISmJ1M3uMLVaLl6Oz4+jRC/vN 1uU8IWoUoAUkgPWeFzawZQ1otZixhsccZrdRElpR9XCrRntR68/ufHoemOE0fQ8A 3Uv092g2zMXfKjxW3X9OEjLvyWQBKWG5HbKJpyIvF2iHdUmg5nx9hUUANhtMqNc= =gSG/ -END PGP SIGNATURE-
Bug#791754: initramfs-tools: / on LVM gets mounted by initrd with kernel device name /dev/dm-X instead of /dev/mapper/XXX name
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Found this on Ubuntu 15.10 as well: http://launchpad.net/bugs/1513272 -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCgAGBQJWOq2ZAAoJEBB5UWFcu6UWpoUH/19pkbrkOTIjvpGN8Bs9IlR2 28hc3Q/XC8RmwWcMBloSf6j0AkEYrLCJhsAU0eddl5vymwIxApKo35252Xszlv55 +NO09OkHXpqn0Ep6sKVU8FRnlE20rlNwe7Hbi4UXvdaW9HI/RVimAiDTj45q+YkG V3qhx30iUyEBsXOY/BBLPD0/FVWDKmaxtqMSiHOHQxTvm2DNzsYFW08eEnoP7fi2 C4mALYGUDmYpoxSvJrJ+n8Y36pP3UP/v8/zeQKjkdLOppkK1QyiQ2ZUqs5WZS4Qw EgtZ7cjQFBeqaXwMxZ4mts4xdq4Awge8dZruzU+jhaHfIY+4dAZhnpgdpwilteI= =OgTS -END PGP SIGNATURE-
Bug#792752: mention that one must use -f or the count must be exceeded, else just one big no-op
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 reassign 792752 e2fsprogs thanks This is really specific to e2fsck, not fsck. On 07/17/2015 09:33 PM, 積丹尼 Dan Jacobson wrote: Package: util-linux Version: 2.26.2-8 Severity: wishlist File: /usr/share/man/man8/fsck.8.gz Maybe on the fsck man page, there should be a notice at top: ** Dear user: fsck doesn't REALLY check a filesystem unless 1. you use the -f flag or 2. the number of mounts has reached the limit (20). Unless one of the above conditions are met, nothing at all will be done, despite any other options given, it is just one big no-op that prints some statistics, but doesn't actually check your disks at all. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCgAGBQJVqw4xAAoJENRVrw2cjl5RJE0H/RB7zK958TL/fpSHAsDy6nC9 RRgwWFl73z6st6VDp2xvjZdqtH5+6qbOT15JT078mFSLt5yp2f8DDPBGMDxRWy/g U6l/iODv1L6diNa8A6aMSUAsTiS94mipzOkA+F33PsZFoVQdiwdGTw5u9E/UJhIg fDSd9bPffEqPzm5DQIjjmaFhdJ1wsMYxQ3b27M5ySr7I8z6xOpnG5l5ey9fy5b5G AdqWmRH1UNCca3P/HlMYYseTjYe0qnFAsDQqYJVxcO/NYLyQObb66TH+NH1/4WXe IQsToDSDm9/I3K1HNb1NutFaICUwLnNOtMM6VM2ZKdK4HHIMg2IKbmQKBR1WLIY= =F/rf -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787763: util-linux: 'unshare -m' broken
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/06/2015 02:56 PM, James Long wrote: Phil, it does work if /mnt is already a mount point, and I subsequently make a second mount underneath /mnt. I expect that the patched version of unshare(1) with restore the previous behavior, allowing things mounted directly on /mnt to be private. There is no patch for unshare(1). The mount you want to make private is /, since that is the mount point you are attaching a new mount to. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCgAGBQJVc5ssAAoJENRVrw2cjl5RgkIH/jxZY0aJSQk2l52puPm8Nmwq pZ3la7HC/G4Ma5ZkGk8xjYGrL/97X0rvlK+JxEVyle1YWY76pLStg5fZsAH1pl8S RgJnatTJ3/+B+zH7qm/BENR0givQnJq2mcYZ7Oxe2dFUALGgt31cvikUqC/Lvs2g nsdVCU3l8C9Gyflimz7MYs2Rpc9XiQQduxzzE6MhG30CToqs4XgNvwlaq3x12Xum MrudD41ju2upUCnjiu52/i+Vi98vLoluovJg2Hc9FQZYfmv1vqr3T+WMMmC5nX0v wW/zvQSI5DtHkKRdwDQLAWVUnDLTNvZU3HV6ZH7pMX2LDIBQz6HoBn3am9pipRE= =KC0i -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#779017: gparted: btrfs partition can not be cloned
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 reassign 779017 btrfs-tools thanks On 2/23/2015 5:18 AM, Joachim Schmidt wrote: I created a btrfs partition with btrfs-convert from ext4. This partition can not be cloned with gparted to other disk because btrfschk is unsuccessful. A btrfs check --repair /dev/sdXX does not help. Then the problem has to do with btrfs rather than gparted. It would probably help to show exactly what errors btrfsfsck is throwing. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJU60JxAAoJENRVrw2cjl5RbKgH/jj6ree3EQeZVuGTYVN3gOSy abO5dhQbWQC2U+2w0KbC4rw4AlswtncLQj7GHdFOEuE07m3hze+vnrpouXojzY5O pN3vv1PHub4rgGW4H68L9aXr4ETsUmhH9quDIQOazlsEMohi7eHlZWY+cn6rsxxI R6Xn/60jog00yk476TW65EJzKX/zaNDX0Oj25h9g5Gu2SfYcx2Okl63jhJcaDB1+ Q3HNmXcxzvqNBbVih46roKpruvPrVNV8RdvEndi3yr5LNE8TleFfHJ8CYM9TIhEO LDj9sf0ax96Gf8zLscKkY9WUeJHKhoAHbVYCwwUfQpc6rKUx7kfpOD9SW+MHpwA= =NGJz -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778712: libparted2: Breakage of RAID GPT header
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/19/2015 2:24 PM, jnqnfe wrote: Firstly, I am not running fdisk or parted on the raw member disks, I am simply running generic 'fdisk -l' and 'parted -l' commands, which return information about all disks. To simplify matters I removed information about other disks in my system from the output I supplied, leaving only that pertaining to the array and array member disks. You did not; the output you supplied listed both sda and sdb. I disagree that the problems reported against the member disks should just be ignored. Why does parted think and report that one of the member disks has corrupt GPT tables? 1) The array was setup with 16KB block striping, which is surely plenty to contain the entire MBR block and primary GPT table within the one member disk; so it's not like this results from part of the GPT header being on one disk and the rest on another, which otherwise would understandably result in such an error. Unless I am wrong and this is happening, why does parted think there is a corruption? The GPT is 16 KiB but starts on sector 2, hence the last 2 sectors fall onto the second disk. 2) Why is parted examining GPT headers of member disks at all? It should recognise that these disks are members of a RAID array and thus skip looking for and reading partition headers on it, otherwise it just results in confusion for the user (and potentially other issues if it changes anything). Parted's behaviour should be changed here accordingly to skip seeking this information on array members. Because parted does not know anything about raid. I suppose it might be nice if it could detect it and ignore those drives, but doing so would require adding a dependency on udev or blkid. I'll mull the idea over. Furthermore, if you look at the fdisk output I supplied, you should notice that when I created the partition table with fdisk, everything was initially fine; no 'dev/sdb1' device exists (see fdisk4). However after running 'parted -l' to see what parted makes of the result of using fdisk, and then re-running 'fdisk -l' (I just happened to do so to be certain everything was fine, and found to my surprise it was not), you can see that now all of a sudden a /dev/sdb1' device exists. sdb1 shows up in fdisk2. The 'GPT PMBR size mismatch' error reported by fdisk is related to this device, which per its name is apparently a sub-component of one of the array member disks, but I did not create any partition, and this device does not appear in lsblk output. So where does this 'sdb1' device come from? As just stated, it does not exist after purely creating the partition table with fdisk, but it does suddenly exist after running The moment you created the GPT table on the raid array, it included the protective MBR partition, and that is what fdisk is reporting since the GPT is corrupt ( when viewed through the lens of the single disk ). lsblk uses the blkid database which does recognize that the disks are array components and filters them out. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJU50+6AAoJENRVrw2cjl5RgMAIAIKdSLrH8xyAOGgILnFkaMC3 Y0nWrjnH6ZZvxF4WgFCgRkmPAt0Er2BTYTd0PTMd81mMRndoWJNfiQ+J5L8GTxCb jekarQWgpnGuUfhuUGJxg23IoTUhCXsbIiOu8kcbYTfI3WmXD5ZWEK2ZA+Y9XAaU rWIajfIfcngeQKaZXL6TdKGslKfaOfdIyAn4AyAGuRP7SwyaHNu9RQyXo4xayjm1 006WmHNAIk0CtOMkPIPjH018+jmj3rnAqBIXc2R6wBZ6QjBdTmch2iRqYln99OR9 wJ6Jso9SWARM+pa3Yh2smFdWJPTFTHe9pY3xmFKtAOP7KGF5vQVJ9wC1w+ss7Ao= =dSiK -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778712: libparted2: Breakage of RAID GPT header
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/20/2015 3:44 PM, jnqnfe wrote: I agree now that this might just be an fdisk caching issue, but I don't think this bit is quiet as you describe. The actions taken and results were as follows: 1) RAID array recreated. 2) fdisk used to create GPT table on md126. 3) fdisk -l, showing no issues and no info from MBR. It also shows no GPT either, because it is still seeing the stale cached data where there is nothing on the drive but zeros. 4) parted -l, pointing out corrupt GPT table. 5) fdisk -l, now showing info from the MBR and the error. So on the basis that fdisk is writing the same protected MBR that parted does, it seems fdisk is failing to flush it's cache and see the problem when asked to display info immediately following creation of the partition tables. Then, either parted triggered a cache flush (shared cache I presume?), or else fdisk managed to flush the cache the second time around. So in conclusion, this whole confusing mess resulted from a combination of: 1) parted being incapable of understanding RAID array membership. 2) fdisk also being incapable of understanding RAID array membership. 3) fdisk failing to flush a cache of partition info. Right... fdisk flushes the cache on /dev/md127, but not /dev/sdb, since it isn't operating on /dev/sdb. When you run parted -l, it walks every disk in the system and as part of reading from each one, flushes the cache, thus, /dev/sdb has its cache flushed, and reads the new partition table from the disk. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJU56AZAAoJENRVrw2cjl5RrtEIAJ+RgE2yKuIY+a3YeuF9ctyT xfZi6Uzdcz2UfaM1iWvJzdd6IUDgnDztajO4RYgl/XlMjS6efXtO3YixKsUI1Ajt 1Iv4rhPt2Asd+yFCX8fNkA6aGhvTGuHBvf21uWfUZRv05NC8ck7ro8d21RObQDsk KX5/c/PW3GTJDq1OrQsYygFCoFOocc5w60bu3vcHbGU7WPp561FTrQ4R4Sk1oZaH ln7W+QtfV+wYg7DnjvdMh2YRrIGfk3IoV4GibIFkn+6X5numGBs/O9/f8Q+4DyJC naMHOTQAGdzF5VxlNukeCkC7JlWPzEV1sFzxlB/DRhzb/F1Y8MGKCsLZexHEmSE= =kD25 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778712: libparted2: Breakage of RAID GPT header
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/20/2015 12:17 PM, jnqnfe wrote: What? I very carefully went through every one of them before sending to ensure that only information about the array (md126) and the array members (sdb and sdc) were included. I have just checked back over every one of those files attached to the original bug report and none of them contain any info about sda. I'm sorry; I misread what you said. I thought you said you had removed the information about the individual disks that were members of the array. sdb1 shows up in fdisk2. Yes, but please review the initial bug report for when I created each of the output files. I ran three tests using different tools to create the GPT headers, first with gparted, then with parted, then with fdisk. Before each test I deleted and recreated the RAID array to try and achieve a fresh start (which checking fdisk and parted info after doing so confirmed was a successful means of resetting things). Files fdisk1 and parted1 demonstrate the state of things directly after recreating the RAID array, without yet attempting to write the partition table. Yes, at this point the disk is blank. So, fdisk2 and parted2 show the state of things after using gparted to write a GPT table to the array, and thus this phantom sdb1 device exists, which fdisk doesn't like. At this point the array contains a protective MBR that lists one partition of type ee that occupies the whole array. Fdisk looks at sdb and sees the same thing. Following the MBR is the GPT, part of which is missing from sdb, so fdisk treats it as corrupt, and falls back to printing only the MBR. So the phantom sdb1 device was not there when only fdisk was used (fdisk4), but does appear after using parted, whether using parted to create the partition table (fdisk 2, fdisk3), or as in the last test, only to view information (parted -l) after using fdisk (fdisk5). I see now. I think you are running into a cache aliasing issue here. That is to say, that the MBR of sdb was read into the cache while the drive was still blank, and when parted creates the gpt on the array, it does in fact create that protective mbr partition, but fdisk does not see it on sdb yet, since it is still holding the cached data from earlier. Note that at this point fdisk reports that there is no partition table of any kind, not just no sdb1. If you run blockdev - --flushbufs and then repeat the fdisk -l, sdb1 should show up. Okay, I am aware that a protective MBR may be written alongside the GPT tables and that the protective MBR may contain a partition entry covering the entire disk. So you're suggesting that this may be what this phantom sdb1 device is? Interesting. Yes, that is exactly what sdb1 is. You can see from the ID field being ee. But, what is the explanation for it not appearing in fdisk ouput after using fdisk to create the GPT tables in test #3? And furthermore what is the explanation for it then suddenly appearing after then running 'parted -l'? And if that is the case then that would imply that fdisk also may not be properly paying attention to the fact that these are array members. parted flushes the disk cache when opening it to make sure that it is reading the correct data. After that, fdisk also now sees it. If fdisk is setting the protective MBR partition to the size of a member disk, rather than the size of the array, that would explain the fdisk error not showing up after using fdisk to create the partition tables. And if parted is doing the opposite, setting the array size here, that would explain the presence of the error in fdisk output after using parted to do it. Which if so, begs the question, which is right? Should fdisk be changed to use the array size (alongside paying proper attention to array membership of course), or should parted be using the disk size? Both of them are using the size of the array, which they should since that is the disk as far as they are concerned. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJU55UUAAoJENRVrw2cjl5RM8UH/0tBf2Kz1MfNkZeOuMG4nfRV fx5iYdI0I5Zm5SEB1fYXJcKLwxfNb5h0sBs+BskmVcnJZioMm3foo9uHetFip4kA 2zBZfXmgI5akFbkYYq2H7q0wxwU4tDecCGOn9cOUeTA0GNCci4W/f6TfKugk504E aUzoQMh+qN8Fxycj1p+efa7voRgYiUjC8aaEUmswYRLdfgxKKLkhOKYZY31Kk3Qf i5zbLjeUrLPARlmUGOc2ON0ljzLm/QJ3p40iCTFVaJ9dQrUumLiH4bUc53rXY72S XAYeaCTim2gKTcGJD6VKMTa/EVlwjWgBPb12FsnFtha/Gv/oilahGVqz5cZlRro= =3W21 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778683: Error creating partition table on RAID device
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 tags 778683 + moreinfo thanks I can't really follow your very well, but it sounds like you did simply select the wrong device in gparted. If you can reproduce this using just parted showing how would make things clear. If you can only reproduce it in gparted, then more detailed steps of how, as well as a copy of the gparted log file should help track down the problem there. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJU5NaVAAoJENRVrw2cjl5RJT0H/3/mVrSSxGrWUyBrNKWY5ko6 o6YpqfSdLF/xHBRGAvKsCaw7g8Uv/GDrJXaIg3IUU4Ba8b3S+lKsmQ/UbZFARSQH FWWUBsrJmJARjs7T7azxjUDbipVFJZQxxoNKKPqzeNwGhXIGHM8WVmffP1YUOYzK 00Of92sZffPyw2DdTIJaHtJNFMJiVkdf7K7RRkURzHvSoA8uEw2ezQVjaHJmQ1OA 8Bdc759gi+OrjDGRALJrA86ztLNvqFOa9nb5PQ491jfkBSHyrYVziGZ8HIgkEmZ0 drDyEA9pMH8obz+EEDTOw6HbMFS9xghAtcbKKALaQRkbc+wDEJK3ovQh476mabQ= =uEDM -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778712: libparted2: Breakage of RAID GPT header
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/18/2015 4:05 PM, jnqnfe wrote: Background = I have a 'fake-raid' RAID0 array, created from two HDDs using my motherboard firmware. This is not used for root, just data. FYI, unless you have to dual boot with windows, you should avoid using fakeraid and stick with conventional linux software raid, which is much better supported. sdb and sdc are the RAID members here and the RAID device is md126. Then you need to only manipulate md126 and ignore sdb and sdc. Most of what you seem to be reporting involves looking directly at the individual disks, which you must not do as that will present a partial/corrupt view of the raid array. In other words, if the first few sectors of the raid array map to sdb, then sdb will appear to have a partition table in its sector 0 that describes a disk that is twice the size, since this partition table is actually describing the raid array and not the individual disk. The one thing you mention that I can't write off as user error is but parted is not and seems to be forcibly applying what it believes to be correct (ignoring the fact that it was only asked to display info, not modify anything). Can you provide more details here? Exactly what command did you run and what changed before vs. after? Parted should not be modifying anything on the disk unless you tell it to. Normally it will throw a warning telling you something is wrong with the disk and ask if you want it to fix it and you have to answer fix for it to modify the disk. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJU5QWEAAoJENRVrw2cjl5RwnkH/0jvimRzKxUZjFait+KVZQgW gq2m6MVJYiDZLX3ajGZj2mxQNVu2RFqDn+YwqAWeDtrQEj/B0TXJC3RbBJpoN3Ao 5kH+lU2Z+YihRDpQMst8VGt1MVA6izcapN1uVeJOcLB2wICSGd0WcjAn8ROSnZNS o/7hXLh7dhxQZT+2HsTpmWa6pLEVvyBeQ8u2giNB0w8he75qv4/AxCFYAdVqhr4Y nNfC9zzCtcOGExu12GyigEpWUPlxUcyGsYzaQRR2hG1Vv7LKBsDBsok3qAag033E DyhyCWDj8NJk1WQIW2ZyVjhcskSyl59Oatd7X3TGSqr2L7yaHV+QAA5Cng+A9fw= =WuvR -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778712: libparted2: Breakage of RAID GPT header
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/18/2015 05:15 PM, jnqnfe wrote: Then you need to only manipulate md126 and ignore sdb and sdc. Most of what you seem to be reporting involves looking directly at the individual disks, which you must not do as that will present a partial/corrupt view of the raid array. In other words, if the first few sectors of the raid array map to sdb, then sdb will appear to have a partition table in its sector 0 that describes a disk that is twice the size, since this partition table is actually describing the raid array and not the individual disk. I am not doing anything at all to the member disks, I am only manipulating the array (mb126) and providing the ouput of fsdisk -l / parted -l (with unnecessary info about other disks removed). All of the error messages shown in the logs you sent so far involve the raw disks ( sdb, etc ) rather than the raid array. You certainly should not be running fdisk or parted on the raw disk, and responding to the error messages by saying it should fix the problem ( since the problem is only a result of looking at an individual disk instead of the whole array ). The one thing you mention that I can't write off as user error is but parted is not and seems to be forcibly applying what it believes to be correct (ignoring the fact that it was only asked to display info, not modify anything). Can you provide more details here? Exactly what command did you run and what changed before vs. after? Parted should not be modifying anything on the disk unless you tell it to. Normally it will throw a warning telling you something is wrong with the disk and ask if you want it to fix it and you have to answer fix for it to modify the disk. I did only exactly as described in my previous message, nothing more, nothing less. You stated that parted modified the disk when you didn't tell it to, but did not show exactly what command you gave that lead to this, and more importantly, what if any, error messages parted threw and how you responded to them. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCgAGBQJU5WZLAAoJENRVrw2cjl5RIEwIAKgjCMaHtYDruSejfB5I60F9 opO+FGClLTJPML6ggREF8hDM+K7eFpWCa4buWTvKUBix1oNjeLvWJVfu5XoSIQbt A+XX+YyBGjYuXXApXUV5W1A9P/beKhAGzs0anAZu6pZEirCcxQINjexjPua8PlZM PSuEppd/Bpmnw26CK/h2lrFNHJs1c9vzcnLOwMlT0ZzVXVAFFK90z8cxVo/kSvVb z5Sp5NtD/WWcdc5nTs6m1yEgs/3E/G3OB9VUF3+2c9dwXj5FXnEzAMAKN+g2ZKAO zI2TGFQpITPRkP7ij+0XpqH/YaWYLAHGbb0peIbsQHpDuBX+yT16Q3E93Sg56oU= =2m/O -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778617: grub-install often breaks in UEFI mode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/17/2015 5:51 PM, Steve McIntyre wrote: On Tue, Feb 17, 2015 at 09:32:56AM -0500, Phillip Susi wrote: Package: grub-installer Version: 1.110 I'm forwarding this patch from Ubuntu: https://launchpad.net/bugs/1303790 On EFI, the boot disk argument given to grub-install is a dummy and is often the wrong disk or a non existent disk. Grub is still installed to the correct place since it goes through the filesystem to /boot/EFI, but the function make_active_partition tries to look at the partition table on the dummy disk and throws an error. Hence, I wrote the attached patch to disable the function on EFI. Hi Phillip, The logic looks ok, I guess, but I'd check more explicitly for grub-efi-* instead of !grub-pc. There's several other architectures that may use grub, and I'm not sure if/how they may need special handling for active partitions... Sounds good to me if you want to switch it when you apply the patch. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJU5KcwAAoJENRVrw2cjl5R48YH/isp8MR/2Ps4F0v7fzpxpgkb Oe2e/s+ziB14mhKQ1dNHb8KcIeFfg60cCTSNw8kmb05Zk+v+GsaAHpKX0Dk62i5T gy+9HXPlyUqZTzCe24mQnSAgSbrgm8B9OD0VRgr6fEzAbW2/+co9wI4l1NQHKifK fPls70SKQBZyqZDpr4F0uBEBDfB16kOTJr8P+a9MEhdzkwxA0CyuQObwaIC5V0xd DpQqmiE+g5v9zpJgBZDVV/c1t+mBAzSTnORg+/1J8qXf48yHOtA2Or0nJb/VxvBM U6B32fsy7g+4hnZVq1U3Q+JlrNIB4BdyyEoatg68i2TnjS5b/aDXCVPBR0TpsoY= =igUq -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778617: grub-install often breaks in UEFI mode
Package: grub-installer
Version: 1.110
I'm forwarding this patch from Ubuntu:
https://launchpad.net/bugs/1303790
On EFI, the boot disk argument given to grub-install is a dummy and is
often the wrong disk or a non existent disk. Grub is still installed to
the correct place since it goes through the filesystem to /boot/EFI, but
the function make_active_partition tries to look at the partition table
on the dummy disk and throws an error. Hence, I wrote the attached
patch to disable the function on EFI.
revno: 121
committer: Phillip Susi ps...@ubuntu.com
branch nick: grub-installer
timestamp: Tue 2015-02-17 09:15:44 -0500
message:
Don't try to mark a partition as active, except on grub-pc.
This was causing failures for grub-efi (LP: #1303790).
diff:
=== modified file 'debian/changelog'
--- debian/changelog2014-10-06 18:29:15 +
+++ debian/changelog2015-02-17 14:15:44 +
@@ -1,3 +1,10 @@
+grub-installer (1.78ubuntu24) vivid; urgency=medium
+
+ * Don't try to mark a partition as active, except on grub-pc.
+This was causing failures for grub-efi (LP: #1303790).
+
+ -- Phillip Susi ps...@ubuntu.com Tue, 27 Jan 2015 15:51:09 -0500
+
grub-installer (1.78ubuntu23) utopic; urgency=medium
* On ppc64el, wipe the PReP partition before installing grub-ieee1275,
=== modified file 'grub-installer'
--- grub-installer 2014-10-06 18:29:15 +
+++ grub-installer 2015-02-17 14:15:44 +
@@ -1006,6 +1006,12 @@
}
make_active_partition () {
+ if [ $grub_package != grub-pc ]; then
+ # only do this for grub-pc since on EFI $bootdev is a dummy argument
+ # and looking for a partition table on the wrong or non existing disk
+ # crashes the installer LP:#1303790
+ return
+ fi
bootdisk=
bootpart=
case $bootdev in
signature.asc
Description: OpenPGP digital signature
Bug#777647: partman-efi always complains when installing from usb
On 2/17/2015 1:37 AM, Steve McIntyre wrote: Any futher clues on this at all? I have next to no knowledge about how the Ubuntu installer code uses the d-i packages, which makes it difficult for me to comment much more. I emailed a log with my attempt at analyzing it to Colin Watson the other day and am still waiting to hear back from him. I think you can close this bug now as I'm fairly certain it is an Ubiquity issue. I looked at some logs from older releases and indeed they all seem to run all of the init.d scripts first, and only later process the visual.d and other scripts, so somehow ubiquity must be running things wrongly and getting the visual.d scripts to run before the init.d ones and that is the cause of the problem. I do still wonder though, why the script doesn't trip up when installing from a USB stick. Is there some logic somewhere I don't see that causes all of partman to ignore/forget about the disk you are installing from, so that the efi script doesn't see that and count it as a non ESP? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#777647: partman-efi always complains when installing from usb
On 2/11/2015 4:38 AM, Steve McIntyre wrote: Hmmm, and just testing with the latest Debian amd64 daily netinst all works flawlessly here still, using the same empty disk in a KVM setup as your bug reporter. Strange.. I'll have to poke around with that. This suggests the problem is Ubuntu-specific, or there's an issue with other software. You allude to potential changes in libparted; how do the versions in Debian and Ubuntu compare here? They are in sync. The change in particular that I think may be related is that in parted3, it now keeps the partition table cached between commands rather than re-reading it every time. This has the affect that when you create a partition and tell parted it will hold an ext2 filesystem, and then print the table, it now reports that it contains an ext2 filesystem since it is no longer re-reading the disk and finding the partition to be empty. Now that I think about it though, this change was in parted proper and so should not affect other libparted clients like parted_server, so that seems to have been a red herring. The thing I saw that struck me as similar to that parted change was that when I put a set +x in the partman-efi script, it appeared to have identified an ext2 filesystem on the disk that partman was formatting with the usual default ext4 root and swap partitions so I kind of assumed it simply had not gotten around to running mke2fs yet but had asked libparted to make an ext2 partition and then partman-efi identified it as a non efi system partition. This script really should be running before the disk has been modified in any way though right? So it should still just see a blank disk or a disk with no partitions and not count it as a non ESP. Hrm... I'll do some more debugging tonight. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#777647: partman-efi always complains when installing from usb
On 02/11/2015 11:47 AM, Steve McIntyre wrote: Quite, that's exactly how it's meant to work and it's what I've seen in my development and testing. Silly question - is ubiquity trying to run some of the d-i bits in parallel, or something? That's what I was wondering. I'm looking at /var/log/partman now and it appears that visual.d/35name runs and then I see /bin/perform_recipie issue a NEW_PARTITION command to make the ext2 partition ( which will later be formatted as fat32 for the esp ), and then the ext4 partition for the root and then swap. Later init.d/50efi runs and sees the partition that the earlier script created even though it has not actually been committed to disk yet ( i.e. blkid still sees a blank disk ). Did we change the ordering in ubuntu or something so that the problem is that visual.d has priority 35 but init.d/efi has priority 50 when they should run the other order? I would think that all of the init.d scripts would be run before any visual.d scripts though, and the priorities just order them within their group. If that's not the case then I guess they simply have the wrong priority. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#777647: partman-efi always complains when installing from usb
Package: partman-efi Version: 59 partman-efi uses flawed logic that trips up when installing from usb. init.d/efi scans the system and counts the number of efi system partitions, and the number of non efi system partitions. If it does not find an EFI system partition, but does find at least one non ESP, then it throws the non_efi_system warning/question. The problem is that when installing to a disk that does not already have an efi system partition, the script *always* detects a non EFI system partition, and throws the warning. This may be connected to a recent change in libparted. Looking at the partman logs and the output after adding a set -x to the init.d/efi script, it appears to me that what is happening is that the system asks libparted to create a new partition on the hard disk that will become an EFI system partition. Either init.d/efi runs before the partition has been formatted with a fat filesystem, or parted_server is still running and is keeping the ext2 fs type cached from before it was formatted. Either way, the script decides it sees an ext2 filesystem on the drive, and that counts as a non EFI system partition, and so it throws the message. Forwarding this from launchpad bug #1418706 in Ubuntu. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#777647: partman-efi always complains when installing from usb
title 777647 partman-efi complains about boot problem whenever the target disk does not have an efi system partition thanks Sorry, I mentioned that it involved installing from a usb stick, but it also happens when installing from cdrom; using a usb stick has nothing to do with it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#777166: Please consider not hard coding the name Debian into error messages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: partman-efi Version: 59 Recently a new message was added to d-i: This machine's firmware has started the installer in UEFI mode but it looks like there may be existing operating systems already installed using BIOS compatibility mode. If you continue to install Debian in UEFI mode, it might be difficult to reboot the machine into any BIOS-mode operating systems later. Please consider replacing Debian with `lsb_release -si` or similar so that people installing other distros based on debian don't get a message about a different operating system than the one they are installing. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJU09MKAAoJENRVrw2cjl5RvvMH/1WYchn0xt77ZRySIodqz9sx VgDNmuXNbafhE6NATzOSnQxYwwprMHcS5HD8rfNoF6G9Zg//a6pGQa6BJ73C0Zn/ 1oeb5fiOFTlcaJbpelDsx7cxH9aWWrSRN4HEiJIeR9u3FssJcJEU9r5Iuw7Kj+f/ uT8qNdibKnyKZziYeCgw06DGdtA6l64PgH4apjlCUcKr1q9x+zlP0HE1lASJxKas gSfRjeDLtus4SFsAq3EhEZd/W9QfttFTG7aknsJgqmAoVZn2pq+ceogD9CfTA121 8E3iACB7icTGOE7z+j13VRCkIh3Zmi2Xp+b92pj9BkXGnrXpFEOBfx1RZXr5tXI= =zk48 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776034: fsck runs in parallel on same physical disk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/26/2015 7:34 AM, Daniel Pocock wrote: The performance impact is not trivial. I have 28 LVs on my main /dev/md and 47 on an external disk that is used to replicate other filesystems. Both of these disks make a horrible thrashing sound while fsck runs. Why on earth are you fscking all of those volumes at once? Use a journaling filesystem ( ext4? xfs? ) and you shouldn't really ever need to fsck at all. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJUxkZJAAoJENRVrw2cjl5RPywH/RvUti6Xn8EUi8CBVBe8G1xU ViahLvk3Q+vMZxNHASg7pbjXMBzosBks28+kd5lqZ/LGm9vNBXTmmEctUwwG/RHZ yT9kiOg8A/czkW9N4enEZ7Qtb/bq8fH9Cc4uqEDvKxJFZN8hr0I9W9KE/hfYGv28 B3o9qEbyrzv6VsC9UjeA2b+/1taQFUp3KKcM0s/maXJef9JufzTilVkT8lb1cUMd /4/oWB4HUywG/ArMP8eCogy/0jsJSLWIPs0bAvmUVBo2YnfOFuBn67cuF7Z3a6ZG OtaKbIExqlyDrT4/Jo+nfsXYpt9h48AKtjESUuqX4C7xB2hMob8q5yOPx65/IKY= =+qtc -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765283: gparted crashes due to bug in glibmm
reassign 765283 src:glibmm affects 765283 gparted tags 765283 + fixed-upstream thanks Upstream traced this to a change in glibmm that they have patched. Please apply the patch in this upstream bug report: https://bugzilla.gnome.org/show_bug.cgi?id=743466 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765283: Bug 765283
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/23/2015 3:34 AM, Andreas wrote: Hi Phillip! I can reproduce this here on Lubuntu Vivid... Lots of stuff coming up... Strange... it looks like a newly created thread is crashing very early on before it even gets to run any gparted code. Could you describe how you reproduce the crash, and could you take a look at what the other threads are doing when the crash happens? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJUwlVYAAoJENRVrw2cjl5RXagIAKln/hycuKzE6sbSF/Nr9kto +Jmarl4PMRvx8sVisYHGkM/O2xkMpEC2VdZYWXd52gj7MLwlQMzrQ6rP8Fyl7tcp k1bNbwI/Hey913pIb8qOLiPmCFuvLC89X+PrkHP32Sm81Udlz1N7gtkKmyuR3JdK AJbmasN/QGo2dm6XRQEvNGT/yMIzOu+Y+YHotJoIjfHnhRq/f+nzDnaQqJ3K6z+i pb31JKT/lBNQW4HTJMokJNyUYmeVhF65Dc6iuDOqvdh9IWLx7msGwhnhD8byk1Jb ULMLtKRVKcCran6gDjtqR2xT1QACd4oIwtIW2v1WkRCaaSQQRNR/DX27tapOZdY= =sfs1 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773354: please add breaks: live-tools ( 4.0.1-1)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/17/2014 6:27 PM, Daniel Baumann wrote: On 12/17/14 23:50, Andreas Henriksson wrote: I'd guess (without having looked) because live-tools diverts update-initramfs? no, it's about uptime. What? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJUkuCUAAoJENRVrw2cjl5R3BYIAIYUEHWyeJb3ar/2D4V9//zO 1LQ7G6jZURBSnn/FqUfzHEW6S7Q1m4Hk5aUvXdlEv1M0e98xPVGQ6irjEd0aGXsz aHv6C1VW1r00yRa6WnkShhreEuuzjDUmWsS8To8Rbv0fUPxOhRsJRXjlcn89Gjqs X9eFDojeUv8P3Z5S+byThsnFwVoWuPnF0WETHmmsxhX4uxkpQumIBHzqB0KgK3Fe hFX2PCu0qqp4QtKc9TW7dPTb/Mueg9PX1UVm8wQwwtKFClqhLoNvCSlAFJe7e3Br WRCQPj760ZP5NBsCwNDNZNyf/wdfb06k/2lOYvDNJ1kSBB2EBPvSl5jhiQx5ou0= =HvMz -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772977: mount: root partition cannot be remounted readwrite from shell
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 tags 772977 - moreinfo + fixed-upstream thanks They fixed it upstream -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJUkuX7AAoJENRVrw2cjl5RBTUH/044JAIRAaC366HvdF+O9gVK YXmdfx/E9RDp35LrUJSfObLHToqeSavFkDT7BGiTau10iDsnXEP4beIadv7Euqzw tZwiKJOP0BwWin4059vx++n5M3e0keuLxbdV/vCeZlnDPllEKjfwO4RCcZMscGHU V5/hVHW8WE8avyVGitrFg862wJVgli/QJ0QFtotg0LFrIKCxV9JPSHK/zObxezHL oMgiJ+IB2S3nvGueIko6aP2/5ZuCu9rvdie0l23hh0rsQ+A9Z9fY8H13GD5Qas2q rG4XkdI79W6M8tPX3lb6qTzHtEnk01PmhaNVEbpPuCQHgaIfx33/SdODqTtlG3Y= =OQMF -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773354: please add breaks: live-tools ( 4.0.1-1)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I don't quite understand what's happening in this bug. How do we get from calling update-initramfs to an error trying to execute update-initramfs.orig.initramfs-tools instead? For that matter, instead of directly executing update-initramfs, shouldn't we be using a dpkg trigger? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJUkZSVAAoJENRVrw2cjl5RojMH/1lGFkCM+FdvBL+9Y77V9O+T o+RVZitkYpBWpPGoQ4RjjY8B6YoaOl4QppvMN+1jpfV2+u3cA7Rq6+INB+RGvtD2 UN6ZmHAdpuPyTAiXERkHqfMJ0+FNHmE0RJGGkcMpuhQ4emFWfe97KNApe3MzJ+XN evIkPi5rlM5P7fxSZunR7F9bOnZD09g34FW9Kwdhud/aIA8qdcyComW8qtGJZlse NzO6jlH11aLcFv5d2JGJShrBKePilngeXe8RcCptueAf6ny7t0bvroLreLKPe37g rtgF+1nyGKG3pYHwLV9dyKXp8I26iUJ1gwGQ5Qo4upBGv4+hLeg+SK9dv8IBte4= =BMUY -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
