Bug#635968: installation-reports: Initial boot after installation failed
30.07.2011 01:06, Ralf Jung wrote: > Machine: HP Compaq 615 > Processor: AMD Athlon(tm)X2 DualCore QL-66 > Memory: 4 GiB > Partitions: >Device Boot Start End Blocks Id System > /dev/sda1 *2048 1228761438976 83 Linux > /dev/sda2 12288 131071999 4096000 82 Linux swap / Solaris > /dev/sda3 131074046 625141759 2470338575 Extended > /dev/sda5 131074048 625141759 247033856 83 Linux > [] > Installation went fine, however, the initial boot into the actual system > failed: The BIOS complained it would not find anything to boot on my HDD. I > tried both graphical and console installation, with the same result - of > course > I always replied "Yes" when asked whether I want GRUB to be installed into the > MBR. I then tried to fix the problem by chroot'ing into the installed system > and running "grub-install /dev/sda", but even though this completed > successfully, the PC would still refuse to boot. After three installation > attempts with two different versions of the disc (I used a two-months old > version for my first attempts), I tried to set the boot flag on the root > partition, using GParted from the system rescue CD. The next installation > attempt then completed successfully. > > I suspect that either my system is special in that it needs that flag on the > partition even though grub resides in the MBR, or this is a bug in grub- > install: It should also make sure the partition containing grub has the boot > flag set so that booting actually worked. If that's impossible, the installer > should at least set the boot flag for the /boot or / partition - the partition > in question was actually created during Debian installation, so it definitely > should have been set up correctly. The way things work currently, the user > ends > up with a completely unusable system. Can you verify this by clearing the boot flag you now have and seeing if your system will boot after that? So far, I for one haven't seen a system which requires a partition _table_ to boot, not to mention a bootable partition in it. BIOS merely loads first 512 bytes of a disk into memory and jumps into that area, without trying to interpret what's inside. Unless you use some recovery/diagnostic mode which is embedded into some BIOSes/machines. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e33ad23.6040...@msgid.tls.msk.ru
LVM/grub2/UUID don't get along
After installing squeeze on a new disk, booting failed because the kernel was unable to find the root device. This is a report of soome things that went wrong and some work-arounds. My main motivation it to highlight some areas that seem to need improvement. I don't need help, since I (think I've?) fixed the problem on my system. Boot failed because the root device was on LVM, and LVM had not been activated by the initrd scripts. In particular, scripts/local-top/lvm2 does a number of tests to determine if root is on an LVM volume. It is expecting /dev/mapper/ (and a few other cases), but not UUID=. So it never activate LVM volumes. Since the autogenerated lines in grub.cfg have two root parameters, the first as a conventional device and the second as UUID, the second apparently is the one that counts. The exact process by which I got to this state was definitely non-standard, but it appears that this might be the regular behavior. I thought I'd report it here, since even if it's a bug it's not clear what it is a bug in. One interpretation is that the grub2 config scripts (or perhaps the filesystem base scripts) should not generate the root=UUID entries on the kernel invocation line. Alternately, the lvm initrd scripts should cope with the UUID better. Against the first interpretation are all the arguments for using UUIDS; against the second is the difficulty (perhaps impossibity by the time one is running in the initrd) of determing from the UUID if the device is on lvm. Perhaps a solution would be for the local-top/lvm2 script to look for the UUID on the disks and, if unsuccessful, activate LVM with vgchange -ay. Additionally, the autogenerated grub.cfg did not even have the correct UUID. It had the UUID of the physical partition underlying the logical volume of interest (or maybe of the boot partition), not the UUID of the logical volume itself. The VG includes several physical partitions, not entire disks. For the record, there were a couple of different **fixes/work-arounds**. If one gets to the point inside the initrd where the kernel's root is not found, one is dropped into a (busybox) shell. Typing vgchange -ay will activate the logical volumes; typing exit will cause the boot process to continue successfully. A more permanent solution is to edit the grub.cfg, or ideally /etc/default/grub, which includes options not to generate the UUIDs for the kernel root lines, and a custom set of options for the main kernel startup. E.g., GRUB_CMDLINE_LINUX="root=/dev/mapper/daisy-root_rescue ro rootdelay=20" # autogenerated line was #GRUB_CMDLINE_LINUX="root=UUID=2707f7ec-48cc-4c41-98ec-4dc5ee8bb8dd ro rootdelay=20" # Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux GRUB_DISABLE_LINUX_UUID=true I'm not sure the last uncommenting is wise. --- Gory details about my non-standard process start here, and include some additional issues that seem more likely to be idiosyncratic to the non-standard installation. Basically, I followed Appendix D3 of the installation guide http://www.debian.org/releases/stable/amd64/apds03.html.en (though I was on i386). Initial state: running Debian Lenny system, 686 architecture, lots of disks making heavy use of lvm and token use of dm-crypt. An internal SATA disk is the boot disk; there is also an external data connected by USB, an internal IDE connected to the main board, and 2 internal IDE's connected to a promised controller. Installed a new SATA disk (SATA 1, where SATA 0 is the boot disk) and used (lenny) parted to make it GPT with a BIOS boot partition. Bootstrapped a squeeze system, chrooted into it, and from inside the chroot installed a kernel and grub2. Installed grub2 onto the new disk. The new disk had a separate, vanilla (for GPT), partition to hold the squeeze /boot drive, and the new root partition (including the whole rest of the system) came out of a logical volume from the same VG that held much of the Lenny system. Chain loaded from my old grub1 into grub2 on the new disk. This account omits many false starts. The first cut of the grub setup was wildly off about the mapping from grub disks to real disks. Some of this seems inevitable. In the chroot, for example, /boot did not appear to be on a separate partition. I think this is also the reason the initrd and vmlinuz symlinks ended up in / instead of /boot. Also, device naming and ordering differed in Lenny (I did mount --bind /dev /squeezeroot/dev) from what it would be in squeeze (hd? in Lenny becomes sd? with the squeeze kernel). Even when I finally booted into squeeze, grub running inside linux did a poor job of getting the device mapping right. It assume that all my IDE drives would appear before (in the grub (hd?) sense) all SATA drives (ignoring the USB drive). In fact, only the motherboard-connected IDE drive appeared first. I ended up editing the grub map by hand. --
Bug#576309: installation-reports: [pt_BR] A mistake in grub-pc configuration phase
tags 576309 pending thanks On Sat, Apr 03, 2010 at 09:35:03AM -0300, Eriberto wrote: > 2010/4/3 Christian PERRIER : > > - the original English talks about "extended partition" which seems to > > have been translated to "partição estendida" in the installer. > > Right. But you can't put data into an extended partition and because > it I am suggesting to use logical instead of extended. I think the > word "extended" can confuse the users. Well. Each logical partition is actually contained within an extended partition (despite how it's sometimes presented), and technically, GRUB is installed to the extended boot record which is *outside* the logical partition in the same way that the master boot record is outside any individual primary partition. This may help (and the topic is certainly confusing in various directions): http://en.wikipedia.org/wiki/Extended_boot_record > > What you suggest implicitly is to mention that "sdc5" might be either > > an SCSI or SATA partition *in the original string*. That seems correct > > but needs to be discussed with the D-I team. > > > > Indeed, nowadays, "sdc" is o longer SCSI only so that mimght need > > rephrasing in several places. > > I agree with your idea. But think that newbies may not know about it > and a purpose of the d-i is to be very easy to all. So I think the > SATA word can be added to description as an extra help to new users. > It is modern because SATA is a recent technology. It is relevant as > additional information to users that don't know SCSI-SATA concepts. > The intent is update the description to make the GRUB installation > more friendly. Given that most disk devices nowadays use the sd* naming, and that this is actually dependent not on PATA vs. SATA but on whether the kernel driver uses the old IDE stack or the new libata stack (a concept I definitely do not think should be introduced in user-visible text at installation time!), I think it would be better to simply drop the IDE vs. SCSI text as obsolete and to use /dev/sd* throughout. I've committed this change, and would welcome feedback before it's uploaded: commit 02b57cb2727f5cc78c7d37205212e66da55457ac Author: Colin Watson Date: Sat Jul 30 10:06:52 2011 +0100 Update grub-installer/bootdev text to avoid GRUB device naming that changed between GRUB Legacy and GRUB 2, and to use libata-style device naming since that is more accurate for most people (closes: #576309). diff --git a/debian/changelog b/debian/changelog index 1c93c1b..ba38f66 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,11 @@ +grub-installer (1.66) UNRELEASED; urgency=low + + * Update grub-installer/bootdev text to avoid GRUB device naming that +changed between GRUB Legacy and GRUB 2, and to use libata-style device +naming since that is more accurate for most people (closes: #576309). + + -- Colin Watson Sat, 30 Jul 2011 10:06:22 +0100 + grub-installer (1.65) unstable; urgency=low * Add mipsel/loongson-2f support, covering the Lemote YeeLoong (closes: diff --git a/debian/grub-installer.templates b/debian/grub-installer.templates index 8762b0c..a9a53b1 100644 --- a/debian/grub-installer.templates +++ b/debian/grub-installer.templates @@ -77,15 +77,14 @@ _Description: Device for boot loader installation: prefer, you can install GRUB elsewhere on the drive, or to another drive, or even to a floppy. . - The device can be specified using GRUB's "(hdn,m)" notation, or as a device - in /dev. Below are some examples: - - "(hd0)" or "/dev/hda" will install GRUB to the master boot record -of your first hard drive (IDE); - - "(hd0,2)" or "/dev/hda2" will use the second partition of your -first IDE drive; - - "(hd2,5)" or "/dev/sdc5" will use the first extended partition of -your third drive (SCSI here); - - "(fd0)" or "/dev/fd0" will install GRUB to a floppy. + The device should be specified as a device in /dev. Below are some + examples: + - "/dev/sda" will install GRUB to the master boot record of your first +hard drive; + - "/dev/sda2" will use the second partition of your first hard drive; + - "/dev/sdc5" will use the first extended partition of your third hard +drive; + - "/dev/fd0" will install GRUB to a floppy. Template: grub-installer/password Type: password Cheers, -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110730090858.ga28...@riva.dynamic.greenend.org.uk
Processed: Re: Bug#576309: installation-reports: [pt_BR] A mistake in grub-pc configuration phase
Processing commands for cont...@bugs.debian.org: > tags 576309 pending Bug #576309 [grub-installer] Should consider rewording grub-installer templates to abetter fit 2010 device names Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 576309: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=576309 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: http://lists.debian.org/handler.s.c.131201695614317.transcr...@bugs.debian.org
Bug#635968: installation-reports: Initial boot after installation failed
Hi, > Can you verify this by clearing the boot flag you now > have and seeing if your system will boot after that? Yes, I tried that: The system showed exactly the same error about not being able to find a bootable device if the boot flag is unset, and after setting it again, things now work like before. > So far, I for one haven't seen a system which requires a > partition _table_ to boot, not to mention a bootable > partition in it. BIOS merely loads first 512 bytes of > a disk into memory and jumps into that area, without > trying to interpret what's inside. Unless you use some > recovery/diagnostic mode which is embedded into some > BIOSes/machines. Well, that was my understanding as well, but my laptop just proofed us wrong ;-) . Maybe this is related to the "mainboard firmware" actually being some EFI or UEFI thingy with a BIOS compatibility layer. In any case, the Ubuntu installer deals with this correctly, I never had any issues booting from HDD before trying Debian as main OS (CDs are a different matter though). Kind regards, Ralf -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201107301354.44151.ralfjun...@gmx.de
Re: [pkg-wpa-devel] Bug#610931: Please build wpasupplicant-udeb
Hi I've now uploaded the package. Please see the attached NMU patch. Gaudenz Excerpts from Gaudenz Steinlin's message of 2011-07-30 04:08:32 +0200: > Excerpts from Kel Modderman's message of 2011-07-30 01:44:07 +0200: > > On Sat, 30 Jul 2011 06:25:00 AM Gaudenz Steinlin wrote: > > > Excerpts from Kel Modderman's message of 2011-07-27 13:30:37 +0200: > > > > On Wed, 27 Jul 2011 02:43:02 AM Gaudenz Steinlin wrote: > > > > > OK. How do you feel about me NMUing wpa_supplicant to add the udeb? I > > > > > added an updated patch for the udeb to this mail. If you are OK I'll > > > > > upload this as an NMU after libnl1-udeb enters the archive. > > > > > > > > I would be very happy for you to do that. > > > > > > After some more investigation we (I and Otavio) decided that we rather > > > want to move wpasupplicant to build against libnl3. I guess this has > > > to be done at some point anyway and it avoids to have to do the whole > > > work again for libnl3. So we created a udeb for libnl3 and will upload > > > this soon. I hope you agree to this change. If you are against it > > > please reply soon. > > > > This is a far more invasive change than just adding the udeb. Please be > > prepared to pick up the pieces in case regression in stable functionality > > are > > introduced with such a change. > > > > Doing this when moving from wpa_supplicant 0.7.x -> 0.8.x (not yet > > released) > > would be more appropriate in my opinion. > > > > I am less happy about this change, but do not oppose NMU's regardless of > > the > > risk, the rewards may be worth it. > > I can understand your concerns. > > > > > > > > > The only change needed in wpasupplicant for this is to set > > > CONFIG_LIBNL20=y > > > in the linux and udeb configs. > > > > And cross your fingers that it works just the same, without any noticable > > change to the end users. > > For what it's worth I'm using a wpasupplicant built against libnl3 > since 3 days on my laptop here at Debconf without any problems. But as > it stands this is just testing on one single driver (iwlwifi) on one > single network. Probably some wider testing would be appropriate. > > Gaudenz -- Ever tried. Ever failed. No matter. Try again. Fail again. Fail better. ~ Samuel Beckett ~ build_wpasupplicant_udeb_v3.patch Description: Binary data
Bug#636040: finish-install: hvc0 console added to inittab even when not available
Package: finish-install Version: 2.32 Severity: normal finish-install 90console script checks for the existence of /sys/bus/xen to determine whether to add a console on /dev/hvc0 - but in 2.6.38 / 2.6.39 this always appears to exist. The effect is an "init id co respawned too fast, disabling for 5 mins" message every 5 mins on systems without /dev/hvc0 Adding a check that /dev/hvc0 exists prevents this particular manifestation, but possibly a more conclusive fix would be required as the previous block can also create a co console using /dev/hvc0, but with mode vt100. I don't have a suitable environment to test what happens under those circimstances. -- System Information: Debian Release: 5.0.8 APT prefers oldstable APT policy: (500, 'oldstable') Architecture: i386 (x86_64) Kernel: Linux 2.6.26-2-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/bash -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110730131029.12861.69283.report...@buildd.thirdlight.int
Bug#636040: finish-install: hvc0 console added to inittab even when not available
On Sat, 2011-07-30 at 14:10 +0100, Dominic Benson wrote: > Package: finish-install > Version: 2.32 > Severity: normal > > finish-install 90console script checks for the existence of > /sys/bus/xen to determine whether to add a console on > /dev/hvc0 - but in 2.6.38 / 2.6.39 this always appears to exist. Do you mean that /sys/bus/xen exists even when not running under Xen? Or when running under Xen but without the necessary driver (perhaps in an HVM domain)? > The effect is an "init id co respawned too fast, disabling for 5 mins" > message every 5 mins on systems without /dev/hvc0 > > Adding a check that /dev/hvc0 exists prevents this particular > manifestation, but possibly a more conclusive fix would be required > as the previous block can also create a co console using > /dev/hvc0, but with mode vt100. I don't have a suitable environment > to test what happens under those circimstances. > > -- System Information: > Debian Release: 5.0.8 > APT prefers oldstable > APT policy: (500, 'oldstable') > Architecture: i386 (x86_64) > > Kernel: Linux 2.6.26-2-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/bash > > > -- Ian Campbell A statesman is a politician who's been dead 10 or 15 years. -- Harry S. Truman signature.asc Description: This is a digitally signed message part
Bug#636040: finish-install: hvc0 console added to inittab even when not available
(please keep 636...@bugs.debian.org CC'd so this conversation is recorded on the bug) On Sat, 2011-07-30 at 14:43 +0100, Dominic Benson wrote: > On 30 Jul 2011, at 14:40, Ian Campbell wrote: > > > On Sat, 2011-07-30 at 14:10 +0100, Dominic Benson wrote: > >> Package: finish-install > >> Version: 2.32 > >> Severity: normal > >> > >> finish-install 90console script checks for the existence of > >> /sys/bus/xen to determine whether to add a console on > >> /dev/hvc0 - but in 2.6.38 / 2.6.39 this always appears to exist. > > > > Do you mean that /sys/bus/xen exists even when not running under Xen? Or > > when running under Xen but without the necessary driver (perhaps in an > > HVM domain)? > > The former - that /sys/bus/xen exists even when not running under Xen. > > I've seen it under VMware, Parallels, Virtualbox and on a real > hardware box (an old Sunfire v20z) OK. Some sort of check for hvc0 is probably in order then. Sounds like you have at least the beginnings of a patch -- can you post it? You mentioned a previous block which added another hvc0 (with vt100), is that the one inside the "if [ -e $DT_ROOT/chosen/linux,stdout-path ]; then" block? I think that one is safe. Ian. -- Ian Campbell DYSLEXICS OF THE WORLD, UNTIE! signature.asc Description: This is a digitally signed message part
Bug#636040: finish-install: hvc0 console added to inittab even when not available
On 30 Jul 2011, at 14:56, Ian Campbell wrote: > (please keep 636...@bugs.debian.org CC'd so this conversation is > recorded on the bug) Sorry - missed that last time. > > On Sat, 2011-07-30 at 14:43 +0100, Dominic Benson wrote: >> On 30 Jul 2011, at 14:40, Ian Campbell wrote: >> >>> On Sat, 2011-07-30 at 14:10 +0100, Dominic Benson wrote: Package: finish-install Version: 2.32 Severity: normal finish-install 90console script checks for the existence of /sys/bus/xen to determine whether to add a console on /dev/hvc0 - but in 2.6.38 / 2.6.39 this always appears to exist. >>> >>> Do you mean that /sys/bus/xen exists even when not running under Xen? Or >>> when running under Xen but without the necessary driver (perhaps in an >>> HVM domain)? >> >> The former - that /sys/bus/xen exists even when not running under Xen. >> >> I've seen it under VMware, Parallels, Virtualbox and on a real >> hardware box (an old Sunfire v20z) > > OK. Some sort of check for hvc0 is probably in order then. > > Sounds like you have at least the beginnings of a patch -- can you post > it? I attach a patch that I've used (against 2.22). It does, for me, prevent the problem on systems that I can test. I tried it under Citrix Xencenter, and the inittab entry for this console is (correctly) added. > > You mentioned a previous block which added another hvc0 (with vt100), is > that the one inside the "if [ -e $DT_ROOT/chosen/linux,stdout-path ]; > then" block? I think that one is safe. OK. I'm not really sure under what real circumstances it would be entered. My concern was that, if it is used, as /sys/bus/xen and /dev/hvc0 must both exist, two inittab lines would be produced with the same id. It strikes me that that would be in some way bad, although I haven't tried it. Dominic finish-install_hvc0-check.patch Description: Binary data
Re: [RFC] Use of Built-Using in debian-installer
On 07/30/2011 06:23 AM, Otavio Salvador wrote: > Hello, Hi Otavio > During this night I got some nice progress on the stuff planned to > debian-installer. I am adding the generated control file for review > and comments. > > Basically it gather all udebs included on the initrd and puts this > information in the Built-Using field of the binary package. > > Comments, welcome :-) Great start, though Built-Using expects source packages instead of binary (or udeb) packages. Cheers Luk -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e3416ec.3060...@debian.org
Bug#636040: finish-install: hvc0 console added to inittab even when not available
On Sat, 2011-07-30 at 15:28 +0100, Dominic Benson wrote: > On 30 Jul 2011, at 14:56, Ian Campbell wrote: > I attach a patch that I've used (against 2.22). It does, for me, > prevent the problem on systems that I can test. > > I tried it under Citrix Xencenter, and the inittab entry for this > console is (correctly) added. Thanks, it looks sane to me. > > You mentioned a previous block which added another hvc0 (with vt100), is > > that the one inside the "if [ -e $DT_ROOT/chosen/linux,stdout-path ]; > > then" block? I think that one is safe. > > OK. I'm not really sure under what real circumstances it would be entered. > > My concern was that, if it is used, as /sys/bus/xen and /dev/hvc0 must > both exist, two inittab lines would be produced with the same id. > It strikes me that that would be in some way bad, although I haven't > tried it. The $DT stuff is for systems using Device Tree with an HVC console and not any system currently supported by Xen (it's used by e.g. a PowerPC hypervisor, I think). It appears that the DT stuff is checking for specific machines and/or explicit hvc0 configurations. However we may as well switch the Xen case "if" into an "elif" after the DT case, then if a system which uses both Xen and DT appears it will only hit the DT case (which would be arguably the more correct one to trust in those circumstances). e.g. (untested): diff --git a/finish-install.d/90console b/finish-install.d/90console index 9886724..272e0a1 100755 --- a/finish-install.d/90console +++ b/finish-install.d/90console @@ -136,9 +136,7 @@ if [ -e $DT_ROOT/chosen/linux,stdout-path ]; then "$upstart_tty1" > "$(upstart_console "$console")" sed -i -e "s/^\(exec.*\) -8/\1/" "$(upstart_console "$console")" fi -fi - -if [ -e /sys/bus/xen ]; then +elif [ -e /sys/bus/xen ] && [ -e /dev/hvc0 ]; then console=hvc0 log "Setting up virtualized serial console on /dev/$console" if [ -f /target/etc/inittab ]; then Ian. -- Ian Campbell Why won't you let me kiss you goodnight? Is it something I said? -- Tom Ryan signature.asc Description: This is a digitally signed message part
Re: Changes to Debian Installer release process
On 07/28/2011 01:18 PM, Otavio Salvador wrote: > I used some of Debcamp and Debconf time this year to discuss the > Debian Installer release process with some people and after talking > with many people it seems we agreed on the following changes on Debian > Installer release process and it would be interesting to receive > feedback on those to see if anyone see a problem we didn't notice yet. Great, lets make d-i as easy to handle as general packages (or at least almost ;-))! > * Official uploads to be built against unstable Sounds good. > * Linux kernel udebs to be built from linux source package Also looks good. > * Debian Installer daily builds to be done from source uploads > >The daily builds will use the archive source for building so every > time we do a change in unstable in a module that is included in initrd > it will trigger a binNMU in all architectures replicating what we have > in daily builds. When source changes in debian-installer source > package are done, a new source upload will be required. Do the daily builds only uncover issues from building the initrd? A.k.a. will changes in packages other than the one in the initrd only have an effect on the install via genuine downloading from the archive at the time of the install? > * Debian Installer experimental builds > >With Linux kernel udebs built from linux source we have the > possibility to get the installer built against the development kernel > that will be available on experimental and this is quite important to > us to be able to test all this before it is available in unstable to > avoid bad surprises for us and users. This will also be a handy tool > for us to play with not well tested or finished stuff without breaking > installer to end users. Sounds good! > * Use of britney to handle package and installer migration > >This is the end of the process and some details are yet unknown how > this is going to happen however but our goal is to make it happen > since it will alleviate a lot the amount of work to make Debian > Installer release to happen. Super! > It is important to notice that it is not a single-man effort but a > coordinate and shared effort of Debian Kernel, Debian Release and > Debian Installer teams to get all this done. Those changes are not > going to happen at once but in a progressive process and at the end > this is going to make the installer release process easier to > understand and handle. Right, lets go for it! Cheers Luk -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e341d9a.1040...@debian.org
Bug#636040: finish-install: hvc0 console added to inittab even when not available
On 30 Jul 2011, at 15:57, Ian Campbell wrote: > On Sat, 2011-07-30 at 15:28 +0100, Dominic Benson wrote: >> >> OK. I'm not really sure under what real circumstances it would be entered. >> >> My concern was that, if it is used, as /sys/bus/xen and /dev/hvc0 must >> both exist, two inittab lines would be produced with the same id. >> It strikes me that that would be in some way bad, although I haven't >> tried it. > > The $DT stuff is for systems using Device Tree with an HVC console and > not any system currently supported by Xen (it's used by e.g. a PowerPC > hypervisor, I think). It appears that the DT stuff is checking for > specific machines and/or explicit hvc0 configurations. > > However we may as well switch the Xen case "if" into an "elif" after the > DT case, then if a system which uses both Xen and DT appears it will > only hit the DT case (which would be arguably the more correct one to > trust in those circumstances). Ahh, that sounds like a good plan in that case. The adjusted patch looks fine to me. [there remains no currently effective 'is XEN' test, but using /dev/hvc0, if it exists, precisely once, sounds reasonable] Dominic -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1809a69a-bb69-4f96-8d02-bf20b5ebf...@thirdlight.com
Re: [RFC] Use of Built-Using in debian-installer
On Sat, Jul 30, 2011 at 16:36, Luk Claes wrote: > On 07/30/2011 06:23 AM, Otavio Salvador wrote: >> Basically it gather all udebs included on the initrd and puts this >> information in the Built-Using field of the binary package. >> >> Comments, welcome :-) > > Great start, though Built-Using expects source packages instead of > binary (or udeb) packages. Mostly fixed in my local repository; will post it soon. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAP9ODKrBUFEN1GALcK3W9Psyir84frr=rqjrojk2uadpbjd...@mail.gmail.com
Re: Changes to Debian Installer release process
On Sat, Jul 30, 2011 at 17:04, Luk Claes wrote: ... >> * Debian Installer daily builds to be done from source uploads >> >> The daily builds will use the archive source for building so every >> time we do a change in unstable in a module that is included in initrd >> it will trigger a binNMU in all architectures replicating what we have >> in daily builds. When source changes in debian-installer source >> package are done, a new source upload will be required. > > Do the daily builds only uncover issues from building the initrd? A.k.a. > will changes in packages other than the one in the initrd only have an > effect on the install via genuine downloading from the archive at the > time of the install? Mostly; the only addition situation we'll need to rebuild the installer is when the amount of translation changes for a specific language so we get the 'translation-status' file updated into the initrd. Cheers, -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cap9odkpinxtg0z7neo1mye-jgrx_lh1tmry0_q3nm1g8z9e...@mail.gmail.com
Re: [RFC] Use of Built-Using in debian-installer
On Sat, Jul 30, 2011 at 17:05, Otavio Salvador wrote: > On Sat, Jul 30, 2011 at 16:36, Luk Claes wrote: >> On 07/30/2011 06:23 AM, Otavio Salvador wrote: >>> Basically it gather all udebs included on the initrd and puts this >>> information in the Built-Using field of the binary package. >>> >>> Comments, welcome :-) >> >> Great start, though Built-Using expects source packages instead of >> binary (or udeb) packages. > > Mostly fixed in my local repository; will post it soon. So I got it done; please take a look at it. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br control Description: Binary data
Bug#636040: finish-install: hvc0 console added to inittab even when not available
Hello On Sat, Jul 30, 2011 at 15:10, Dominic Benson wrote: > Package: finish-install > Version: 2.32 > Severity: normal > > finish-install 90console script checks for the existence of > /sys/bus/xen to determine whether to add a console on > /dev/hvc0 - but in 2.6.38 / 2.6.39 this always appears to exist. Ian, do you mind to have a look at this? -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cap9odkr9ptc-zvtjmg7tocwdfaaanrhpd5xustfrfyqzba3...@mail.gmail.com
Re: [RFC] Use of Built-Using in debian-installer
On Sat, Jul 30, 2011 at 17:18:28 +0200, Otavio Salvador wrote: > On Sat, Jul 30, 2011 at 17:05, Otavio Salvador > wrote: > > On Sat, Jul 30, 2011 at 16:36, Luk Claes wrote: > >> On 07/30/2011 06:23 AM, Otavio Salvador wrote: > >>> Basically it gather all udebs included on the initrd and puts this > >>> information in the Built-Using field of the binary package. > >>> > >>> Comments, welcome :-) > >> > >> Great start, though Built-Using expects source packages instead of > >> binary (or udeb) packages. > > > > Mostly fixed in my local repository; will post it soon. > > So I got it done; please take a look at it. > Looks sane from a quick look. Can we also see the code that generates this, maybe? Cheers, Julien -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110730155423.gp32...@radis.liafa.jussieu.fr
Processed: reassign 635968 to grub-installer, tagging 635968
Processing commands for cont...@bugs.debian.org: > reassign 635968 grub-installer Bug #635968 [installation-reports] installation-reports: Initial boot after installation failed Bug reassigned from package 'installation-reports' to 'grub-installer'. > tags 635968 + pending Bug #635968 [grub-installer] installation-reports: Initial boot after installation failed Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 635968: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635968 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: http://lists.debian.org/handler.s.c.13120429219322.transcr...@bugs.debian.org
Re: [RFC] Use of Built-Using in debian-installer
Julien Cristau wrote: > On Sat, Jul 30, 2011 at 17:18:28 +0200, Otavio Salvador wrote: > >> So I got it done; please take a look at it. >> > Looks sane from a quick look. Can we also see the code that generates > this, maybe? FYI, I did this in win32-loader (but not pushed yet as my smartcard with ssh+gpg subkeys on broke): http://alioth.debian.org/~odyx-guest/0001-Use-the-Built-Using-field-and- enhance-the-sources-do.patch -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/j11bnq$itn$1...@dough.gmane.org
Bug#635968: installation-reports: Initial boot after installation failed
Ralf Jung wrote: >> So far, I for one haven't seen a system which requires a >> partition _table_ to boot, not to mention a bootable >> partition in it. BIOS merely loads first 512 bytes of >> a disk into memory and jumps into that area, without >> trying to interpret what's inside. Unless you use some >> recovery/diagnostic mode which is embedded into some >> BIOSes/machines. >Well, that was my understanding as well, but my laptop just proofed us wrong >;-) . Maybe this is related to the "mainboard firmware" actually being some >EFI >or UEFI thingy with a BIOS compatibility layer. In any case, the Ubuntu >installer deals with this correctly, I never had any issues booting from HDD >before trying Debian as main OS (CDs are a different matter though). The BIOS on all[1] IBM-PC-compatible systems validates the Master Boot Record[2] for the MBR signature ($55, $AA) in bytes 510 and 511 in the first block of the hard disk. This avoids jumping to random noise on an uninitialized disk. Some[3] BIOS vendors also validate the presence of at least one bootable partition by looking for the BOOT flag, located in the first byte of each partition record, as an additional check. It would seem prudent that the Debian Installer set this flag appropriately. --Don [1] I know of no exceptions, for the reason stated. Even GPT includes a legacy MBR. [2] http://en.wikipedia.org/wiki/Master_boot_record [3] I've encountered boot failures for this reason more than once, but can't tell if the successful installs on various systems were due to ignoring the BOOT flag or having one correctly set. I tend to partition manually so haven't been concerned enough about any failures to research a bug report. -- Retro tagline: On a clear disk you can seek forever. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/bn9837h0nc5832p4q9f2cuam9dl3ubn...@4ax.com
[PATCH 1/2] Use upload suite as origin to udebs
---
debian/changelog |1 +
debian/rules |6 +-
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index 5a53ac8..cb9c975 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -90,6 +90,7 @@ debian-installer (2011) UNRELEASED; urgency=low
[ Otavio Salvador ]
* Update Linux kernel to 3.0.0-1
+ * Use upload suite as origin to udebs
-- Robert Millan Fri, 15 Jul 2011 23:34:48 +0200
diff --git a/debian/rules b/debian/rules
index a434c5f..a659a5e 100755
--- a/debian/rules
+++ b/debian/rules
@@ -9,8 +9,12 @@ USE_UDEBS_FROM=unstable
TRANSSTATUS=
BOOTMENU_BEEP=n
else
-USE_UDEBS_FROM=wheezy
+USE_UDEBS_FROM=$(SUITE)
+ifeq (,$(filter stable wheezy stable-proposed-updates
wheezy-proposed-updates,${SUITE}))
USE_PROPOSED_UPDATES=0
+else
+USE_PROPOSED_UPDATES=1
+endif
TRANSSTATUS=translation-status
BOOTMENU_BEEP=y
endif
--
1.7.5.4
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/1312051150-13754-1-git-send-email-ota...@ossystems.com.br
[PATCH 2/2] Output information of all used udebs into the debian-installer binary package for usage by the archive tool
---
build/Makefile |7 +++
build/util/write-built-using |8
debian/changelog |2 ++
debian/control |1 +
debian/rules |3 +++
5 files changed, 21 insertions(+), 0 deletions(-)
create mode 100755 build/util/write-built-using
diff --git a/build/Makefile b/build/Makefile
index e2c5da0..6ee9089 100644
--- a/build/Makefile
+++ b/build/Makefile
@@ -350,12 +350,19 @@ endif
usedblocks=`echo $$newblocks - $$oldblocks | bc`; \
usedcount=`echo $$newcount - $$oldcount | bc`; \
version=`dpkg-deb --info $$udeb | grep '^ *Version:' |
sed 's/^ *//' | awk '{print $$2}'` ; \
+ source=`dpkg-deb --info $$udeb | grep '^ *Source:' |
sed 's/^ *//' | awk '{print $$2}'` ; \
+ if [ -z "$$source" ]; then \
+ source=`dpkg-deb --info $$udeb | grep '^
*Package:' | sed 's/^ *//' | awk '{print $$2}'` ; \
+ fi ; \
echo " $$usedsize B - $$usedblocks blocks - $$usedcount
files from $$pkg (version $$version)" >>$(TEMP)/diskusage.txt;\
+ echo "$$source (= $$version)"
>>$(TEMP)/built-using.txt;\
oldsize=$$newsize ; \
oldblocks=$$newblocks ; \
oldcount=$$newcount ; \
fi; \
done
+ sort -u < $(TEMP)/built-using.txt > $(TEMP)/built-using.txt.new && \
+ mv $(TEMP)/built-using.txt.new $(TEMP)/built-using.txt
sort -n < $(TEMP)/diskusage.txt > $(TEMP)/diskusage.txt.new && \
mv $(TEMP)/diskusage.txt.new $(TEMP)/diskusage.txt
grep-dctrl -nsPackage,Version,Architecture ''
$(TREE)/var/lib/dpkg/status | \
diff --git a/build/util/write-built-using b/build/util/write-built-using
new file mode 100755
index 000..97beb13
--- /dev/null
+++ b/build/util/write-built-using
@@ -0,0 +1,8 @@
+#!/bin/sh
+
+echo -n "initrd:Built-Using=" >> debian/debian-installer.substvars
+cat build/tmp/*/built-using.txt \
+| sort -u \
+| tr "\n" "," \
+| sed 's/,/, /g;s/, $//g' >> debian/debian-installer.substvars
+echo >> debian/debian-installer.substvars
diff --git a/debian/changelog b/debian/changelog
index cb9c975..b9fd9d0 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -91,6 +91,8 @@ debian-installer (2011) UNRELEASED; urgency=low
[ Otavio Salvador ]
* Update Linux kernel to 3.0.0-1
* Use upload suite as origin to udebs
+ * Output information of all used udebs into the debian-installer
+binary package for usage by the archive tool
-- Robert Millan Fri, 15 Jul 2011 23:34:48 +0200
diff --git a/debian/control b/debian/control
index f8e9bbd..9aef650 100644
--- a/debian/control
+++ b/debian/control
@@ -161,6 +161,7 @@ Build-Depends:
Package: debian-installer
Architecture: any
+Built-Using: ${initrd:Built-Using}
Description: Debian installer
This package currently only contains some documentation for the Debian
installer. We welcome suggestions about what else to put in it.
diff --git a/debian/rules b/debian/rules
index a659a5e..9cf4ef0 100755
--- a/debian/rules
+++ b/debian/rules
@@ -66,6 +66,9 @@ binary-arch: install
-X internals.xml -X partman-doc.sgml
dh_compress
dh_fixperms
+
+ ./build/util/write-built-using
+
dh_gencontrol
dh_md5sums
dh_builddeb
--
1.7.5.4
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/1312051150-13754-2-git-send-email-ota...@ossystems.com.br
Re: [RFC] Use of Built-Using in debian-installer
On Sat, Jul 30, 2011 at 17:54, Julien Cristau wrote: > Looks sane from a quick look. Can we also see the code that generates > this, maybe? I sent the two patches I have queued to push to mailing list; please comment on them. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cap9odkoeo0nn6wtlu+6aabr5qtb0+5_nd4emv46aaj3mxxk...@mail.gmail.com
Re: Changes to Debian Installer release process
Quoting Otavio Salvador (ota...@ossystems.com.br): > Mostly; the only addition situation we'll need to rebuild the > installer is when the amount of translation changes for a specific > language so we get the 'translation-status' file updated into the > initrd. We might need to find a way to avoid rebuilding just because *one* language changed. Mostly because this happens really often..we don't really have control about the translator's schedule and they happen to commit things more or less randomly (with peaks when something is changed in a string, or when strings are added: some like to be 100% all time long..:-)). As I'm watching all this very regularly, we could maybe imagine something where the i18n coordinator can trigger an l10n-rebuild because (s)he notices that a given language changed significantly enough to be worth itor because it has been too much time since the last rebuild and many very small changes piled up. signature.asc Description: Digital signature
Re: Changes to Debian Installer release process
On Sat, Jul 30, 2011 at 22:12, Christian PERRIER wrote: > Quoting Otavio Salvador (ota...@ossystems.com.br): >> Mostly; the only addition situation we'll need to rebuild the >> installer is when the amount of translation changes for a specific >> language so we get the 'translation-status' file updated into the >> initrd. > > We might need to find a way to avoid rebuilding just because *one* > language changed. Mostly because this happens really often..we don't > really have control about the translator's schedule and they happen to > commit things more or less randomly (with peaks when something is > changed in a string, or when strings are added: some like to be 100% > all time long..:-)). But this will change only when we upload the package to the archive so we can try to upload a set of packages with translation updates to avoid this. Basically the binNMU would be triggered when the translation status change for a language and since we work with percentage this will not change on every translation update. > As I'm watching all this very regularly, we could maybe imagine > something where the i18n coordinator can trigger an l10n-rebuild > because (s)he notices that a given language changed significantly > enough to be worth itor because it has been too much time since > the last rebuild and many very small changes piled up. Or maybe if there's no initrd changes queue it to the end of week if nothing else changes? -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cap9odko0ent87kdj_cevexzwi+g+iedn8r9__kqgluzn7_u...@mail.gmail.com
Bug#635854: [rescue] Wheezy Rescue mode won't chroot to ext4
Hi, i've just tried the businesscard images for amd64 and i386 under Virtualbox. amd64 works as expected, the console appears with the mounted filesystem. i386 doesn't throw a shell to the mounted partition as expected, but the filesystem is mounted in /target. In both logs appears the following messages: Jul 30 21:39:51 rescue-mode: selected root device '/dev/sda1' Jul 30 21:39:51 rescue: umount: can't umount /target: Invalid argument Jul 30 21:39:51 kernel: [ 44.183793] EXT2-fs (sda1): error: couldn't mount because of unsupported optional features (244) Jul 30 21:39:51 kernel: [ 44.184494] EXT3-fs (sda1): error: couldn't mount because of unsupported optional features (240) Jul 30 21:39:51 kernel: [ 44.219889] EXT4-fs (sda1): recovery complete Jul 30 21:39:51 kernel: [ 44.220081] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) -- Melhores cumprimentos/Best Regards, Miguel Figueiredo http://www.DebianPT.org 20110730_syslog_BR635854_i386.gz Description: GNU Zip compressed data 20110730_syslog_BR635854_amd64.gz Description: GNU Zip compressed data
Bug#576309: marked as done (Should consider rewording grub-installer templates to abetter fit 2010 device names)
Your message dated Sat, 30 Jul 2011 23:47:17 + with message-id and subject line Bug#576309: fixed in grub-installer 1.66 has caused the Debian Bug report #576309, regarding Should consider rewording grub-installer templates to abetter fit 2010 device names 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 ow...@bugs.debian.org immediately.) -- 576309: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=576309 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: installation-reports Severity: minor Tags: l10n When configuring grub-pc, a sample says (in Brazilian Portuguese): - "(hd2,4)" ou "/dev/hda" utilizará a primeira partição estendida de seu terceiro disco (aqui SCSI); I think the correct is: - "(hd2,4)" ou "/dev/sdc5" utilizará a primeira partição lógica de seu terceiro disco (aqui SCSI ou SATA); In other words: s/hda/sdc5/, s/estendida/lógica/, s/SCSI/SCSI ou SATA/. Regards, Eriberto - Brazil -- Package-specific info: Boot method: CD NetInst Image version: Squeeze Alpha1, March 22, 2010 -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.32-3-686-bigmem (SMP w/2 CPU cores) Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash --- End Message --- --- Begin Message --- Source: grub-installer Source-Version: 1.66 We believe that the bug you reported is fixed in the latest version of grub-installer, which is due to be installed in the Debian FTP archive: grub-installer_1.66.dsc to main/g/grub-installer/grub-installer_1.66.dsc grub-installer_1.66.tar.gz to main/g/grub-installer/grub-installer_1.66.tar.gz grub-installer_1.66_amd64.udeb to main/g/grub-installer/grub-installer_1.66_amd64.udeb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 576...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Otavio Salvador (supplier of updated grub-installer package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 31 Jul 2011 01:42:48 +0200 Source: grub-installer Binary: grub-installer Architecture: source amd64 Version: 1.66 Distribution: unstable Urgency: low Maintainer: Debian Install System Team Changed-By: Otavio Salvador Description: grub-installer - Install GRUB on a hard disk (udeb) Closes: 576309 635968 Changes: grub-installer (1.66) unstable; urgency=low . [ Colin Watson ] * Update grub-installer/bootdev text to avoid GRUB device naming that changed between GRUB Legacy and GRUB 2, and to use libata-style device naming since that is more accurate for most people (closes: #576309). * Unless grub-installer/make_active is preseeded to false, mark the partition to which GRUB is being installed as bootable, or failing that the first available primary partition on the disk to which GRUB is being installed (closes: #635968). . [ Otavio Salvador ] * debian/control: build-depends on libparted-dev . [ Updated translations ] * Basque (eu.po) * Hebrew (he.po) by Lior Kaplan * Macedonian (mk.po) by Arangel Angov * Sinhala (si.po) by Danishka Navin Checksums-Sha1: 78cc1aebc49c7fdfe2b0d7836be630ffa0ca08b3 1725 grub-installer_1.66.dsc 634f8e73112818f6b407774583f7d10eddc6a0ba 189686 grub-installer_1.66.tar.gz d2143a3a53932e859bf0cd0a213cbb3ca635aaf8 155650 grub-installer_1.66_amd64.udeb Checksums-Sha256: 4ffd75f0c0882dc98da10e079db51cff6124bad897a6f6045ec3f6bb9df0b48e 1725 grub-installer_1.66.dsc 41510496b3f2b728fe2dbd32160483e2837c510a502ad7ac2c3a97ebc9aa2b00 189686 grub-installer_1.66.tar.gz b490c7ec7f7a4cce45b9c9248d921aa86575d6dccb1641aaac5629b9a2c20ee5 155650 grub-installer_1.66_amd64.udeb Files: 25b9759ccb16e9077130de0481da73ce 1725 debian-installer standard grub-installer_1.66.dsc 214a98ae92a97e393cc91b192b616b16 189686 debian-installer standard grub-installer_1.66.tar.gz ae841e569b8e7c987195a392eff3cbba 155650 debian-installer standard grub-installer_1.66_amd64.udeb Package-Type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJONJcnAAoJEOtw/vPN/G5PPk0P/Agm7JjRaOw/u4NRnBUbmSKH 7tjXXSvmaiu81+9Xr6eoh/n+j30U1cCkCEwoEJzJ1kyDPQIL2sThn
Bug#635968: marked as done (installation-reports: Initial boot after installation failed)
Your message dated Sat, 30 Jul 2011 23:47:17 + with message-id and subject line Bug#635968: fixed in grub-installer 1.66 has caused the Debian Bug report #635968, regarding installation-reports: Initial boot after installation failed 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 ow...@bugs.debian.org immediately.) -- 635968: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635968 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: installation-reports Severity: grave Tags: d-i Justification: renders package unusable Boot method: CD Image version: http://cdimage.debian.org/cdimage/daily-builds/daily/arch- latest/amd64/iso-cd/debian-testing-amd64-netinst.iso Date: July 27th, 2011 Machine: HP Compaq 615 Processor: AMD Athlon(tm)X2 DualCore QL-66 Memory: 4 GiB Partitions: Device Boot Start End Blocks Id System /dev/sda1 *2048 1228761438976 83 Linux /dev/sda2 12288 131071999 4096000 82 Linux swap / Solaris /dev/sda3 131074046 625141759 2470338575 Extended /dev/sda5 131074048 625141759 247033856 83 Linux Output of lspci -knn (or lspci -nn): 00:00.0 Host bridge [0600]: Advanced Micro Devices [AMD] RS780 Host Bridge [1022:9600] Subsystem: Hewlett-Packard Company Device [103c:308c] 00:01.0 PCI bridge [0604]: Advanced Micro Devices [AMD] RS780/RS880 PCI to PCI bridge (int gfx) [1022:9602] 00:04.0 PCI bridge [0604]: Advanced Micro Devices [AMD] RS780 PCI to PCI bridge (PCIE port 0) [1022:9604] Kernel driver in use: pcieport 00:07.0 PCI bridge [0604]: Advanced Micro Devices [AMD] RS780 PCI to PCI bridge (PCIE port 3) [1022:9607] Kernel driver in use: pcieport 00:09.0 PCI bridge [0604]: Advanced Micro Devices [AMD] RS780/RS880 PCI to PCI bridge (PCIE port 4) [1022:9608] Kernel driver in use: pcieport 00:11.0 SATA controller [0106]: ATI Technologies Inc SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] [1002:4391] Subsystem: Hewlett-Packard Company Device [103c:308c] Kernel driver in use: ahci 00:12.0 USB Controller [0c03]: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397] Subsystem: Hewlett-Packard Company Device [103c:308c] Kernel driver in use: ohci_hcd 00:12.1 USB Controller [0c03]: ATI Technologies Inc SB7x0 USB OHCI1 Controller [1002:4398] Subsystem: Hewlett-Packard Company Device [103c:308c] Kernel driver in use: ohci_hcd 00:12.2 USB Controller [0c03]: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB EHCI Controller [1002:4396] Subsystem: Hewlett-Packard Company Device [103c:308c] Kernel driver in use: ehci_hcd 00:13.0 USB Controller [0c03]: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397] Subsystem: Hewlett-Packard Company Device [103c:308c] Kernel driver in use: ohci_hcd 00:13.1 USB Controller [0c03]: ATI Technologies Inc SB7x0 USB OHCI1 Controller [1002:4398] Subsystem: Hewlett-Packard Company Device [103c:308c] Kernel driver in use: ohci_hcd 00:13.2 USB Controller [0c03]: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB EHCI Controller [1002:4396] Subsystem: Hewlett-Packard Company Device [103c:308c] Kernel driver in use: ehci_hcd 00:14.0 SMBus [0c05]: ATI Technologies Inc SBx00 SMBus Controller [1002:4385] (rev 3a) Subsystem: Hewlett-Packard Company Device [103c:308c] Kernel driver in use: piix4_smbus 00:14.2 Audio device [0403]: ATI Technologies Inc SBx00 Azalia (Intel HDA) [1002:4383] Subsystem: Hewlett-Packard Company Device [103c:308c] Kernel driver in use: HDA Intel 00:14.3 ISA bridge [0601]: ATI Technologies Inc SB7x0/SB8x0/SB9x0 LPC host controller [1002:439d] Subsystem: ATI Technologies Inc SB7x0/SB8x0/SB9x0 LPC host controller [1002:439d] 00:14.4 PCI bridge [0604]: ATI Technologies Inc SBx00 PCI to PCI Bridge [1002:4384] 00:14.5 USB Controller [0c03]: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB OHCI2 Controller [1002:4399] Subsystem: Hewlett-Packard Company Device [103c:308c] Kernel driver in use: ohci_hcd 00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] Family 11h Processor HyperTransport Configuration [1022:1300] (rev 40) 00:18.1 Host bridge [0600]: Advanced Micro Devices [AMD] Family 11h Processor Address Map [1022:1301] 00:18.2 Host bridge [0600]: Advanced Micro Devices [AMD] Family 11h Processor DRAM Controller [1022:1302] 00:18.3 Host bridge [0600]: Advanced Micro Devices [AMD] Family 11h Processor Miscellaneous Control [1022:1303] Kernel driver in use: k10temp 00:
Processing of grub-installer_1.66_amd64.changes
grub-installer_1.66_amd64.changes uploaded successfully to localhost along with the files: grub-installer_1.66.dsc grub-installer_1.66.tar.gz grub-installer_1.66_amd64.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: http://lists.debian.org/e1qnjeo-0003pe...@franck.debian.org
grub-installer_1.66_amd64.changes ACCEPTED into unstable
Accepted: grub-installer_1.66.dsc to main/g/grub-installer/grub-installer_1.66.dsc grub-installer_1.66.tar.gz to main/g/grub-installer/grub-installer_1.66.tar.gz grub-installer_1.66_amd64.udeb to main/g/grub-installer/grub-installer_1.66_amd64.udeb Override entries for your package: grub-installer_1.66.dsc - source debian-installer grub-installer_1.66_amd64.udeb - standard debian-installer Announcing to debian-devel-chan...@lists.debian.org Closing bugs: 576309 635968 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: http://lists.debian.org/e1qnjfv-0003sg...@franck.debian.org
Debconf11 multiarch-related-items meeting notes
We held a meeting during debconf discussing policy on things which multiarch enables: partial architectures, cross-compilers in the archive, cross-comiled uploads, and a few other things. I've posted the meeting notes here: http://wiki.debian.org/Multiarch/Debconf11MultiarchRelatedMinutes reproduced here: Multiarch cross-architecture meeting minutes Held at Debconf 11 2011-07-26. 5pm Present. Approx 12 people, including Steve Langasek(vorlon) (chairing), Wookey (minuting), Mark Hymers(mhy) (FTPmasters), Adam Barratt(adsb) (Release team), Andreas Barth(aba) (Release team), Steve McIntyre(sledge) (Install Media team), Mattias Klose(doko) (gcc maintainer), Aurellien Jarno(aurel32) (eglibc maintainer, ports buildd maintainer), Neil Mcgovern(maulkin) (release team), Tollef Fog Heen(mithrandir), Goswin von Brederlow(goswin), Philip Kaluza(pixelpapst) (minuting) + 1 other (sorry, don't know name) All errors in these notes are Wookey's fault. A lot of people said a lot of things, and getting down the significant points of what was said without missing anything important was not particularly easy, so there are probably a few things missing, and potentially some misrepresentations (although few comments are attributed). please just fix up anything that needs it. (Philip Kaluza's version of the minutes is also included below). Agenda for meeting roughly: * keep grub-pc in amd64 ? * partial architectures ? * what to do with gcc-multilib * cross-compilers in archive * cool things to do in the future * stuff that's not arch-independant in contents, but is in there use. (firmware etc.) * How to manage install media Firstly: are there any serious blockers (e.g. dpkg) before usingmultiarch in main. In short, 'No'. Partial arches? Use cases: 1. 'almost complete' e.g amd64, but with 32-bit grub. 2. 'optimised' (a few packages). Also ABI-incompatible and optimised: These are not the same, but could probably most easily be treated the same by infrastructure. Examples of partial arches are: * sparc64 and ppc64: could expand to full arch, win32 won't. (this is a relatively exotic 'future' possibility dak (on the ftpmaster side) doesn't care whether a package set is closed across an arch but britney (release team) does. Some discussion of when it is useful to have mixed 64/32 arch or not. What packages are pointless in 64-bit form on sparc64, for example. x86_64 is faster than x86_32, but sparc64 is not faster than sparc32 (so no real point making it a full arch). Build/release people would like to see the definition of an arch being: Arch is something that has to be built on that arch (where arch is a set). This works well for 64/32 or i386+i686. Archive size: are there major restrictions? ftpmasters: It's already way too big so lets just press on. Biggest churn is in dists. mirror pulse size is more costly than disk size. Are we going to have smaller package files? Maybe - this depends on implementation. In a small partial arch we can merge small extra files into host arch package. Is this a good idea? Does apt do the right thing anyway? It should do Needs testing. likely partial arches: i686, ppc64, sparc64, s390x, mips64, arm/x86 optimisations? ABI-comptible optimisations are not the same as ABI-incompatible. But could be treated the same way. As well as sparc64 needing base sparc packages, sparc has a sparc64 kernel. So neither arch is complete alone. (but definition of both as needing in both works) Does allowing partials mean that incentive to move base build of a port forward (eg would we still be using 286) is removed? No, because toolchain support is dropped eventually. We still need to drop old stuff and move base along. What if you have i386/686/amd64 all on one machine/install. Discussion about installing with 3 DVDs until you have all arches you want. How should install media work? Agreement: Need to have correct user interface for this. For upgrades as well as installs. reportbug needs to report the arch of package. Otherwise we have no chance of reproducing bugreports. So does popcon. vorlon: dpkg -l should do the right thing already. Can we drop 32 and 64-bit 'foreign' kernels now? (i.e -amd64 kernel from i386) Kernel team would like to do it now, but may well have to wait one release. (ask kernel team for input) Big picture: How to handle first upgrade to MultiArch ? That may need release-note update to say 'get this package first', then do dist-upgrade. This always causes some breakage. How do we decide on arch qualification for release? someone needs to define some criteria. How do we define the set of stuff for percent-built? Subject needs work. Do we want to get rid of anything depending on gcc-multilib? Doko wants to keep mulitilib capability. Cross-compilers in the archive Are we going to upload some. How do we decide which set? How do we implement cross-builds. From gcc package? gcc maintain
Debian installer build: failed or old builds
Debian installer build overview --- Failed or old builds: * FAILED BUILD: mipsel Jul 31 00:06 buildd@rem build_cobalt_netboot-2.6_serial http://d-i.debian.org/daily-images/mipsel/daily/build_cobalt_netboot-2.6_serial.log * FAILED BUILD: mipsel Jul 31 00:07 buildd@rem build_cobalt_netboot-2.6_ssh http://d-i.debian.org/daily-images/mipsel/daily/build_cobalt_netboot-2.6_ssh.log * FAILED BUILD: mipsel Jul 31 00:07 buildd@rem build_cobalt_netboot-2.6_common http://d-i.debian.org/daily-images/mipsel/daily/build_cobalt_netboot-2.6_common.log * FAILED BUILD: mipsel Jul 31 00:07 buildd@rem build_malta_netboot-2.6 http://d-i.debian.org/daily-images/mipsel/daily/build_malta_netboot-2.6.log * FAILED BUILD: mipsel Jul 31 00:08 buildd@rem build_sb1-bcm91250a_netboot-2.6 http://d-i.debian.org/daily-images/mipsel/daily/build_sb1-bcm91250a_netboot-2.6.log * FAILED BUILD: mipsel Jul 31 00:08 buildd@rem build_loongson-2f_netboot-2.6 http://d-i.debian.org/daily-images/mipsel/daily/build_loongson-2f_netboot-2.6.log * FAILED BUILD: amd64 Jul 30 21:50 debian-cd@pettersson 1sidamd64 http://cdbuilder.debian.org/cdimage-log/1sidamd64 * FAILED BUILD: amd64 Jul 30 21:50 debian-cd@pettersson 2sidamd64 http://cdbuilder.debian.org/cdimage-log/2sidamd64 * FAILED BUILD: amd64 Jul 30 21:50 debian-cd@pettersson Csidamd64 http://cdbuilder.debian.org/cdimage-log/Csidamd64 * FAILED BUILD: amd64 Jul 30 21:52 debian-cd@pettersson 1sidi386 http://cdbuilder.debian.org/cdimage-log/1sidi386 * FAILED BUILD: amd64 Jul 30 21:53 debian-cd@pettersson 2sidi386 http://cdbuilder.debian.org/cdimage-log/2sidi386 * FAILED BUILD: amd64 Jul 30 21:53 debian-cd@pettersson Csidi386 http://cdbuilder.debian.org/cdimage-log/Csidi386 * FAILED BUILD: amd64 Jul 30 22:02 debian-cd@pettersson 2sidmulti-arch-1 http://cdbuilder.debian.org/cdimage-log/2sidmulti-arch-1 * FAILED BUILD: amd64 Jul 30 22:02 debian-cd@pettersson Csidmulti-arch-1 http://cdbuilder.debian.org/cdimage-log/Csidmulti-arch-1 Totals: 107 builds (14 failed, 0 old) -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1qnknw-0006yb...@ravel.debian.org
