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
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
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.
>
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
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.
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
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
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
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
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
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
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
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
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
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
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
&g
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
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
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
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
>
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
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.
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
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.
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.
I disabled wayland in /etc/gdm3/daemon.conf and and keyboard input works
fine in X11.
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.
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 )
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.
Kyle B writes:
> (gpartedbin:11049): Gtk-WARNING **: 09:04:39.901: cannot open display:
What display server / desktop environment are you using?
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
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
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,
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
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.
>
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
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
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 ),
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
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
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
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
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]
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
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
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
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
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.
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
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
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
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
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
>
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
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?
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.
-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-
-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
-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
-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,
Package: general
This is a test of the BTS, please ignore.
-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
>>
-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
-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.
-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
-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
-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
-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
-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
-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
-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
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]
-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
-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
-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
-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
-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
-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
-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,
-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
-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
-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
-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
-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
-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
-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
-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
: 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
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
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
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
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
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
-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
-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
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
-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.
-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:
-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
-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,
1 - 100 of 393 matches
Mail list logo
