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#1025568: marked as pending in gparted
Control: tag -1 pending Hello, Bug #1025568 in gparted reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/debian/gparted/-/commit/f64c86a0329ee2a0f8834058c32405832243bfdd Switch dependency from transitional polkit-1 to pkexec package (Closes: #1025568) (this message was generated automatically) -- Greetings https://bugs.debian.org/1025568
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#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#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#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#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#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#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-rc-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-rc-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-rc-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-rc-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-rc-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-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762236: parted: [kfreebsd] use of kern.geom.debugflags is unsafe
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/27/2014 7:49 PM, Colin Watson wrote: It does? linux_open appears to just open read-write, and only falls back to read-only if a read-write mount fails. I can't find anything special that arranges to do read-only mounts when write support isn't needed. Can you point me to the bit I'm missing? Goodness, you are right... I could have *sworn* I had seen code that reopened the disk r/w when required, but looking at it again it seems I was mistaken. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJUKXRTAAoJEI5FoCIzSKrw65gH/0UDQ16/a4XxhKPbQXFFmhEO Nlk8ub9W1fmFLkHle7QTm8FLkoG70fAUrSQxd/E4n9Yyr7K/ncdFfquG9TMOlTOR ZpdnkfKbTTy6fuDoxrYxK7Qz0aqHwnTzE8CcPeSRD2mmg6LCnJiZR1/9b7NaNIOa EvnX+84peYTaxfEJa6rfb+R1+kOYLf7HKpPb1X2qaiooiGQo3GP099ewZ3CLlQuq DCy6EbJOBSuiClQzLKmMmd2uoH82KZJC8EOLNyW7CkpBMV73vfF57+z2wWhCOJVD VfeksU88/oWssljYaZFYGpt+w4OHKKP3TxpP6xSycymbJTTtAX0pTHq9CxSmofw= =cXum -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762236: parted: [kfreebsd] use of kern.geom.debugflags is unsafe
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/19/2014 4:21 PM, Steven Chamberlain wrote: snip * opening O_RDWR and closing a disk device on FreeBSD, causes its partition tables to be rescanned (so, a 'commit' is implied - this also seems to be the cause of major slowness of partman in kfreebsd d-i, because it does this 'about' a hundred times in total) * the CAM layer handles this as a MEDIACHANGE event, it will DESTROY /dev devices for the disk partitions, and when scanning is complete, CREATE them again (perhaps similar to udev?) Umm... it seems to me that if you open your disk O_RDWR, for instance, to update your boot loader, while you have a partition on the disk mounted, and the kernel destroys an actively mounted partition device, then the kernel is very, very broken... As for the performance implications, yes, parted should not be using O_RDWR when it do doesn't need it and does take care not to on linux. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJUIB/6AAoJEI5FoCIzSKrwjE0H/3JiVspNyP2xm8qR5NFX0DYx Uhzufj4TkxtfwVRQkRmW8XAYJVqil/mUuP8/J2gbseujaB1qpafWGgek0XaSWEAj Rx4LsrjATwIqhudk4CxF0pV2idWQcoFYGYitRN8cowya13X7TcZBbLb6C77PL+ax B4Cy7eZrUWHpVXWEfRb1JeuRf29TpB88wzaB0nAg1UOYlyxbr2J4J8qtIF4O6hMi PlzbhQKJTwoIRIOWhGYXKet97khHM0KxIKMKNqdjVHhpXWVcKmFI/QoCZpsn3vX6 0OuIAjczMWgcn4sl2D8zc0dlQH4gWmnIC6Wk4aWzL5Q9Rg6yJhMmMxfTLn2EmRM= =8mDs -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743816: parted and partprobe segfault on various actions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I believe this is caused by the loop label changes I backported, which depend on fat and ntfs probing, which crashes for non 512 byte sector size disks. I have backported the required changes to fix that and sent the patch to Colin Watson to apply. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTQeFYAAoJEI5FoCIzSKrwJqIH/2w53hlKrR1S3cNcwkVXF1AX JQm6vEv4j4BwsxAvBVNwb/h9UdK9ZXDWE40Lokeha/dWHaxr1ZvEvT4nmgx8rqV+ Y1Hul8uFTtN6tTE5beXHPcAe8nfaLgg0WFSmISedpHtcgKWcW5lWVcEkLP6+Pv0c FZVJgAtzh9U7knT9pwFLmPnyz86/iAgrRKtwnL5Iwnpk5FUUKxdbyWoCyB0ZA6Ua sxV+nZROyrU+RuifvdmiFFTEn/URGl/5GHbfLAbwdyl0SWOUZj2cJQNIZXXZAu1S +p/fVFXlGu+nnuDvO3lKFAqex9+XdxucDo+ZGIBKErGsUv2SfsSc4Dxl1BTk+bs= =j7SC -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741842: parted: FTBFS: ../../parted/ui.c:1444:41: error: 'CPPFunction' undeclared (first use in this function)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03/16/2014 08:58 AM, David Suárez wrote: Hi, During a rebuild of all packages in sid, your package failed to build on amd64. On new readline versions old-style function typedefs have been deprecated. Yes, this was recently fixed upstream. Is there a rush to get this fixed in debian, or can it wait a bit? I'm hoping to get a new upstream release done and into debian soon (tm). -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTJhS3AAoJEI5FoCIzSKrwOI4H/2R9sbWBYchKfUIE4kCpRu9B n/zGn8X48bka+5jQxZf0k6+kPqeCXyYoELPVAddSfg6WBU4VWXfv7EterO4omW6R UKyxXmLE44sNpCZbmML3ukuIKUub3e5ey9J4+75/jBpRSlwVA3BRS1uO7PALv3BE 0qeoSlLV8sCZHyYT4gN4/1kezgFMkIIj56I3OYVZCwyqXQsS7ReJl2fZ638hOAqS fJXpUQfXMsAzvTj2siovDuTMxtRNHwtrmqyId7369OgFvbO4ysBjv58HWk4FvG8z UE7lIE0scSynj+b3G4nM3uOJhi2esrIQ4jB1zL637ZgkNbbZdwG+d+RKDue3Mms= =yIc9 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717239: partman-ufs: depends on obsolete package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It also depends on ufsutils-udeb, which is only built on kfreebsd. It seems to me that this package needs changed from all to kfreebsd only. This prevents building d-i monolithic images. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS+5SYAAoJEI5FoCIzSKrw13QIAI3M83yQ0JpLmOV5aEPwaVNI /aMG5EBLtLQaZDoLjtEXnIvddazS7dFZhaW5pboPdArEFD3l2OtpSTD5FSJbt5US dUKosgdsyErQ/TWgns89rXkxcpFB1qp823QeGnA3io6bGHeGkxzpAjOywqDXbPq1 rS8Kp1g1bGxg9o9A1XRPX85Z6EZOQgqx48DItU0UDOfOQDMZbTbGdZzp4YjP2d4h g9acd1hk/vUD0YyobPY/nmOkeaxEa2nduwOTVEzXVekU6d2nlGLULRU+Nt0YpUZg CLPBMKfyK/77JIkBZ0d1Rc1J1FtndhzV04GSUAZrN0xhqqZGlq/q2o5S7zJ6bCA= =/0GG -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#668920: (no subject)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 You install grub to the disks, not the raid array. dpkg-reconfigure grub-pc should have all of your disks checked, or at least the one your bios boots from. I believe this can be closed as NOTABUG. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPnEv/AAoJEJrBOlT6nu75YzMH/2c0ezpKhd7M7k83csOTZZcS SLSkKIDc6BAgjifRB25oILluBtI2lpnCqQogdJNCAEvSqB7SMWPqrQn12V+FHF1E ZePZvv7a/3BGXL8V/HDo3DQ4Z06Zum3Y23QhcN/z/AU/8eV2lYi1vHl+ALXLeZnV NdeIEszxJaHi4qmxNO4mMH3ME3pTU2LZLYnUF+Jy22zKmjfHhC1OY97i+X0wLdJZ e9ZFU5+zmYM7LXlaJRaocduBg8/EzUspbxQz4lne7HXKYyYDX8y+yGu5PvJc/GHb vK9AP8m+su85SUJ3V/m4ckcqp1P+a7eLkiLMcsQAntBzTAmAgyDFWyL6Ngg/BRM= =VS+z -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658316: [gparted] Menu item fails quietly
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/1/2012 6:41 PM, Filipus Klutiero wrote: Executing GParted by running gparted-pkexec in a console works, but there is interactivity due to a password request: That's how it is supposed to work. Furthermore, the Debian menu item, which uses su-to-root, apparently does not show. Where does this menu item come from? It should be using the .desktop file, which calls gparted-pkexec. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPMop2AAoJEJrBOlT6nu75E2YH+wdg8Hz9MK25yw8nuRhNJoiH VrNpB3vef8cyIBzKOfM1aRIQfD5XFynmIfG0dhlxXut57KUTeUptfCw1tywcQBd9 ZaiueFlO+3Cjax5bsHttfqHoiMWo4ZxEvoDEYYknGxim6QDhryHAzaPZnhkhCgJN 5OY5TduJzFEh0FAb3V/sU0rHAtukdwq8A/YCNYePIfcAsK42m+r2GTHGtcYYWmws d73YaEqnvo9aWmC67uI20nXRz8EHJALqYNNo+WIfJrvcVCidhMnYCmnDs+qxhdX/ nxpYGnZE8zN61ULu67DmQB0ZUJ9t2suiOXj/zuO5IxxrZou+p1lbP2lr68wYDis= =9R0P -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
