Bug#493865: cttyhack does not handle other serial devices than ttySn (was: Bug booting from console)

2008-08-09 Thread Frans Pop 
On Wednesday 06 August 2008, Jérémy Bobbio wrote:
> Bad news is that we probably have to modify
> /lib/debian-installer/init-udev-devices to create a file for every
> misc. serial line device.

I think someone should look into the option of starting udevd _before_ we 
run init (as also suggested by Marco in a recent discussion on IRC).

A good time to do this would be after the first boot debug shell, but 
before the second one.

> If that sounds like a good plan to solve this issue, feel free to block
> #484366 by #493865.

I don't have the motivation ATM to test your patch or work on this. Please 
do add the block as the issues are clearly related.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#494293: A bit more info...

2008-08-09 Thread Henk Koster 
I used the very same amd64-netinst.iso dated 6 August 2008 to install on
a newly built desktop computer, just a straight-forward install with
Desktop and Standard tasks. Towards the end the installer installed
"grub"... the old Grub (as I could verify after the successful reboot).

Emboldened by this result, I popped the install CD back into the MacBook
Pro and proceeded to do a similar installation, using root/swap
partitions from a previous installation of Ubuntu 8.04 Hardy (uses the
old Grub). I even left off the Laptop task, but again towards the end
the installer installed "grub2"(the dummy package) and "grub-pc"... the
new Grub. 

Apparently, the Debian Installer picks up on the fact that this is a
dual-boot installation next to Mac OS X, so there is a GUID partition
table. The installer is (apparently) configured to install the new Grub
in that case, since it can deal with GPT (from the description in
Aptitude). 

Unfortunately, this does not work: without resynching the GPT and the
MBR partition table there is "no bootable device", and with resynching
(I'm using the Partition tool in the rEFIt boot manager) it gives the
error reported earlier.

I believe this bug would solved by the Debian Installer giving a choice
between installing old or new Grub. 




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#494293: ...and finally.

2008-08-09 Thread Henk Koster 
I've started the install-CD in rescue mode, opened a shell in a chroot,
and did an "apt-get purge" to get rid of grub-pc in preparation of
replacing it with the old grub package. Bit then, unlike the previous
time, I checked and saw that /boot/grub was still full of files left
there, including grub.cfg. So, I deleted the whole lot, before doing
"apt-get install grub", "/usr/sbin/update-grub" and
"/usr/sbin/grub-install". Now the reboot brought up the newly-installed
Debian testing.

Some final thoughts:

1. The "apt-get purge grub-pc" command should not leave a whole
directory full of config files that are subsequently used by
grub-install. 

2. Perhaps old and new grub should not share the same grub-install.

3. The Debian Installer should give users a choice when it wants to
install a piece of crucial software that is still considered by many to
be in beta (in this case new Grub vs. old Grub).

Thank you for your consideration.




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: openssh 1:5.1p1-2 in lenny?

2008-08-09 Thread Luk Claes 

Colin Watson wrote:

Hi,

I've had a lot of requests for OpenSSH 4.9 or better in lenny, since it
adds the much-clamoured-for ChrootDirectory feature. I'd taken a while
to upgrade to this since I was trying to stabilise all the
vulnerable-key-checking code first. I did finally manage to upload to
unstable shortly before the freeze ... and then had an RC bug about
$SHELL handling that I needed to fix. Whoops.

Would it be possible to let openssh 1:5.1p1-2 into lenny? It's had fewer
new bugs filed against it than I can remember from any recent new
upstream version of OpenSSH (the above-mentioned regression in $SHELL
handling was the only particularly bad one, and that's fixed), so I'm
feeling pretty good about it. The only slight glitch is that it depends
on lsb-base (>= 3.2-13), which isn't yet in testing. (If need be, I can
back that out for lenny once I get back from holiday.)


lsb unblocked

As the package contains udebs I'm Cc-ing debian-boot: would it be ok to 
unblock openssh?


Cheers

Luk


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#494466: [patch, RFC] Allow to select driver inclusion policy for initramfs-tools

2008-08-09 Thread Frans Pop 
Package: base-installer
Version: 1.93
Severity: wishlist
Tags: patch

With the default initrd now being over 6 GB on amd64 and the fact that 
lilo has structural problems with large initrds, I think that 
implementing something like the attached patch for Lenny is almost 
unavoidable.

It is also needed for e.g. arm where in some cases the initrd is getting 
too big for the flash memory it needs to fit in.

My personal guess is that selecting MODULES=dep for x86 is unlikely to 
result in unbootable systems. As I've no idea about other architectures 
the default can be set per architecture (to be determined by their 
porters).

Note that the patch adds a new dialog (at medium priority).
Note that this will also need to be documented in the installation guide.

Index: debian/bootstrap-base.templates
===
--- debian/bootstrap-base.templates	(revision 54931)
+++ debian/bootstrap-base.templates	(working copy)
@@ -62,6 +62,23 @@
  The package ${GENERATOR} that was selected to generate the
  initrd is not supported.
 
+Template: base-installer/initramfs-tools/driver-policy
+Type: select
+Choices-C: most, dep
+# :sl3:
+__Choices: generic: include all available drivers, targeted: only include drivers needed for this system
+# :sl3:
+_Description: Drivers to include in the initrd:
+ The primairy function of an initrd is to allow the kernel to mount the
+ root file system. It therefore needs to contain all drivers and supporting
+ programs required to do that.
+ .
+ A generic initrd is much larger than a targeted one and may even be so
+ large that some bootloaders are unable to load it but has the advantage that
+ it can be used to boot the target system on almost any hardware. With the
+ smaller targeted initrd there is a very small chance that not all needed
+ drivers are included.
+
 Template: base-installer/kernel/failed-install
 Type: error
 _Description: Unable to install the selected kernel
Index: debian/templates-arch
===
--- debian/templates-arch	(revision 54931)
+++ debian/templates-arch	(working copy)
@@ -18,6 +18,14 @@
 Description: for internal use; can be preseeded
  Package to use to generate initramfs
 
+Template: base-installer/kernel/linux/initramfs-tools/driver-policy
+Type: string
+Default: most
+Default[amd64]: dep
+Default[i386]: dep
+Description: for internal use
+ Default driver inclusion policy for initramfs-tools
+
 Template: base-installer/kernel/linux/extra-packages
 Type: string
 Default:
Index: library.sh
===
--- library.sh	(revision 54931)
+++ library.sh	(working copy)
@@ -512,7 +512,7 @@
 
 		# initramfs-tools needs busybox pre-installed (and only
 		# recommends it)
-		if [ "$rd_generator" = "initramfs-tools" ]; then
+		if [ "$rd_generator" = initramfs-tools ]; then
 			if ! log-output -t base-installer apt-install busybox; then
 db_subst base-installer/kernel/failed-package-install PACKAGE busybox
 exit_error base-installer/kernel/failed-package-install
@@ -549,6 +549,29 @@
 			rm $QUEUEFILE
 			FIRSTMODULE=0
 		done
+
+		# Select and set driver inclusion policy for initramfs-tools
+		if [ "$rd_generator" = initramfs-tools ]; then
+			if db_get base-installer/initramfs-tools/driver-policy && \
+			   [ "$RET" = "" ]; then
+# Get default for architecture
+db_get base-installer/kernel/linux/initramfs-tools/driver-policy
+db_set base-installer/initramfs-tools/driver-policy "$RET"
+			fi
+			db_input medium base-installer/initramfs-tools/driver-policy || true
+			if ! db_go; then
+db_progress stop
+exit 10
+			fi
+
+			db_get base-installer/initramfs-tools/driver-policy
+			cat > /target/etc/initramfs-tools/conf.d/driver-policy <

signature.asc
Description: This is a digitally signed message part.

Bug#494466: [patch, RFC] Allow to select driver inclusion policy for initramfs-tools

2008-08-09 Thread Frans Pop 
On Saturday 09 August 2008, Frans Pop wrote:
> With the default initrd now being over 6 GB on amd64 and the fact that

That should have been MB. Still insane.


signature.asc
Description: This is a digitally signed message part.

Processing of debian-installer-utils_1.63_i386.changes

2008-08-09 Thread Archive Administrator 
debian-installer-utils_1.63_i386.changes uploaded successfully to localhost
along with the files:
  debian-installer-utils_1.63.dsc
  debian-installer-utils_1.63.tar.gz
  di-utils-shell_1.63_all.udeb
  di-utils-reboot_1.63_all.udeb
  di-utils-exit-installer_1.63_all.udeb
  di-utils-terminfo_1.63_all.udeb
  di-utils_1.63_i386.udeb
  di-utils-mapdevfs_1.63_i386.udeb

Greetings,

Your Debian queue daemon


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#491376: recipe for BIOS-based boot on gpt

2008-08-09 Thread Frans Pop 
On Wednesday 06 August 2008, Robert Millan wrote:
> Attached patch makes it generate the x86 variant dynamicaly at build
> time, as requested by Jérémy on IRC.

This patch gets a huge NACK from me.

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.

I know there are several other arches where a bootloader partition is 
required, but in those cases such a partition at least has a separate 
partition type to indicate its use (example: the Linux/PA-RISC (f0) 
partition [1]) and there is a clear relationship between the (sub)arch, 
the extra partition and the bootloader that will be installed by D-I.

2) The implementation is a huge hack

Because x86 is essentially the "reference arch" for D-I any implementation 
that adds a separate bootloader partition should
- define 100% exactly when it is needed
- ensure it is created *only* in that use-case
- not burden any other use case with unneeded cruft
- be extremely clean with sufficient comments to document why it is needed

All patches proposed so far fail these criteria in one way or another. It 
seems to me that all of them can result in the extra partition getting 
created when it is not actually needed.


According to an earlier mail this BR is somehow related to #488111. 
However, nowhere in the patches proposed so far do I see the BIOS boot 
partition flag getting set.
At this point I am more inclined to revert the patch committed for #488111 
than to allow any change to partman-auto...

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.
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.

Before we can move forward here submitter should IMO provide a lot better 
explanation and specification of exactly why and when and for which type 
of systems/installs all this uglyness is needed.

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
- 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).

Also, it should possibly be integrated with the selection of the 
bootloader (or rather, it should ensure that if such a partition is 
created that a BIOS-based bootloader is actually what is used later on).

All in all, I doubt this is something that can be implemented _cleanly_ in 
time for Lenny.

Cheers,
FJP

[1] Note that there are several issues with the current support for the 
PA-RISC bootloader partition and its partman flag. See e.g. #353573 for 
details.


signature.asc
Description: This is a digitally signed message part.

debian-installer-utils_1.63_i386.changes ACCEPTED

2008-08-09 Thread Debian Installer 

Accepted:
debian-installer-utils_1.63.dsc
  to pool/main/d/debian-installer-utils/debian-installer-utils_1.63.dsc
debian-installer-utils_1.63.tar.gz
  to pool/main/d/debian-installer-utils/debian-installer-utils_1.63.tar.gz
di-utils-exit-installer_1.63_all.udeb
  to pool/main/d/debian-installer-utils/di-utils-exit-installer_1.63_all.udeb
di-utils-mapdevfs_1.63_i386.udeb
  to pool/main/d/debian-installer-utils/di-utils-mapdevfs_1.63_i386.udeb
di-utils-reboot_1.63_all.udeb
  to pool/main/d/debian-installer-utils/di-utils-reboot_1.63_all.udeb
di-utils-shell_1.63_all.udeb
  to pool/main/d/debian-installer-utils/di-utils-shell_1.63_all.udeb
di-utils-terminfo_1.63_all.udeb
  to pool/main/d/debian-installer-utils/di-utils-terminfo_1.63_all.udeb
di-utils_1.63_i386.udeb
  to pool/main/d/debian-installer-utils/di-utils_1.63_i386.udeb


Override entries for your package:
debian-installer-utils_1.63.dsc - source debian-installer
di-utils-exit-installer_1.63_all.udeb - extra debian-installer
di-utils-mapdevfs_1.63_i386.udeb - standard debian-installer
di-utils-reboot_1.63_all.udeb - standard debian-installer
di-utils-shell_1.63_all.udeb - standard debian-installer
di-utils-terminfo_1.63_all.udeb - standard debian-installer
di-utils_1.63_i386.udeb - standard debian-installer

Announcing to [EMAIL PROTECTED]


Thank you for your contribution to Debian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: openssh 1:5.1p1-2 in lenny?

2008-08-09 Thread Otavio Salvador 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Luk Claes <[EMAIL PROTECTED]> writes:

> As the package contains udebs I'm Cc-ing debian-boot: would it be ok
> to unblock openssh?

No objection

- -- 
O T A V I OS A L V A D O R
- -
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
- -
"Microsoft sells you Windows ... Linux gives
 you the whole house."
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ 

iEYEARECAAYFAkieBwwACgkQLqiZQEml+FWFzACfXkDkmTzfW2x5Wx8WpO5JJzRk
XCEAoKCfETjEHwm2R07N3hPBpYAj2A52
=p7yW
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Processed (with 10 errors): Unarchiving archived bugs affecting unstable or testing

2008-08-09 Thread Debian Bug Tracking System 
Processing commands for controlbugs.debian.org:

> unarchive 99400
Unarchived Bug 99400
> unarchive 144876
Unarchived Bug 144876
> unarchive 148123
Unarchived Bug 148123
> unarchive 148150
Unarchived Bug 148150
> unarchive 190630
Unarchived Bug 190630
> unarchive 235611
Unarchived Bug 235611
> unarchive 245548
Unarchived Bug 245548
> unarchive 247648
Unarchived Bug 247648
> unarchive 284925
Unarchived Bug 284925
> unarchive 287070
Unarchived Bug 287070
> unarchive 289055
Unarchived Bug 289055
> unarchive 291945
Unarchived Bug 291945
> unarchive 293631
Unarchived Bug 293631
> unarchive 306804
Unarchived Bug 306804
> unarchive 311035
Unarchived Bug 311035
> unarchive 311220
Unarchived Bug 311220
> unarchive 321678
Unarchived Bug 321678
> unarchive 322884
Unarchived Bug 322884
> unarchive 322926
Unarchived Bug 322926
> unarchive 326723
Unarchived Bug 326723
> unarchive 332525
Unarchived Bug 332525
> unarchive 339717
Unarchived Bug 339717
> unarchive 348913
Unarchived Bug 348913
> unarchive 352029
Unarchived Bug 352029
> unarchive 356625
Unarchived Bug 356625
> unarchive 362288
Unarchived Bug 362288
> unarchive 364466
Unarchived Bug 364466
> unarchive 364992
Unarchived Bug 364992
> unarchive 368786
Unarchived Bug 368786
> unarchive 374004
Unarchived Bug 374004
> unarchive 376075
Unarchived Bug 376075
> unarchive 377049
Unarchived Bug 377049
> unarchive 378483
Unarchived Bug 378483
> unarchive 378890
Unarchived Bug 378890
> unarchive 379110
Unarchived Bug 379110
> unarchive 379367
Unarchived Bug 379367
> unarchive 379537
Unarchived Bug 379537
> unarchive 380739
Unarchived Bug 380739
> unarchive 380810
Unarchived Bug 380810
> unarchive 380831
Unarchived Bug 380831
> unarchive 385090
Unarchived Bug 385090
> unarchive 385265
Unarchived Bug 385265
> unarchive 386366
Unarchived Bug 386366
> unarchive 386467
Unarchived Bug 386467
> unarchive 386949
Unarchived Bug 386949
> unarchive 387057
Unarchived Bug 387057
> unarchive 389140
Unarchived Bug 389140
> unarchive 389871
Unarchived Bug 389871
> unarchive 390391
Unarchived Bug 390391
> unarchive 391022
Unarchived Bug 391022
> unarchive 391220
Unarchived Bug 391220
> unarchive 391849
Unarchived Bug 391849
> unarchive 391989
Unarchived Bug 391989
> unarchive 392852
Unarchived Bug 392852
> unarchive 393032
Unarchived Bug 393032
> unarchive 393970
Unarchived Bug 393970
> unarchive 394039
Unarchived Bug 394039
> unarchive 396303
Unarchived Bug 396303
> unarchive 397245
Unarchived Bug 397245
> unarchive 397346
Unarchived Bug 397346
> unarchive 398242
Unarchived Bug 398242
> unarchive 398524
Unarchived Bug 398524
> unarchive 398609
Unarchived Bug 398609
> unarchive 399021
Unarchived Bug 399021
> unarchive 399478
Unarchived Bug 399478
> unarchive 401855
Unarchived Bug 401855
> unarchive 402301
Unarchived Bug 402301
> unarchive 403273
Unarchived Bug 403273
> unarchive 403431
Unarchived Bug 403431
> unarchive 403585
> unarchive 403587
> unarchive 403590
> unarchive 403592
> unarchive 403599
> unarchive 403601
> unarchive 403645
Unarchived Bug 403645
> unarchive 403651
> unarchive 403673
> unarchive 403848
Unarchived Bug 403848
> unarchive 405630
Unarchived Bug 405630
> unarchive 406207
Unarchived Bug 406207
> unarchive 406285
Unarchived Bug 406285
> unarchive 408273
Unarchived Bug 408273
> unarchive 409063
Unarchived Bug 409063
> unarchive 409253
Unarchived Bug 409253
> unarchive 409688
Unarchived Bug 409688
> unarchive 411052
Unarchived Bug 411052
> unarchive 411522
Unarchived Bug 411522
> unarchive 413184
Unarchived Bug 413184
> unarchive 415421
Unarchived Bug 415421
> unarchive 416081
Unarchived Bug 416081
> unarchive 417142
Unarchived Bug 417142
> unarchive 417259
Unarchived Bug 417259
> unarchive 417469
Unarchived Bug 417469
> unarchive 417764
Unarchived Bug 417764
> unarchive 418229
Unarchived Bug 418229
> unarchive 419067
Unarchived Bug 419067
> unarchive 420764
Unarchived Bug 420764
> unarchive 421228
Unarchived Bug 421228
> unarchive 421607
Unarchived Bug 421607
> unarchive 423050
Unarchived Bug 423050
> unarchive 423205
Unarchived Bug 423205
> unarchive 424430
Unarchived Bug 424430
> unarchive 426154
Unarchived Bug 426154
> unarchive 426415
Unarchived Bug 426415
> unarchive 428686
Unarchived Bug 428686
> unarchive 428848
> unarchive 428957
> unarchive 430065
Unarchived Bug 430065
> unarchive 430379
Unarchived Bug 430379
> unarchive 430510
Unarchived Bug 430510
> unarchive 430667
Unarchived Bug 430667
> unarchive 435239
Unarchived Bug 435239
> unarchive 435922
Unarchived Bug 435922
> unarchive 435935
Unarchived Bug 435935
> unarchive 436170
Unarchived Bug 436170
> unarchive 436306
Unarchived Bug 436306
> unarchive 438326
Unarchived Bug 438326
> unarchive 438724
Unarchived Bug 438724
> unarchive 439591
Unarchived Bug 439591
> unarchive 439764
Unarchived Bug 439764
> unarchive 441755
Unarchived Bug 441755
> unarchive 442308
Unarchived Bug 442308
> unarchive 442635
Unarchived Bug 442635
> unarchive 442926
Unarchived Bug 442926
> unarchive 445011
Unarchived Bug 445011
> unar

Processing of mdcfg_1.27+nmu1_i386.changes

2008-08-09 Thread Archive Administrator 
mdcfg_1.27+nmu1_i386.changes uploaded successfully to localhost
along with the files:
  mdcfg_1.27+nmu1.dsc
  mdcfg_1.27+nmu1.tar.gz
  mdcfg_1.27+nmu1_all.udeb
  mdcfg-utils_1.27+nmu1_all.udeb

Greetings,

Your Debian queue daemon


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

mdcfg_1.27+nmu1_i386.changes ACCEPTED

2008-08-09 Thread Debian Installer 

Accepted:
mdcfg-utils_1.27+nmu1_all.udeb
  to pool/main/m/mdcfg/mdcfg-utils_1.27+nmu1_all.udeb
mdcfg_1.27+nmu1.dsc
  to pool/main/m/mdcfg/mdcfg_1.27+nmu1.dsc
mdcfg_1.27+nmu1.tar.gz
  to pool/main/m/mdcfg/mdcfg_1.27+nmu1.tar.gz
mdcfg_1.27+nmu1_all.udeb
  to pool/main/m/mdcfg/mdcfg_1.27+nmu1_all.udeb


Override entries for your package:
mdcfg-utils_1.27+nmu1_all.udeb - optional debian-installer
mdcfg_1.27+nmu1.dsc - source debian-installer
mdcfg_1.27+nmu1_all.udeb - optional debian-installer

Announcing to [EMAIL PROTECTED]


Thank you for your contribution to Debian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#491376: recipe for BIOS-based boot on gpt

2008-08-09 Thread Robert Millan 
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.

You can reproduce it very easily.  So please don't take it for granted;  go
ahead and try it.

Create a disk image that is 10 GB in size:

  $ qemu-img create -f qcow debian.img 10GB

Install the latest daily build on it.  Once finished, issue these commands
in the guest OS:

  # cp -a /boot/grub /tmp/
  # shred /boot/grub/*
  # rm -rf /boot/grub
  # mv /tmp/grub /boot/

Then reboot.  Everything is fine (either with GRUB Legacy or GRUB 2).

Now try again with a bigger disk, make it 3 TB in size:

  $ qemu-img create -f qcow debian.img 3000GB

Install the latest daily build on it.  Once finished, issue these commands
in the guest OS:

  # cp -a /boot/grub /tmp/
  # shred /boot/grub/*
  # rm -rf /boot/grub
  # mv /tmp/grub /boot/

Then reboot.  Results now depend on which kind of random code shred
generated, since after the MBR this is what your cpu is executing.

Of course, this is just a quick way of reproducing it;  you don't need to
call shred to break it.  It affects a variety of situations, for example
when you restore your whole filesystem from backup.

Here's a nastier variant.  Suppose a local unprivileged user tricks the
administrator to remove /boot/grub/core.img, or archieves the removal of
that file by any other means.

Now it's relatively easy to execute arbitrary code with bootloader privileges.
All the attacker has to do is create a huge file (or lots of small files) to
populate all/most unused sectors with a 512 byte chunk of mallicious code.
Chances that the first core.img sector will be overwritten are very high
(in 512 bytes it is difficult to perform privilege scalation, but the code
to fill the disk with zeroes would fit).

Overall, the result is that the boot process is less robust (and for no good
reason).

> Because x86 is essentially the "reference arch" for D-I any implementation 
> that adds a separate bootloader partition should
> - define 100% exactly when it is needed

Whenever you combine the following ingredients in your Debian install:

  - A standard x86 PC
  - GPT
  - GRUB

> - 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.

> All patches proposed so far fail these criteria in one way or another. It 
> seems to me that all of them can result in the extra partition getting 
> created when it is not actually needed.

I assume that you were thinking this is a very specific use case, but as I
explained above it is in fact a very general one.

> According to an earlier mail this BR is somehow related to #488111. 
> However, nowhere in the patches proposed so far do I see the BIOS boot 
> partition flag getting set.

They all have something like this in one place or another:

+open_dialog SET_FLAGS $id
+write_line "$flags"
+write_line bios_grub
+write_line NO_MORE
+close_dialog


> 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.

> 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.

> - 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?

> All in all, I doubt this

Bug#494361: marked as done (win32-loader: [INTL:zh_TW] Updated Traditional Chinese (zh_TW) translation)

2008-08-09 Thread Debian Bug Tracking System 

Your message dated Sun, 10 Aug 2008 11:32:57 +0800
with message-id <[EMAIL PROTECTED]>
and subject line Re: Bug#494361: Acknowledgement (win32-loader: [INTL:zh_TW] 
Updated  Traditional Chinese (zh_TW) translation)
has caused the Debian Bug report #494361,
regarding win32-loader: [INTL:zh_TW] Updated Traditional Chinese (zh_TW) 
translation
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)


-- 
494361: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=494361
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---
Package: win32-loader
Version: 0.6.7
Severity: wishlist


Hi,

Attached file is updated Translation Chinese translation for
win32-loader package.
Please consider to apply this.

Thanks.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'oldstable'), (500, 'unstable'), (500, 
'stable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-3-vserver-k7 (SMP w/1 CPU core)
Locale: LANG=POSIX, LC_CTYPE=zh_TW.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
# Traditional Chinese translation for win32-loader
# Copyright (C) 2008 Tetralet 
# This file is distributed under the same license as the win32-loader package.
#
msgid ""
msgstr ""
"Project-Id-Version: win32-loader 0.6.0\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2008-05-01 10:40+0200\n"
"PO-Revision-Date: 2008-08-09 02:28+0800\n"
"Last-Translator: Tetralet <[EMAIL PROTECTED]>\n"
"Language-Team: Debian-user in Chinese [Big5] <[EMAIL PROTECTED]"
"debian.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. translate:
#. This must be a valid string recognised by Nsis.  If your
#. language is not yet supported by Nsis, please translate the
#. missing Nsis part first.
#.
#: win32-loader.sh:36 win32-loader.c:39
msgid "LANG_ENGLISH"
msgstr "LANG_TRADCHINESE"

#. translate:
#. This must be the string used by GNU iconv to represent the charset used
#. by Windows for your language.  If you don't know, check
#. [wine]/tools/wmc/lang.c, or 
http://www.microsoft.com/globaldev/reference/WinCP.mspx
#.
#. IMPORTANT: In the rest of this file, only the subset of UTF-8 that can be
#. converted to this charset should be used.
#: win32-loader.sh:52
msgid "windows-1252"
msgstr "big5"

#. translate:
#. Charset used by NTLDR in your localised version of Windows XP.  If you
#. don't know, maybe http://en.wikipedia.org/wiki/Code_page helps.
#: win32-loader.sh:57
msgid "cp437"
msgstr "cp950"

#. translate:
#. The name of your language _in English_ (must be restricted to ascii)
#: win32-loader.sh:67
msgid "English"
msgstr "Chinese (Traditional)"

#. translate:
#. IMPORTANT: only the subset of UTF-8 that can be converted to NTLDR charset
#. (e.g. cp437) should be used in this string.  If you don't know which charset
#. applies, limit yourself to ascii.
#: win32-loader.sh:81
msgid "Debian Installer"
msgstr "Debian 安裝程式"

#. translate:
#. The nlf file for your language should be found in
#. /usr/share/nsis/Contrib/Language files/
#.
#: win32-loader.c:68
msgid "English.nlf"
msgstr "TradChinese.nlf"

#: win32-loader.c:71
msgid "Debian-Installer Loader"
msgstr "Debian 安裝程式載入器"

#: win32-loader.c:72
msgid "Cannot find win32-loader.ini."
msgstr "找不到 win32-loader.ini"

#: win32-loader.c:73
msgid "win32-loader.ini is incomplete.  Contact the provider of this medium."
msgstr "win32-loader.ini 不完整。請聯繫此檔案的提供者。"

#: win32-loader.c:74
msgid ""
"This program has detected that your keyboard type is \"$0\".  Is this "
"correct?"
msgstr "本程式偵測到您的鍵盤類型是「$0」。這是否正確？"

#: win32-loader.c:75
msgid ""
"Please send a bug report with the following information:\n"
"\n"
" - Version of Windows.\n"
" - Country settings.\n"
" - Real keyboard type.\n"
" - Detected keyboard type.\n"
"\n"
"Thank you."
msgstr ""
"請發送包含了以下資訊的錯誤回報：\n"
"\n"
" - Windows 的版本。\n"
" - 國家設定。\n"
" - 鍵盤的實際類型。\n"
" - 偵測到的鍵盤類型。\n"
"\n"
"謝謝您。"

#: win32-loader.c:76
msgid ""
"There doesn't seem to be enough free disk space in drive $c.  For a complete "
"desktop install, it is recommended to have at least 3 GB.  If there is "
"already a separate disk or partition to install Debian, or if you plan to "
"replace Windows completely, you can safely ignore this warning."
msgstr ""
"在裝置 $c 中似乎沒有足夠的未使用磁碟空間。為了要安裝完整的桌面環境，建議至少"
"要有 3 GB 的空間。如果您已準備了個別的磁碟或分割區以用來安裝 Debian，或者您是"
"打算要完全取代 Windows，您可以放心得忽略此警告訊息。"

#: win32-loader.c:77
msgid "Error: not enough free disk space.  Aborting install."
msgstr "錯誤：沒有足夠的未使用磁碟空間。安裝中止。"

#: win32-loader.c:78
msgid "This program doesn't support Windows $windows_version yet."

Bug#494466: [patch, RFC] Allow to select driver inclusion policy for initramfs-tools

2008-08-09 Thread Martin Michlmayr 
* Frans Pop <[EMAIL PROTECTED]> [2008-08-09 19:53]:
> With the default initrd now being over 6 GB on amd64 and the fact
> that lilo has structural problems with large initrds, I think that
> implementing something like the attached patch for Lenny is almost
> unavoidable.

Nice patch.  I wouldn't change the default to dep on amd64 and i386
though:
 1) These arches are the most generic ones we support in terms of
hardware and MODULES=most makes most sense on them (unlike on
embedded hardware which doesn't change).
 2) The LILO bug has been fixed.

-- 
Martin Michlmayr
http://www.cyrius.com/



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Processing of cdebconf-terminal_0.1_i386.changes

2008-08-09 Thread Archive Administrator 
cdebconf-terminal_0.1_i386.changes uploaded successfully to localhost
along with the files:
  cdebconf-terminal_0.1.dsc
  cdebconf-terminal_0.1.tar.gz
  cdebconf-gtk-terminal_0.1_i386.udeb

Greetings,

Your Debian queue daemon


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]