Bug#542448: (no subject)
This bug is labeled as having a patch attached, but as far as I can see, does not. Is there some information we can provide to help understand the location of the problem? -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Please unblock eglibc/2.9-25
X-Mailer: Mutt 1.5.18 (2008-05-17) eglibc 2.9-25 is now in unstable for 10 days without new major bugs. It introduces the libc6 package split into libc6 + libc-bin, and libc6-dev into libc6-dev + libc-dev-bin in preparation for multiarch. Could you please unblock it? Thanks in advance, Aurelien -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please unblock eglibc/2.9-25
* Aurelien Jarno (aurel...@aurel32.net) [090828 14:17]: eglibc 2.9-25 is now in unstable for 10 days without new major bugs. It introduces the libc6 package split into libc6 + libc-bin, and libc6-dev into libc6-dev + libc-dev-bin in preparation for multiarch. Could you please unblock it? done. Cheers, Andi -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#543786: partman-auto-raid: having to name devices explicitly is clumsy
On Wed, Aug 26, 2009 at 11:09:47PM +0100, Colin Watson wrote: Attached is a patch which introduces new syntax, looking like this: Any comments? I think this is a noticeable improvement, so I'll commit it next week or so if there are no objections. ENOPATCH. :-) The concept sounds good to me. It might be applicable to other parts of partman, too. Max -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#491376: recipe for BIOS-based boot on gpt
Firstly, at this point I am thoroughly convinced that something like
this patch is necessary, and I think the tone being taken with the
original submitter has been out of order; driving people away from
making improvements to d-i is not what we want to do, considering our
limited developer base! Yes, we should make sure that patches are
necessary, since all maintenance has a cost, but we should also
demonstrate a little more respect for the judgement of our fellow
developers and remember that there is a substantial difference in tone
between I'm trying to understand why this is needed and huge NACK,
even if we are stressed out trying to produce something releaseable.
With that out of the way:
On Sun, Aug 10, 2008 at 03:29:16AM +0200, Robert Millan wrote:
On Sat, Aug 09, 2008 at 10:17:34PM +0200, Frans Pop wrote:
1) The use-case is insufficiently clear
The reason _why_ a separate partition is required at all has (at least for
me) not been sufficiently explained. So far my impression is that all
this is just one huge ugly hack needed when GPT and some otherwise
undefined BIOS-based bootloader are combined, but I have no idea yet
for which type of systems that would be.
I may be completely wrong, but it's up to the submitter to provide
sufficient information. Instead we only get hackish patches without the
context.
The whole purpose of this is solving a problem (whose technical details I
have explained in #488111), that will affect all users who install Debian on
standard PCs in the near future, when disks get bigger.
In short, we need somewhere to put GRUB 2's core.img on GPT that isn't
just sticking it in a filesystem, since the latter means GRUB's boot
sector needs to be able to find the filesystem in order to load bits of
itself and there isn't room in the boot sector to implement reliable
mechanisms for that (e.g. UUIDs). This is particularly problematic on
multi-disk setups.
http://grub.enbug.org/BIOS_Boot_Partition has a good, longer,
explanation.
- ensure it is created *only* in that use-case
My last patch does that; except for GRUB, but then again there's no way to
tell at the partitioning stage if user will want to use LILO.
Yes, and we certainly don't want to bail out at the boot loader
installation stage because the partitioning was wrong ...
In any case, GRUB is overwhelmingly the common case for d-i particularly
now that GRUB 2 can cope with /boot on LVM, so I don't think this minor,
non-installation-blocking issue should get in our way.
If the flag and this partition _are_ related then partman should ensure
that the BIOS boot partition flag can only be set on a BIOS boot
partition and not on any random other partition.
There's no flag. This is just the way Parted exports it to the upper
layer. For example, if you set the boot flag in a GPT partition, you get
an EFI partition type.
If the BIOS boot partition needs to be a separate partition because its
usage means any file system data could get overwritten, then partman
should ensure that such a partition cannot be used for a file system. The
current flag does not do that.
I'll fix that.
The correct approach here, I think, is to use a partman method instead.
That ensures that a partition can contain a filesystem or a BIOS boot
area, but not both. This also makes preseeding a lot easier - we don't
need a special-cased $bios_boot{ } internal specifier any more, but can
just set the method in the natural way.
See my first attached patch. In particular I'd like translator comments
on the slight textual changes; Christian?
In future, we perhaps also ought to add a check.d script to
grub-installer to have it verify that a bios_grub partition exists when
on GPT. Not having it is no worse than the present situation, though.
My current feeling is that if it is demonstrated after that that a
separate bootloader partition really is needed, it should either
- be added based on the detection of a separate subarch (and thus
*separate* recipes), or
It's not a subarch, as explained.
Indeed, a subarch would be entirely wrong here. i386 with DOS partition
table is not necessarily a different subarchitecture from i386 with
GPT partition table; this is most easily demonstrated by the fact that
the very same system will use DOS or GPT by default depending on whether
the disk is in excess of 2TB, or indeed that the very same system might
be given one or the other partition table type on a pre-existing disk.
I agree with Frans' earlier comment that there are good reasons to
continue to use the default recipes for i386 and amd64.
- be added at runtime on top of a normal, clean recipe based on very
specific and targeted tests (similar to the way a /boot partition is
added automatically when LVM is used).
I did this already (Jérémy requested), except on buildtime.
Shall I move it to runtime?
Given that this is much more specific to GPT than to the x86
Bug#543786: partman-auto-raid: having to name devices explicitly is clumsy
On Fri, Aug 28, 2009 at 02:53:56PM +0200, Max Vozeler wrote:
On Wed, Aug 26, 2009 at 11:09:47PM +0100, Colin Watson wrote:
Attached is a patch which introduces new syntax, looking like this:
Any comments? I think this is a noticeable improvement, so I'll commit
it next week or so if there are no objections.
ENOPATCH. :-)
Gah. One of these days I'll make my mailer automatically whine at me if
I do that.
Really attached now.
--
Colin Watson [cjwat...@debian.org]
Index: debian/changelog
===
--- debian/changelog (revision 60467)
+++ debian/changelog (working copy)
@@ -2,6 +2,9 @@
* Stop documenting devfs syntax in README.
* Upgrade to debhelper v7.
+ * Add raidid= syntax to partman-auto-raid/recipe to make it possible to
+preseed RAID creation without having to guess partition device names in
+advance.
-- Colin Watson cjwat...@debian.org Wed, 26 Aug 2009 17:56:38 +0100
Index: auto-raidcfg
===
--- auto-raidcfg (revision 60467)
+++ auto-raidcfg (working copy)
@@ -4,6 +4,20 @@
# Mostly based on mdcfg
+expand_raidid() {
+ new_raid_devices=
+ for raid_device; do
+ if [ ${raid_device#raidid=} != $raid_device ]; then
+ for match in $(cat /var/lib/partman/raidids/${raid_device#raidid=}); do
+new_raid_devices=${new_raid_devices:+$new_raid_devices }$match
+ done
+ else
+ new_raid_devices=${new_raid_devices:+$new_raid_devices }$raid_device
+ fi
+ done
+ echo $new_raid_devices
+}
+
create_raid() {
RAID_TYPE=$1
DEV_COUNT=$2
@@ -21,12 +35,14 @@
FS_TYPE=$4
MOUNTPOINT=$5
- DEVICES=$6
+ RAID_DEVICES=$6
SPARE_DEVICES=$7
- RAID_DEVICES=$(echo $DEVICES | sed -e s/#/ /g)
+ RAID_DEVICES=$(echo $RAID_DEVICES | sed -e s/#/ /g)
+ RAID_DEVICES=$(expand_raidid $RAID_DEVICES)
SPARE_DEVICES=$(echo $SPARE_DEVICES | sed -e s/#/ /g)
+ SPARE_DEVICES=$(expand_raidid $SPARE_DEVICES)
NAMED_SPARES=$(echo $SPARE_DEVICES | wc -w)
Index: display.d/initial_auto_raid
===
--- display.d/initial_auto_raid (revision 60467)
+++ display.d/initial_auto_raid (working copy)
@@ -16,6 +16,22 @@
mkdir -p /var/lib/partman
touch /var/lib/partman/initial_auto_raid
+# Look around for raidids before stopping parted_server
+rm -rf /var/lib/partman/raidids
+mkdir -p /var/lib/partman/raidids
+for dev in $DEVICES/*; do
+ [ -d $dev ] || continue
+ cd $dev
+ open_dialog PARTITIONS
+ while { read_line num id size type fs path name; [ $id ]; }; do
+ [ -f $id/raidid ] || continue
+ raidid=$(cat $id/raidid)
+ echo $path /var/lib/partman/raidids/$raidid
+ done
+ close_dialog
+done
+cd /
+
confirm_changes partman-md || exit 1
commit_changes partman/text/commit_failed || exit $?
Index: README
===
--- README (revision 60467)
+++ README (working copy)
@@ -38,13 +38,12 @@
d-i partman-auto/disk string /dev/sda /dev/sdb
+# raidid can be anything, as long as it doesn't contain spaces or slashes
+# and matches something in raidid{ } in partman-auto/expert_recipe. You can
+# use hash separated lists of ordinary device names instead if you prefer.
d-i partman-auto-raid/recipe string \
- 1 2 0 ext3 /boot\
- /dev/sda1#/dev/sdb1 \
- . \
- 1 2 0 lvm - \
- /dev/sda5#/dev/sdb5 \
- .
+ 1 2 0 ext3 /boot raidid=1 . \
+ 1 2 0 lvm - raidid=2 .
# Please note that RAID partitions are tagged as lvmignore
# and LVM logical volumes as defaultignore and lvmok.
@@ -54,10 +53,12 @@
$lvmignore{ } \
$primary{ } \
method{ raid } \
+ raidid{ 1 } \
. \
900 5000 4000 raid \
$lvmignore{ } \
method{ raid } \
+ raidid{ 2 } \
. \
700 5000 4000 ext3 \
$defaultignore{ } \
Bug#491376: recipe for BIOS-based boot on gpt
On Fri, Aug 28, 2009 at 02:10:42PM +0100, Colin Watson wrote: Firstly, at this point I am thoroughly convinced that something like this patch is necessary, and I think the tone being taken with the original submitter has been out of order; driving people away from making improvements to d-i is not what we want to do, considering our limited developer base! Yes, we should make sure that patches are necessary, since all maintenance has a cost, but we should also demonstrate a little more respect for the judgement of our fellow developers and remember that there is a substantial difference in tone between I'm trying to understand why this is needed and huge NACK, even if we are stressed out trying to produce something releaseable. Thanks Colin. I see that you're already on track on getting the implementation details right. I don't think I'm the most indicate to comment on your changes to partman internals, but I remain at your disposal in case there's any doubts about the GRUB side of things that need be resolved. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#540023: cdrom: netinst installation might freeze with out-of-date keyring
Hello, The option debian-installer/allow_unauthenticated=true does not help. A customer told me he tried it (with installgui) and he did get an mixed installation with lenny in sources.list, 2.6.18 kernel from Etch, and OpenOfficeOrg 2.4 from Lenny. I think the full-installer is the only option to install oldstable. With regards, Paul van der Vlis. -- http://www.vandervlis.nl/ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Problems with kernel 2.6.26-2-686-bigmem
Hi, I'm trying to get Debian (Lenny) to recognize 6 Gig of memory on a Dell PE 2650 server. I installed the basic 5.02a Debian system with just a minimal install then I installed the 2.6.26-2-686-bigmem kernel so it will see all the memory. When I boot into the bigmem kernel it fails to boot, the errors I get are: WARNING boot device may be renamed. Try root=/dev/hda3 ... ALERT! /dev/sda3 does not exist To see a snapshot of the full error goto: http://www.amwestonline.com/error/DSC07082.JPG Booting into the regular 2.6.26-2-686 kernel works just fine, but I only see 4 gig of memory. After the error it drops me into a shell I can see that /dev/hda3 does not exist. This system is setup with Raid 5. I've been struggling with this for over a week now so any help would be greatly appreciated. Thanks, David [Sorry about the cross posting, I'm trying to get to as wide an audience as possible.] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Problems with kernel 2.6.26-2-686-bigmem
David Vanfleet wrote: Hi, I'm trying to get Debian (Lenny) to recognize 6 Gig of memory on a Dell PE 2650 server. I installed the basic 5.02a Debian system with just a minimal install then I installed the 2.6.26-2-686-bigmem kernel so it will see all the memory. When I boot into the bigmem kernel it fails to boot, the errors I get are: WARNING boot device may be renamed. Try root=/dev/hda3 ... ALERT! /dev/sda3 does not exist Did you try with changing the root device for the bigmem kernel to /dev/hda3? If you use grub for booting you could do that by pressing 'e' (for edit on the line with the bigmem kernel) and afterwards pressing 'b' (for boot) while in the grub menu (to just try it) or updating /boot/grub/menu.lst (for the bigmem kernel) and running update-grub before rebooting into the bigmem kernel. Cheers Luk -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Problems with kernel 2.6.26-2-686-bigmem
Luk Claes wrote: David Vanfleet wrote: Hi, I'm trying to get Debian (Lenny) to recognize 6 Gig of memory on a Dell PE 2650 server. I installed the basic 5.02a Debian system with just a minimal install then I installed the 2.6.26-2-686-bigmem kernel so it will see all the memory. When I boot into the bigmem kernel it fails to boot, the errors I get are: WARNING boot device may be renamed. Try root=/dev/hda3 ... ALERT! /dev/sda3 does not exist Did you try with changing the root device for the bigmem kernel to /dev/hda3? If you use grub for booting you could do that by pressing 'e' (for edit on the line with the bigmem kernel) and afterwards pressing 'b' (for boot) while in the grub menu (to just try it) or updating /boot/grub/menu.lst (for the bigmem kernel) and running update-grub before rebooting into the bigmem kernel. Thanks for your response, I did try what you suggested but got the same error, except it says that "/dev/hda3 does not exist". Looking in /dev there is no sda* or hda*, there only an hda which I think is the CD drive. When I boot to the default Kernel then /dev/sda3 exists and is used to boot the kernel. Any other ideas? Thanks, David -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
diff is now diffutils
Hello. The diff binary package has been renamed diffutils. The diff package is now dummy and depends on diffutils, so nothing should break because of this change. However, you might want to adjust debootstrap and similar tools so that they don't install obsolete dummy packages. Thanks. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: diff is now diffutils
Hi Santiago, On Friday 28 August 2009, Santiago Vila wrote: The diff binary package has been renamed diffutils. The diff package is now dummy and depends on diffutils, so nothing should break because of this change. However, you might want to adjust debootstrap and similar tools so that they don't install obsolete dummy packages. Nothing installs diff by name (base system packages get installed based on their priority, not some explicit list), but thanks for the heads up. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
[D-I Manual] String freeze / Last call to update translations
On Sunday 16 August 2009, Frans Pop wrote: For this release, translators are requested to update their translations. The deadline is in two weeks: *** Sunday August 30 ***. Which leaves *only this weekend* for those who'd like their translation to be up-to-date for this release. Seven translations are now at 100%. My thanks to their translators! And the Spanish translators have announced they've started work. That leaves the following: Brazilian, Catalan, Chinese (simplified), Greek, Finnish, Japanese, Korean, Swedish and Vietnamese. As mentioned in the initial call, I will not drop translations that are not up-to-date in this release. Current status can, as always, be found at: http://d-i.alioth.debian.org/manual/ Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
ceza ödemeyin
iyi günler, Eğer aracınızın muayenesi yoksa ve trafik kontrolune yakalanırsanız; 1 Araç ruhsatı sizin adına değilse otomobiliniz direk parka çekilir 2 Ruhsat sahibi sizseniz önce 62 tl ceza öderseniz sonra 15 günlük muayene müsade belgesi alarak muayenenizi aylık % 5 ceza ile yaptırısınız. Özet olarak siz uğraşmayın gelin bizhalledelim. Ankara'nın muayene merkezi bizhalledelim.com adresten alıp adrese teslim hizmet. ÖNEMLİ NOT : Eğer araç veya araçlarınızın birikmiş vergi borcu varsa ,lpg montajı yaptıracaksanız hatta sadece muayene işleminiz bile varsa hepsini vade farkını ödeyerek kredi kartınıza 24 aya kadar taksitlendirebilirsiniz. Saygılar Güven NOYAN 0 312 442 19 20 0 554 385 1900 i...@bizhalledelim.com www.bizhalledelim.com www.viraoto.com.tr
Bug#544114: installation-reports: No networking on Dell Vostro 1320
Package: installation-reports Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 eth0 is detected but the installer fails to get a DHCP response from the server. Configuring the network manually also does not work.. The network card is: 08:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev 03) Kernel driver in use: r8169 Kernel modules: r8169 Network-related kernel messages: r8169 Gigabit Ethernet driver 2.2LK-NAPI loaded ACPI: PCI Interrupt :08:00.0[A] - GSI 17 (level, low) - IRQ 17 PCI: Setting latency timer of device :08:00.0 to 64 r8169: :08:00.0: unknown MAC (2b1000c0) eth0: RTL8169 at 0xc236e000, 00:24:e8:c2:9e:5b, XID 281000c0 ORQ 1282 - -- Package-specific info: Boot method: DVD Image version: Lenny 5.0.2 amd64 Date: Sat Aug 29 00:20:04 BST 2009 Machine: Dell Vostro 1320 Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [E] Detect CD: [ ] Load installer modules: [ ] Detect hard drives: [ ] Partition hard drives: [ ] Install base system:[ ] Clock/timezone setup: [ ] User/password setup:[ ] Install tasks: [ ] Install boot loader:[ ] Overall install:[ ] - -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (430, 'testing'), (420, 'unstable'), (410, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqYZx0ACgkQshl/216gEHifCgCgoKSow82b6Z83UqDceCtMgesO 7psAn21sA+e0i6FihSLX71ZcET1n2sWL =F8we -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544120: debootstrap: --make-tarball yields exit value 1 (one)
Package: debootstrap Version: 1.0.10lenny1 Severity: important The following perfectly valid and correct usage # debootstrap --include host --exclude laptop-detect \ --arch i386 --make-tarball ./packs.tgz \ etch /mnt/ http://host-of-choice/debian/ completes with return value 1, thus preventing its use in a GNU Makefile, unless error checking is avoided on the above statement. This must be judged as a major impediment and undesirable behaviour. The mandatory full file path demanded by --unpack-tarball in version 1.0.10lenny1, contrasted to the relative path accepted bu --make-tarball, is likewise annoying, but is easier to detect and circumvent in standard ways. -- System Information: Debian Release: 5.0.2 APT prefers stable APT policy: (500, 'stable'), (90, 'testing'), (80, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-686 (SMP w/1 CPU core) Locale: LANG=sv_SE.ISO-8859-15, LC_CTYPE=sv_SE.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages debootstrap depends on: ii binutils2.18.1~cvs20080103-7 The GNU assembler, linker and bina ii wget1.11.4-2 retrieves files from the web debootstrap recommends no packages. debootstrap 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
please unblock libpng 1.2.39-1 pciutils 1:3.1.4-1 rdate 1:1.2-4 (udebs)
please unblock libpng 1.2.39-1 Changes: libpng (1.2.39-1) unstable; urgency=low . * New upstream release * Fix out-of-date-standards-version * Fix patch-system-but-no-source-readme please unblock pciutils 1:3.1.4-1 Changes: pciutils (1:3.1.4-1) unstable; urgency=low . * New upstream version * Fix out-of-date-standards-version * Update pci.ids with snapshot dated 2009-08-18 03:15:02 please unblock rdate 1:1.2-4 Changes: rdate (1:1.2-4) unstable; urgency=low . * Connect to an NTP server over IPv6 Patch by Jakub Wilk Closes: 515219 * Fix out-of-date-standards-version * Fix patch-system-but-no-source-readme * Update debian/watch signature.asc Description: Digital signature
