Bug#777439: Jessie DI-rc1 amd64 after installation no network interfaces
On Tue, 10 Feb 2015 17:47:01 +0100 Holger Wansing wrote: > This is getting confusing: > In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777439#35 you wrote, > that you have done a shell-only install (no desktop environment). > Now you write, that you have kde and network-manager installed. > ??? > Without the installer logs there is no chance to get this sorted out. > Sorry, I have install only the shell with the debian installer and have than with apt-get install kde., after installing the shell. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1750089.DSIBQXjoDo@debian
Processed: Re: Bug#777740: debian-installer: Default keyboard is not set for Korean language
Processing commands for cont...@bugs.debian.org: > reassign 40 console-setup Bug #40 [debian-installer] debian-installer: Default keyboard is not set for Korean language Bug reassigned from package 'debian-installer' to 'console-setup'. Ignoring request to alter found versions of bug #40 to the same values previously set Ignoring request to alter fixed versions of bug #40 to the same values previously set > thanks Stopping processing here. Please contact me if you need assistance. -- 40: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=40 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.c.1423720583752.transcr...@bugs.debian.org
Bug#777740: debian-installer: Default keyboard is not set for Korean language
reassign 40 console-setup thanks Quoting Changwoo Ryu (cw...@debian.org): >Like other languages, it should choose the default kr keymap. > > I have no idea which package decides the default keyboard for a given > language. I added Korean default in console-setup package, in #756052. > But it doesn't seem to change d-i. Still, the package responsible for this is console-setup. Hence reassigning, though I have no idea why things don't work as expected... signature.asc Description: Digital signature
Bug#777740: debian-installer: Default keyboard is not set for Korean language
Package: debian-installer Severity: normal Dear D-I team, Currently on jessie d-i, it always asks keyboard to use when I select Korean language. * What led up to the situation? Select Korean language and proceed * What was the outcome of this action? It asks keyboard type, presenting the full list of available keyboards. * What outcome did you expect instead? Like other languages, it should choose the default kr keymap. I have no idea which package decides the default keyboard for a given language. I added Korean default in console-setup package, in #756052. But it doesn't seem to change d-i. -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/3 CPU cores) Locale: LANG=ko_KR.UTF-8, LC_CTYPE=ko_KR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1423719638.7502.1.ca...@debian.org
Bug#777716: [jessie RC1] wireless LAN card not usable, problem with loading/using firmware
Package: installation-reports I have a laptop here which needs firmware for the wireless LAN card Intel PRO/Wireless LAN 2100 3B Mini PCI Adapter (PCI-ID: 8086:1043). It seems the process of requesting, loading and using firmware is not fully functional: When it comes to the d-i step "Detecting network hardware", there is lot of output on the 4th console regarding "BUG: unable to handle kernel paging request at ce8ec00c" and "Oops: 0002 [#1] and "Call Trace:" " ? ipw2100_down+0x9e/ox10 [ipw2100] and the like. I have attached a syslog of this installation try. But I am able to proceed with the installation steps, d-i requests firmware file, so I plug in my usbstick, the relevant firmware package is installed (the firmware files end up in /lib/firmware), but the device is not able to operate. It is not shown in the list of available network devices in the d-i UI. To investigate this, I started the installation again, but before the step "Detect network hardware" is started, I mount my usbstick, copy the needed firmware file into /lib/firmware by hand and then start the step "Detect network hardware". And now the device is working, it is shown as available nework device, it scans and shows available WLANs, so the hardware seems to work. So it calms down to the firmware not being available, when the module is loaded. (Please note, that the needed firmware is detected correctly, and the correct package is installed, so the newly created way of detecting missing firmware seems to work fine!) Regards Holger -- Created with Sylpheed 3.2.0 under D E B I A N L I N U X 7 . 0 W H E E Z Y ! Registered Linux User #311290 - https://linuxcounter.net/ firmware-problem.dmesg Description: Binary data
Processed: update attri
Processing commands for cont...@bugs.debian.org: > tags 777578 - moreinfo Bug #777578 [partman-btrfs] btrfs-tools not always installed with btrfs root Removed tag(s) moreinfo. > severity 777578 important Bug #777578 [partman-btrfs] btrfs-tools not always installed with btrfs root Severity set to 'important' from 'normal' > End of message, stopping processing here. Please contact me if you need assistance. -- 777578: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777578 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.c.14236849239350.transcr...@bugs.debian.org
Processed: Re: no cryptsetup in initrd when btrfs selected
Processing control commands:
> close -1
Bug #777650 [partman-crypto] no cryptsetup in initrd when btrfs selected
Marked Bug as done
> archive -1
Bug #777650 {Done: jnqnfe } [partman-crypto] no cryptsetup in
initrd when btrfs selected
archived 777650 to archive/50 (from 777650)
--
777650: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777650
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/handler.s.b777650.1423683785779.transcr...@bugs.debian.org
Bug#777650: no cryptsetup in initrd when btrfs selected
Control: close -1 Control: archive -1 As identified in bug #777578, btrfs-tools was not installed during the installation, which was the real cause of the issues I was experiencing. So on the assumption that a resolution to that issue would successfully allow cryptsetup to be added to the initrd with a btrfs + luks install, just as with an ext4 + luks install, I will close and archive this. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54dbb0be.9030...@gmail.com
Bug#777578: initramfs-tools: update-initramfs fails with btrfs
On 11/02/2015 18:42, Ben Hutchings wrote: > So the root (no pun intended) of the problem is that btrfs-tools was > not installed. Ben. Ah ha, you're absolutely right, I assumed it was but it is indeed not installed. Thanks for that. Yep, now it boots successfully :D -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54dbaf87.1010...@gmail.com
Processed: Re: initramfs-tools: update-initramfs fails with btrfs
Processing control commands: > retitle -1 btrfs-tools not always installed with btrfs root Bug #777578 [initramfs-tools] update-initramfs in chroot fails with btrfs Changed Bug title to 'btrfs-tools not always installed with btrfs root' from 'update-initramfs in chroot fails with btrfs' > reassign -1 partman-btrfs Bug #777578 [initramfs-tools] btrfs-tools not always installed with btrfs root Bug reassigned from package 'initramfs-tools' to 'partman-btrfs'. Ignoring request to alter found versions of bug #777578 to the same values previously set Ignoring request to alter fixed versions of bug #777578 to the same values previously set -- 777578: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777578 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.b777578.142368015010242.transcr...@bugs.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-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54db9afa.1060...@gmail.com
Bug#708722: initramfs-tools: update-initramfs fails with btrfs
On 11/02/2015 05:05, Ben Hutchings wrote: > On Wed, 2015-02-11 at 03:04 +, jnqnfe wrote: >> I think that my issues might all stem from initramfs-tools, so >> reassigning. > I don't think so - other packages hook into initramfs-tools and are > quite capable of breaking it. I see, I wasn't aware of that. > What are the error messages? When executing update-initramfs -u in a chroot via a live CD, I get: update-initramfs: Generating /boot/initrd.img-3.16.0-4-amd64 cryptsetup: WARNING: could not determine root device from /etc/fstab Warning: /sbin/fsck.btrfs doesn't exist, can't install to initramfs, ignoring. More details of the setup are described in the following mailing list message (please ignore issue #1), including fstab, crypttab contents and blkid output: https://lists.debian.org/debian-user/2015/02/msg00323.html (please excuse the use of '' in the UUID's, I couldn't be bothered to type them all out in full) The filesystem after installation does contain an install of cryptsetup, just no copy in initrd. I added 'cryptsetup' into the /etc/initramfs-tools/modules file before executing update-initramfs -u, resulting in the above output, and no cryptsetup binary or config files present in the /boot initrd image. >> Secondly, the other issue I believe is due to the initrd created by >> debian-installer missing at least cryptsetup; I believe >> debian-installer runs update-initramfs towards the end, so perhaps >> this is where debian-installer is trying to add things like cryptsetup >> to initrd, and it is actually silently failing here due to same issue >> above. > initramfs-tools doesn't make that decision - cryptsetup does. And if > cryptsetup isn't installed or configured properly, that's the fault of > partman-crypto. I'm not going to dispute whether the fault lies with initramfs-tools or partman-crypto, because I don't have a clue. All I know at this time is that comparing two VM installs, one using luks + btrfs and one using luks + ext4, otherwise identical, the btrfs one lacks cryptsetup in its initrd after installation, causing boot failure, while the ext4 one is fine, and using a live CD + chroot to try to fix things via update-initramfs, the tool runs fine on the ext4 install, but fails on the btrfs install. I am guessing that both problems have a common cause. Thank you for taking some time to respond to my issue. I appreciate any help you can offer in resolving it. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54db8d15.9080...@gmail.com
Bug#777647: partman-efi always complains when installing from usb
On Wed, Feb 11, 2015 at 11:39:00AM -0500, Phillip Susi wrote: >On 2/11/2015 4:38 AM, Steve McIntyre wrote: > >> 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. That caching worries me, I'll be honest... >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. 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? >Hrm... I'll do some more debugging tonight. Cool. -- Steve McIntyre, Cambridge, UK.st...@einval.com There's no sensation to compare with this Suspended animation, A state of bliss -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150211164702.gq8...@einval.com
Bug#777702: os-prober seems to hang, but is actually reading entire partition when a partition is not mounted
Package: os-prober Version: 1.65 Severity: important Tags: d-i Dear Maintainer, I've found that 'update-grub' in jessie which calls 'os-prober', reads what seems to be the entire partition if it isn't mounted. I've tested this on both ext3 partitions in LVM and a btrfs partition. I am unsure if this occurs on an ordinary non-lvm partition. This would likely break the upgrade for any user upgrading to jessie, as the read speed I experienced was less than 30GB/h which is close to forever for any reasonably sized partition. As a result, grub is not updated and the new kernel with jessie can not be loaded. Please feel free to reply at clintonm...@gmail.com if you require any further details. Clinton -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages os-prober depends on: ii libc6 2.19-13 os-prober recommends no packages. os-prober suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150211163801.10782.87391.report...@clintonsdesktop.home
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-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54db85a4.9050...@gmail.com
Bug#777647: partman-efi always complains when installing from usb
Control: tag -1 moreinfo On Wed, Feb 11, 2015 at 08:33:29AM +, Steve McIntyre wrote: >On Tue, Feb 10, 2015 at 10:30:32PM -0500, Phillip Susi wrote: >>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. > >Ugh. :-( > >I'm just about to go on VAC for a few weeks, it's going to be >difficult to find time to try and fix this. Help would be very >welcome! 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. 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? -- Steve McIntyre, Cambridge, UK.st...@einval.com You lock the door And throw away the key There's someone in my head but it's not me -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150211093817.gp8...@einval.com
Processed: Re: Bug#777647: partman-efi always complains when installing from usb
Processing control commands: > tag -1 moreinfo Bug #777647 [partman-efi] partman-efi always complains when installing from usb Added tag(s) moreinfo. -- 777647: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777647 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.b777647.142364756117366.transcr...@bugs.debian.org
grub-installer_1.110_i386.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 11 Feb 2015 06:50:00 +0100 Source: grub-installer Binary: grub-installer Architecture: source i386 Version: 1.110 Distribution: unstable Urgency: low Maintainer: Debian Install System Team Changed-By: Christian Perrier Description: grub-installer - Install GRUB on a hard disk (udeb) Changes: grub-installer (1.110) unstable; urgency=low . [ Updated translations ] * Polish (pl.po) by Michał Kułach Checksums-Sha1: 08960c11799f8486cbce8d7e1f40a2de47e3d4f6 1955 grub-installer_1.110.dsc 790f45a11096e76fd2c2292f2ee1dc6d813ce4f0 203688 grub-installer_1.110.tar.xz bd931b88ac7ce8ba4701cbc71bb6da120b6c78ec 274786 grub-installer_1.110_i386.udeb Checksums-Sha256: a434e4614d696bc051305e436b6aee36add2d8c360b89b5f4521cd8dd350fa99 1955 grub-installer_1.110.dsc 64860c1026d5703a3e85bacab4a34dbc8c8af52487c35590a63d5f4774a99a47 203688 grub-installer_1.110.tar.xz b65639c92b1dba8f33a580f9a46536619705729af14f24c1f09ee2ad1a6ee5c8 274786 grub-installer_1.110_i386.udeb Files: 1fe500391915a699f2d5bf428ab9a317 1955 debian-installer standard grub-installer_1.110.dsc 00d05027c26d038ffa4e1162e9782e5f 203688 debian-installer standard grub-installer_1.110.tar.xz c00074d9379da8ce41c4dd76a160ab77 274786 debian-installer standard grub-installer_1.110_i386.udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJU2wq+AAoJEIcvcCxNbiWoaYkQAJdrpPv8Ghvu0siRqanA+W9g prnL81aWluVKjZ54UcRjcZ8ZCeMD0qzp4ESwoCMFf9EBehCJE4oWswnKGOeNouiq X0YSVEaQ4NxtEjMxsTfD/MFQ8ilW2R4x+HCOWuoxVZHp/GfhHUlqTxIvs77HBnjq xP7jwE/v/p3pkFYLX3ApYodMdArr0b7BJ2ayoQ3Dlv5BsvfUmimkzD6SnYODWkQb BqXsP8SWcMWyr0aWjUv+PlUCj05QLWrPUtX9OHN9WqjyebRizCDTtgets9LjI/e6 7ipv3zwlc6JdDK+aiS12E4nGt3L6D5ugzXs5zN0B+RaUaXzS9feTU013zNUU5Osg 1yx5CsFa2RJ2VS/4tJiKLNgjYHbJi/InWamiCgaABiZPUEcBlAcm65ZcF9Ggikpd EMI4DNdgx+2uQy3ANfntcR2gtU/1IZxTbidZ9yfYo9QORs+1rVj9usUpTdRHiw01 S1pL3OnUaYuwvAFiHTd1U5XbkSABYuFZHgsOFzyFmjp2H6bX8yF8K5V2keihmGCZ XfdxJaxIkUFqO62VPgSVOyFPhdG6wFLe/zHJtqkOVxB6fSy7T1KhiKImyiBPEWVy Kukrrp7m4GOsDwUmqMOXD3b/ZceWfgi1wIgItPH5ee4hp3v0bYpbnVFRY0fT9nA5 bYnrlVEhWFdN6LQHV15Z =TDek -END PGP SIGNATURE- Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1yltto-0003iw...@franck.debian.org
Bug#777647: partman-efi always complains when installing from usb
On Tue, Feb 10, 2015 at 10:30:32PM -0500, Phillip Susi wrote: >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. Ugh. :-( I'm just about to go on VAC for a few weeks, it's going to be difficult to find time to try and fix this. Help would be very welcome! -- Steve McIntyre, Cambridge, UK.st...@einval.com "C++ ate my sanity" -- Jon Rabone -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150211083329.ga25...@einval.com
Processing of grub-installer_1.110_i386.changes
grub-installer_1.110_i386.changes uploaded successfully to localhost along with the files: grub-installer_1.110.dsc grub-installer_1.110.tar.xz grub-installer_1.110_i386.udeb Greetings, Your Debian queue daemon (running on host franck.debian.org) -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1ylsep-0002gz...@franck.debian.org
Processing of grub-installer_1.110_i386.changes
grub-installer_1.110_i386.changes uploaded successfully to ftp-master.debian.org along with the files: grub-installer_1.110.dsc grub-installer_1.110.tar.xz grub-installer_1.110_i386.udeb Greetings, Your Debian queue daemon (running on host coccia.debian.org) -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1ylscc-0002n0...@coccia.debian.org
