Commit r59674 is breaking HPPA builds
Hi Colin, Daily builds for HPPA have been failing for some time with: E: Couldn't find package input-modules-2.6.30-1-parisc-di make[2]: *** [stamps/get_udebs-netboot-stamp] Error 100 make[1]: *** [_build] Error 2 make: *** [build_netboot] Error 2 After reverting r59674 they work again, so something must be wrong with that change. Can you look into it please? Thanks, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Commit r59674 is breaking HPPA builds
On Saturday 01 August 2009, Frans Pop wrote:
> Daily builds for HPPA have been failing for some time with:
> E: Couldn't find package input-modules-2.6.30-1-parisc-di
> make[2]: *** [stamps/get_udebs-netboot-stamp] Error 100
> make[1]: *** [_build] Error 2
> make: *** [build_netboot] Error 2
>
> After reverting r59674 they work again, so something must be wrong with
> that change. Can you look into it please?
Reason seems to be that hppa.cfg has:
KERNELIMAGEVERSION = $(BASEVERSION)-parisc $(BASEVERSION)-parisc64
KERNELVERSION = $(foreach ver,${KERNELIMAGEVERSION},$(ver))
which results in:
grep-dctrl '-!' -rFKernel-Version . -o -XFKernel-Version '2.6.30-1-parisc
2.6.30-1-parisc64'
apt.udeb/state/lists/www.fjphome.nl_debian_dists_unstable_main_debian-installer_binary-hppa_Packages
HPPA is probably the only arch that builds virtually identical images
for two different kernel flavors, but that seems valid.
I've fixed it with commit r59872, which results in:
grep-dctrl '-!' -rFKernel-Version . -o -XFKernel-Version 2.6.30-1-parisc -o
-XFKernel-Version 2.6.30-1-parisc64
apt.udeb/state/lists/www.fjphome.nl_debian_dists_unstable_main_debian-installer_binary-hppa_Packages
Cheers,
FJP
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#538344: tzsetup: base-installer hook script returns error
On Saturday 25 July 2009, Frans Pop wrote: > > Apparently time/zone is empty. I assume that s390 installs have no > > localisation or something? > > I doubt that. localechooser does get run (only for country selection, > language is preseeded to C) and tzsetup should be run normally. > > Hmm, but from the log (and a retry) it does not look to be run at all. > In fact, it is not even listed in the menu... AFAIK that in itself is a > regression. > Looks like tzsetup is installed (it is in /v/l/dpkg/status and > templates are present), but there is no tzsetup-udeb.postinst in > /v/l/dpkg/info. Hmmm. It looks like this is a relatively old issue. Once upon a time tzsetup had its own postinst, but it is now called from clock-setup. And clock-setup is not built for s390, I suspect because the installer is not supposed to mess with the system clock of an s/390 system. So, currently tzsetup does get installed on s390 (as it is Priority standard), but the tzsetup script never gets executed. And that results in time/zone being empty. But tzsetup definitely should be run, so we need some kind of special handling here. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Processed: Re: Bug#538344: tzsetup: base-installer hook script returns error
Processing commands for cont...@bugs.debian.org: > retitle 538344 [s390] tzsetup never gets executed because of missing > clock-setup Bug #538344 [tzsetup] tzsetup: base-installer hook script returns error Changed Bug title to '[s390] tzsetup never gets executed because of missing clock-setup' from 'tzsetup: base-installer hook script returns error' > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#539502: n2100: base install fails due to time not set properly
Package: installation-reports Severity: normal The N2100 installer does not set the time properly during installation, which causes gpgv to assume all keys have expired and eventually the installation fails: in-target: WARNING: The following packages cannot be authenticated! in-target: mdadm Running apt-get update in the chroot showed this: W: GPG error: http://mirror.switch.ch lenny Release: The following signatures were invalid: KEYEXPIRED 1356982504 KEYEXPIRED 1337087218 After I set the time, I could simply re-run the base install and it all worked. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31-rc3-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- .''`. martin f. krafft Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#539502: n2100: base install fails due to time not set properly
* martin f krafft [2009-08-01 16:03]: > The N2100 installer does not set the time properly during > installation, which causes gpgv to assume all keys have expired and > eventually the installation fails: Yeah, while it worked for etch it seems this no longer works in lenny. I'm away now for a while but I'll look into this in October or so. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Processed: mine
Processing commands for cont...@bugs.debian.org: > owner 539502 ! Bug #539502 [installation-reports] n2100: base install fails due to time not set properly Owner recorded as Martin Michlmayr . > -- Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Processed: Re: Bug#538344: [s390] tzsetup never gets executed because of missing clock-setup
Processing commands for cont...@bugs.debian.org: > reassign 538344 clock-setup Bug #538344 [tzsetup] [s390] tzsetup never gets executed because of missing clock-setup Bug reassigned from package 'tzsetup' to 'clock-setup'. Bug #538344 [clock-setup] [s390] tzsetup never gets executed because of missing clock-setup Bug No longer marked as found in versions 1:0.25. Bug #538344 [clock-setup] [s390] tzsetup never gets executed because of missing clock-setup Ignoring request to alter fixed versions of bug #538344 to the same values previously set > tags 538344 patch Bug #538344 [clock-setup] [s390] tzsetup never gets executed because of missing clock-setup Added tag(s) patch. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#538344: [s390] tzsetup never gets executed because of missing clock-setup
reassign 538344 clock-setup
tags 538344 patch
thanks
On Saturday 01 August 2009, Frans Pop wrote:
> So, currently tzsetup does get installed on s390 (as it is Priority
> standard), but the tzsetup script never gets executed. And that results
> in time/zone being empty.
What do people think of this patch?
Bastian: are you OK with allowing clock-setup for s390 with this patch?
Make clock-setup safe for s390
On s390 D-I is not allowed to change the system clock. However, clock-setup
is also responsible for running tzsetup, which we do want on s390.
Make clock-setup safe for s390 by only running tzsetup in the postinst and
excluding the finish-install script from the udeb.
diff --git a/packages/clock-setup/debian/clock-setup.postinst b/packages/clock-setup/debian/clock-setup.postinst
index 674fdab..29fabf9 100755
--- a/packages/clock-setup/debian/clock-setup.postinst
+++ b/packages/clock-setup/debian/clock-setup.postinst
@@ -7,6 +7,13 @@ log() {
logger -t clock-setup "$@"
}
+# On s390 we're not allowed to change the system clock; just run tzsetup
+case "$(archdetect)" in
+s390/*)
+ tzsetup
+ exit 0 ;;
+esac
+
db_input medium clock-setup/ntp || true
if ! db_go; then
exit 10 # back to main menu
diff --git a/packages/clock-setup/debian/control b/packages/clock-setup/debian/control
index 59da5ef..6a778c2 100644
--- a/packages/clock-setup/debian/control
+++ b/packages/clock-setup/debian/control
@@ -7,8 +7,8 @@ Build-Depends: debhelper (>= 4.1.13), po-debconf
Vcs-Svn: svn://svn.debian.org/d-i/trunk/packages/clock-setup
Package: clock-setup
-Architecture: alpha amd64 arm armel armeb hppa i386 ia64 lpia m68k mips mipsel powerpc sparc kfreebsd-i386 kfreebsd-amd64
-Depends: ${misc:Depends}, localechooser, tzsetup-udeb (>= 1:0.18), configured-network, rdate-udeb (>= 1:1.1.3-2), di-utils (>= 1.66)
+Architecture: any
+Depends: ${misc:Depends}, localechooser, tzsetup-udeb (>= 1:0.18), di-utils (>= 1.66), ${rdate:Depends}
XC-Package-Type: udeb
XB-Installer-Menu-Item: 2600
Description: set up clock
diff --git a/packages/clock-setup/debian/rules b/packages/clock-setup/debian/rules
index 82ce1c1..5e3bf4b 100755
--- a/packages/clock-setup/debian/rules
+++ b/packages/clock-setup/debian/rules
@@ -1,5 +1,13 @@
#!/usr/bin/make -f
+ARCH=$(shell dpkg-architecture -qDEB_HOST_ARCH)
+
+ifneq ($(ARCH), s390)
+RDATE_DEPENDS = configured-network, rdate-udeb
+else
+RDATE_DEPENDS =
+endif
+
build:
clean:
@@ -11,7 +19,9 @@ install: build
dh_testdir
dh_testroot
dh_clean -k
+ifneq ($(ARCH), s390)
dh_install finish-install.d usr/lib
+endif
binary-arch: build install
dh_testdir
@@ -21,7 +31,7 @@ binary-arch: build install
dh_compress
dh_fixperms
dh_installdeb
- dh_gencontrol
+ dh_gencontrol -- -Vrdate:Depends="$(RDATE_DEPENDS)"
dh_md5sums
dh_builddeb
Bug#539512: prevent running kernel warning during d-i
Package: debian-installer Severity: wishlist After d-i installs the kernel, it connects to security.d.o and possibly upgrades the kernel. This elicits a warning that the currently running kernel is the same as the new one. Maybe this warning could/should be prevented, either by preseeding it (if possible), or by adding security.d.o early enough so that the non-security kernel is not even considered? Thanks, -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31-rc3-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- .''`. martin f. krafft Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Processed: Re: Bug#538782: likely caused by change to PAT w/ 2.6.30
Processing commands for cont...@bugs.debian.org: > reassign 538782 linux-2.6 Bug #538782 [installation-reports] Hang in amd64 Install Bug reassigned from package 'installation-reports' to 'linux-2.6'. Bug #538782 [linux-2.6] Hang in amd64 Install Ignoring request to alter found versions of bug #538782 to the same values previously set Bug #538782 [linux-2.6] Hang in amd64 Install Ignoring request to alter fixed versions of bug #538782 to the same values previously set > forcemerge 538159 538782 Bug#538159: CONFIG_X86_PAT=y breaks bogl-bterm, d-i Bug#538782: Hang in amd64 Install Bug#538898: Squeeze install hangs at "Setting console to Unicode" Forcibly Merged 538159 538782 538898. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#411552: Call Derek For Confirmation +4470319 41862
You are among the winners of the UKNL GROUP.Confirm this receipt by contacting the due process unit officer Mr Derek Max:Fill the details: FullName,Address,Tel,Occupation,etc,derekdom...@9.cn (1)Courier, (2)Bank -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Processed: Re: Bug#539512: prevent running kernel warning during d-i
Processing commands for cont...@bugs.debian.org: > reassign 539512 pkgsel Bug #539512 [debian-installer] prevent running kernel warning during d-i Bug reassigned from package 'debian-installer' to 'pkgsel'. Bug #539512 [pkgsel] prevent running kernel warning during d-i Ignoring request to alter found versions of bug #539512 to the same values previously set Bug #539512 [pkgsel] prevent running kernel warning during d-i Ignoring request to alter fixed versions of bug #539512 to the same values previously set > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#539512: prevent running kernel warning during d-i
reassign 539512 pkgsel thanks On Saturday 01 August 2009, martin f krafft wrote: > After d-i installs the kernel, it connects to security.d.o and > possibly upgrades the kernel. This elicits a warning that the > currently running kernel is the same as the new one. Maybe this > warning could/should be prevented, > either by preseeding it (if possible), That would mean the dialog will *never* get displayed again. > or by adding security.d.o early enough so that the non-security kernel > is not even considered? When the original kernel gets installed apt is not yet fully configured. Changing that would be very hard and is probably not even desirable. The only realistic option is probably to run the upgrade phase with the noninteractive frontend. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#539522: partman randomly crashes partitioning disks in graphical install
Package: installation-reports Boot method: netinst ISO image Image version: http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/debian-testing-amd64-netinst.iso Date: Aug. 1, 2009 Machine: Core i7 920, ASUS WS P6T7 Supercomputer Processor: Core i7 920 Memory: 6 GB Partitions: N/A Output of lspci -knn (or lspci -nn): N/A Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [E] Install base system:[ ] Clock/timezone setup: [ ] User/password setup:[ ] Install tasks: [ ] Install boot loader:[ ] Overall install:[ ] Comments/Problems: Creating partitions with partman in the graphical install causes random crashes with Gtk errors about assertion failures. partman restarts with a set of unpartitioned disks, making it impossible to ever finish partitioning. I filed another bug for that one. Text install seems to create partitions fine, but RAID fs creation hangs. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#539521: mke2fs hangs formatting RAID6
Package: installation-reports
Boot method: netinst ISO image
Image version:
http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/debian-testing-amd64-netinst.iso
Date: Aug. 1, 2009
Machine: Core i7 920, ASUS WS P6T7 Supercomputer
Processor: Core i7 920
Memory: 6 GB
Partitions: N/A
Output of lspci -knn (or lspci -nn): N/A
Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
Initial boot: [O]
Detect network card:[O]
Configure network: [O]
Detect CD: [O]
Load installer modules: [O]
Detect hard drives: [O]
Partition hard drives: [E]
Install base system:[ ]
Clock/timezone setup: [ ]
User/password setup:[ ]
Install tasks: [ ]
Install boot loader:[ ]
Overall install:[ ]
Comments/Problems:
I created a RAID1 to hold the /boot partition and formatted as ext3 just
fine. When trying to format a RAID6 LVM group for /, mke2fs (creating
an ext3 fs) sits there and does nothing. This has been happening for
a week at least.
RAID1: 5 partitions, 0 spares
RAID6: 5 partitions, 0 spares, one LVM logical group for the root fs
Booted with "nopat" to get around a console hang problem but the issue
also happens in the graphical install ("nopat" not needed).
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#538086: installation-reports: Installation works, but neither is user created nor a root password set
Hi, On Tue, Jul 28, 2009 at 12:04 PM, Otavio Salvador wrote: > Hello, > > On Wed, Jul 22, 2009 at 8:09 PM, Dinyar Rabady wrote: >> The first problem I encountered while trying to install a system with an >> encrypted LVM was that the USB stick was taken to be /dev/sda while the >> harddisk was /dev/sdb. This changed at first boot when the usb stick was >> unplugged. >> >> This first problem could be fixed either by booting into a rescue system >> and first changing grub's menu.lst to point to (hd0,0) instead of (hd1,0) >> and then unpack the initrd.img file and change /conf/conf.d/cryptroot to >> point to /dev/sda instead of /dev/sdb, or alternatively I pulled the USB >> stick out right before detecting the harddisk. (priority=medium is helpfull >> for timing here.) This seemed to have no negativ effects on the installation. > > This is not going to happen in new Debian Installer release for > Squeeze since we're not using UUID to avoid those problems. Would be > nice if you could check a current snapshot if it indeed works for you > and tell us. > I have not tryed this yet due to time constraints, but I'll report back as soon as I get round to it. >> The second problem I encountered was that neither my user account was created >> during installation nor was the root password set. This left the system >> fairly >> unusable until I used a rescue system to mount my encrypted disk, added a >> user >> to /etc/passwd and /etc/shadow (without a password) and subsequently added >> this user to the sudoers group. In this way I could aquire root on my new >> system. > > This is confusing; maybe your media was corrupted in some way since I > don't remember of seeing this report and it is used in every > installation. Could you try to reproduce it and report back to us? > I actually tried twice, though with the same installation media. I don't have any plans to reinstall in the near future though (at least not until the multi-arch stuff screws up my system again.. ;) ) so sorry about that. > 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 > -- Please avoid sending me Word, Excel or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#539521: mke2fs hangs formatting RAID6
Oh, it finally did kick off and apparently formatted the partition. The progress meter went to 33% immediately and then just sat there. I saw this behavior last week and then it really did sit there for hours. So it appears whatever problem existed a week ago is gone but that the UI could use some work. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#514218: marked as done (d-i: [sparc] should list sun4v (niagara) in silo.conf)
Your message dated Sat, 1 Aug 2009 21:32:10 +0200 with message-id <200908012132.11036.elen...@planet.nl> and subject line Bug#514218: d-i: [sparc] should list sun4v (niagara) in silo.conf has caused the Debian Bug report #514218, regarding d-i: [sparc] should list sun4v (niagara) in silo.conf 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.) -- 514218: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=514218 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: debian-installer Version: 20090123 Severity: important The installation guide says that we support sun4v systems, but our silo.conf file for netboot and CDs only lists sun4u. Note that this should also be changed in debian-cd when it is added for D-I. --- End Message --- --- Begin Message --- Closing as it turns out that silo does not understand sun4v. Niagara probably just boots under sun4u, just as other 64-bit sparcs. --- End Message ---
Bug#433579: marked as done (partman-dmraid: Error in logic determining if dmraid is supported)
Your message dated Sat, 1 Aug 2009 21:36:43 +0200 with message-id <200908012136.43998.elen...@planet.nl> and subject line Bug#433579: partman-dmraid: Error in logic determining if dmraid is supported has caused the Debian Bug report #433579, regarding partman-dmraid: Error in logic determining if dmraid is supported 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.) -- 433579: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=433579 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: partman-dmraid Version: 1 Severity: important On some systems, dmraid -s -c will return "no block devices found" on stdout with an exit code of 0, and not "No RAID disks". This was seen on a system with cciss, so this is likely a condition that is hit before the "No RAID disks" condition (something like "no suitable controller detected"). Result of this issues is that incorrect paths are taken (as if dmraid devices were detected). It would be nice if dmraid would return a non-zero error code in those cases instead having to parse the output of the command... This also affects: - base-installer - hw-detect - partman-base - grub-installer One solution could be to run something like (assuming that no "%" would be used in error messages): dmraid -s -c r,t --sep "%" | grep "%" | cut -d% -f1 Command needs checking! Note that we should also test for the exit code as dmraid _can_ exit non-zero! Example with /sys not mounted (the errors go to stderr!): # dmraid -s ERROR: opening path /sys/block ERROR: failed to discover devices # echo $? 1 pgpysCxfH9CmD.pgp Description: PGP signature --- End Message --- --- Begin Message --- After the release of Lenny dmraid was fixed to return an error code and its use in D-I has been updated to test for that. See for example base-installer (1.99). Therefore closing. --- End Message ---
