Package: dhcp-client-udeb
Version: 2.0pl5-19.1
Severity: serious
Tags: d-i
Installations for 1386 using current daily builds (using 2.6.12) are
failing with a screen saying no default route could be set.
The cause for this is that in /etc/dhclient the 'ip route add' command is
failing. It
reopen 225693
retitle boot-floppies should never migrate to testing
thanks
Oops. boot-floppies is the source package and that still _is_ in unstable.
There is also a bug in the BTS website which led me astray here...
pgp38HKiKvP0O.pgp
Description: PGP signature
reassign 322723 linux-2.6
retitle 322723 D-I: 'id route add' fails w/ Network is unreachable
thanks
We have just tested this issue using an installer with the busybox version
from Sarge and the error shows up then as well.
We feel this makes the kernel the most likely source of the problem.
On Tuesday 16 August 2005 19:35, Andres Salomon wrote:
Regarding this problem with iproute:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=282492
Would it be possible to include a fix for this, or at least make
CONFIG_ATM_CLIP a module instead of a yes in the stock kernel?
I'm
On Friday 19 August 2005 21:01, Bastian Blank wrote:
- the problem is not there in the 686 image.
On request from waldi, I've compiled a -386 kernel (using gcc-4.0) with
one change in ./debian/arch/i386/config.386:
- CONFIG_CC_OPTIMIZE_FOR_SIZE=y
+ # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
The
On Sunday 21 August 2005 03:56, Horms wrote:
I've put the following in SVN, so this
should be resolved in the next release.
I noticed on IRC that you put a closes: #322723 in the changelog.
I'm wondering if that is correct as I would say there still is a bad bug
in gcc-4.0 causing the kernel
Package: partman-auto-lvm
Version: 8
Severity: serious
While testing partman-auto-lvm on sparc, which has default /boot partition
in its schemes, partman-auto-lvm created two /boot partitions.
Reason is that the following line is broken:
if ! echo $normalscheme | grep -eq
Package: openjade
Version: 1.4devel1-15
Severity: grave
Justification: renders package unusable
I normally build the Debian Installation Guide in a Sarge environment,
except when I upload the package.
In current unstable the build of the PDF version of the manual fails
when openjade is being
After downgrading the following three packages, the build completes
without errors again:
ii libosp4c2 1.5.1.0-4 Runtime library for OpenJade group's SP suite
ii libostyle1c2 1.4devel1-14 Runtime libraries for OpenJade
ii openjade 1.4devel1-14 Implementation of the DSSSL
On Wednesday 01 February 2006 07:14, Ben Collins wrote:
I'm bumping the severity up a bit. It would be very nice to upload a
new afbinit, fixing this bug and #250619.
Would be even nice if I could do the upload. Someone will have to NMU
it.
Will do.
--
To UNSUBSCRIBE, email to [EMAIL
severity 350797 minor
thanks
Thanks for your quick reaction.
On Wednesday 01 February 2006 04:26, you wrote:
The problem is that in order to resolve a long standing performance
problem, I turned off DTDDECL handling in the the libosp5 package on
which openjade depends. What this means is
I've also been having crashes using kbabel in Sarge (see #289646). I've
had crashes with several po files now.
The behavior is somewhat eratic: when I first had the crash, I could
always reproduce it, now I find that sometimes the crash does not happen.
Very likely my crashes are related to
severity 292366 normal
thanks
On Wednesday 26 January 2005 17:20, Sergio Rua wrote:
On the first reboot, it enters on the menu where you will set up the
root password and some other configs. But I was unable to do anything
here as the server entered on a loop with the error Incorrect charset
Package: lvm2
Version: 2.0.0.24-1
Severity: critical
Justification: Can break whole system
During a reorganization of my LVs, I did a lvremove that in itself
produced no errors. However, the next lvremove failed with messages that
devices (?) had been 'left open' and metadata for the VG that
and as I can not access
my sys-root LV, I can not get to the backups.
Or is there some kind of trick to that?
I've also attached the output for 'lvdisplay lvdisplay.txt 21'.
Note the 'Device ??? has been left open' lines in that output.
Cheers,
Frans Pop
Volume group sys inconsistent
Device
it to you what to do with this bug report.
IMO both errors I reported are still there, but as it is after all
relatively easy to recover from the resulting inconsistency (once you
know how), you may want to downgrade to important.
Thanks again,
Frans Pop
--
To UNSUBSCRIBE, email to [EMAIL
Package: tetex-bin
Version: 3.0-9
Followup-For: Bug #334613
I've seen the same problem, with the following extra note.
Setting up tetex-bin was retried automatically, and that time
succeeded. After that tetex-extra could be set up and it appears
that the total installation was successful.
On Monday 24 October 2005 17:46, Faidon Liambotis wrote:
Moreover, I highly doubt that memory leak bugs are justified as
severity critical.
For regular applications I would agree. For an application that runs as a
daemon and is likely to run permanently on a server, I think an RC
severity is
severity 335950 normal
reassign 335950 installation-reports
thanks
On Thursday 27 October 2005 00:32, Kenneth Gessner wrote:
Severity: critical
Justification: breaks the whole system
Again the severity is inflated. How can it break the system if there is no
system installed?
cannot install
Package: libgtk+2.0-directfb-dev
Version: 2.0.9.2-10
Followup-For: Bug #337248
As this package supplies .pc files, it should depend on pkg-config
(libgtk2.0-dev does the same).
No real hurry to add this as this is currently taken care of for
cdebconf-gtk by its dependency on libgtk2.0-dev.
--
tag 337382 pending
thanks
On Friday 04 November 2005 09:48, Daniel Schepler wrote:
Tracing this by adding a set -x to the command line, it appears this
is being caused by s390 expanding to an ARCH_FULL of S/390.
Correct. This is already fixed in the rules file by changing the
separators for
severity 337382 important
thanks
Downgrading this issue. As the installation-guide is arch all, it does not
need to be build on the buildd's and is therefore less critical. It
should at least not block the current version from moving to testing.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
Package: xsupplicant
Version: 1.0.1-4
Severity: grave
Tags: security
Justification: user security hole
When xsupplicant is started on boot, my wireless card is not up.
In that situation, xsupplicant happily dumps configuration settings,
including username/password settings, to
Hi Jurij,
Could you take a look at this bug (as you submitted the original patch and
this could be kernel headers related...).
Cheers,
FJP
On Wednesday 20 July 2005 09:26, Blars Blarson wrote:
discover1 failed to build on a sparc buildd, duplicated on my sparc
pbuilder:
[11:30:24] pere any
on an extremely course basis.
Cheers,
Frans Pop
Here are the headers for the original message:
Return-path: [EMAIL PROTECTED]
Received: from [195.240.184.66] (helo=localhost)
by smtp-out1.tiscali.nl with esmtp (Tiscali http://www.tiscali.nl)
id 1Dua9c-0002lD-DD
for [EMAIL
On Tuesday 26 July 2005 19:27, Stefan Esterer wrote:
After i choose the Sarge install in grub the kernel stops after some
time with :
modprobe: FATAL: Error inserting pciehp
(/lib/modules/2.6.8-2-686/kernel/drivers/pci/hotplug/shpchp.ko):
Operation not permitted
shpchp: can't be loaded
severity 320784 normal
thanks
Daily images can be broken sometimes (like the images dated 31-07-2005)...
On Monday 01 August 2005 14:29, Torok Edwin wrote:
Debian-installer-version:
http://cdimage.debian.org/pub/cdimage-testing/etch_d-i/i386/20050709/de
bian-testing-i386-netinst.iso uname
Package: base-installer
Version: 1.24
Severity: serious
In commit r29833 the value of link_in_boot was changed from false to true
for i386 and amd64. This change make lilo-installer fail as lilo.conf is
configured to expect symlinks for the kernel and initrd in / (if boot is
not a separate
On Sunday 25 September 2005 09:40, Petter Reinholdtsen wrote:
Why the serious severity? lilo is not the default boot loader, so
this only affect expert installs.
Because LILO is the default installer in some cases (/ on XFS IIRC) and is
also ofter prefered by users for RAID installs.
Also, it
On Monday 26 September 2005 17:11, Lennart Sorensen wrote:
My raid install of sarge used grub. Why ever would you want it to use
lilo?
No idea. Just noticed in installation reports that quite a few users
prefer lilo over grub.
Or does grub behave that differently on amd64 that it can't
On Tuesday 11 October 2005 13:17, Gaudenz Steinlin wrote:
Please try the attached patch and see if the generated binary works.
Compiles and runs fine on my Ultra 10.
Output of old and new versions attached.
Cheers,
FJP
Reading PCI hardware database...
Reading PCI hardware database...
Reading
Package: ctrlproxy
Version: 2.6.2-1
Severity: critical
Justification: breaks unrelated software
After running ctrlproxy for a fairly long time as daemon:
Mem: 30180 29248932 0 1336 5596
-/+ buffers/cache: 22316 7864
Swap:60440
Package: cgiemail
Version: 1.6-24
Severity: serious
Justification: Policy 10.7.3
cgiemail does not delete its configuration file /etc/cgiemail.conf when
the package is purged.
Should this file maybe be made into a conffile?
-- System Information:
Debian Release: 3.1
APT prefers testing
APT
I'm seeing the same problem on my Sparc Ultra10. Switching to dhcp3-client
solved the issue.
Removal of the package might not be such a good idea as Debian-Installer
uses the dhcp-client-udeb. I've not yet checked if the udeb has the same
problems on sparc.
pgpj9M3nFzGdl.pgp
Description: PGP
On Saturday 19 November 2005 05:05, Steve Langasek wrote:
What's holding up the switch to dhcp3-client-udeb? Andrew Pollock did
a lot of work earlier this year to get it ready for d-i use. Is there
still something missing, or is it just a question of trying it out?
The only issue AFAIK is
On Saturday 19 November 2005 10:41, Steve Langasek wrote:
Do we actually have reason to believe that this is a memory leak, i.e.,
leaving the daemon running will continue to eat more memory? If the
program simply needs 70-some MB to run, that's unfortunate, but not RC;
if, OTOH, its memory
On Saturday 19 November 2005 15:15, Steve Langasek wrote:
Granted, though it seems that at least two of the architectures you
quoted don't support floppy installs in etch? :)
Sparc does but they are not part of official release as building them
requires root.
pgpRx89JdeMb9.pgp
Description:
Package: netcfg
Version: 1.17
Severity: serious
Justification: Makes package unsuitable for release
Now that udev is enabled in d-i for kernel 2.6.14, regular interfaces get
recognized as being hotpluggable.
However, as udev no longer uses hotplug, the current configuration set up
by netcfg no
regarding this [2], but I'm not sure that also applies for Debian.
Cheers,
Frans Pop
[1] http://bugs.debian.org/340935
[2] https://wiki.ubuntu.com/NetworkMagic
pgp1MQ11QL9G9.pgp
Description: PGP signature
the output of 'dmesg' and contents (using nano) of /var/log/syslog)?
Thanks.
Frans Pop
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Package: linux-2.6
Version: 2.6.14-4
Severity: serious
The following error happens on Debian Installer boot in vmware (386 kernel).
This problem was not present in -3.
The system does come up after the error, but it looks so basic (memory
management AFAICT) that I've set RC severity anyway.
Feel
found 339711 2.0pl5-19.3
thanks
Sam, thanks for working on this.
I'm afraid the NMU has not fixed the problem on sparc though.
[EMAIL PROTECTED]:~$ dpkg -l dhcp-client
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/
On Saturday 03 December 2005 15:49, Frans Pop wrote:
Sam, thanks for working on this.
I'm afraid the NMU has not fixed the problem on sparc though.
I've found the cause. One patch had an extention .diff instead of
.patch and because of that was not applied.
I've uploaded (NMU) a new version
close 341878 1.22
thanks
Bug arrived after fix had already been uploaded, therefore closing this
way.
On Saturday 03 December 2005 21:03, Joey Hess wrote:
Daily build install is failing like this on alpha, and I think on sparc
as well:
No, it does not affect Sparc. Problem was that in some
Package: gtk+2.0-directfb
Version: 2.0.9.2-12
Severity: serious
Justification: FTBFS
The package fails to build on these two architectures with the same error:
gdkpango.c: In function 'gdk_draw_layout_line_with_colors':
gdkpango.c:307: warning: enumeration value 'PANGO_UNDERLINE_ERROR' not
Package: parted
Version: 1.6.25.1-1
Severity: serious
Justification: FTBFS
The package fails to build on these two architectures with the same error:
../../../libparted/fs_hfs/advfs.c: In function 'hfs_read_bad_blocks':
../../../libparted/fs_hfs/advfs.c:241: internal compiler error: Floating
Thiemo Seufer replied to #342028 (similar error for gtk+2.0-directfb):
From the symptom I expect this to be fixed in gcc-4.0 4.0.2-4.
Possibly this is valid for parted too.
I understand that rebuilds are already being scheduled.
[23:12:11] fjp ths: So, just ask buildd admins to schedule a
On Tuesday 06 December 2005 05:23, Jurij Smakov wrote:
It's not kernel's fault. I have just booted the 2.6.14 off today's
sid_d-i daily netinst, and it has the bug. The bug appears because the
af_unix_init function is invoked twice, and it normally should not
happen. This function is the init
reassign 341392 ftp.debian.org
retitle 341392 Please remove obsoleted socket-modules-2.6.14-2-386-di
thanks
On Tuesday 06 December 2005 06:55, Frans Pop wrote:
This looks to be a serious bug in kernel-wedge as it seems a module
from a previous kernel version is included when that module
, 2005 at 01:17:42PM +0100, Frans Pop wrote:
There are several packages relevant for the installer that have what
looks like minor problems keeping them from being built on some
arches.
- cdebconf (0.91)
Failed on alpha and ia64 with strange build dep error; a simple
retry may fix
Package: klibc
Version: 1.1.1-4
Severity: serious
Justification: Fails to build from source
I was trying to recover from yaird failing to create an initrd for the
new kernel and, to install initramfs-tools, had to try to build klibc
locally as it's not available from the mirrors for Sparc.
This
The bug seems to be caused by the new make (3.80+3.81.b3-1).
The README.Debian lists several backwards incompatibility warnings for
this version. Possibly the build failure is caused by one of those.
The build succeeded after downgrading to make 3.80-12.
I'm not sure where this problem needs to
Urgency: low
Maintainer: Frans Pop [EMAIL PROTECTED]
Changed-By: Gopal Narayanan [EMAIL PROTECTED]
Description:
pgplot5- large subroutine library for plotting scientific data
Closes: 146077 248551
Changes:
pgplot5 (5.2.2-6) unstable; urgency=low
.
* Removed PIC compilation for static library
On Sunday 24 April 2005 18:39, Frans Pop wrote:
I have built the package for s390, but can not upload myself (still
waiting for DAM approval).
Joey Hess has just done the upload, so it's now complete for all archs.
Cheers,
FJP
pgpTbZXTxLxQd.pgp
Description: PGP signature
On Monday 29 August 2005 11:06, Sven Luther wrote:
* reboot
* upgrade udev
This is definitively not a user-friendly procedure.
In effect this means that any user having udev installed will have to put
udev on hold. Because of versioned dependencies on udev, this will
probably make a lot
On Monday 29 August 2005 12:35, Marco d'Itri wrote:
On Aug 29, Frans Pop [EMAIL PROTECTED] wrote:
In effect this means that any user having udev installed will have to
put udev on hold.
No, if the kernel has not been upgraded yet then preinst will fail.
Hmm. Won't that fail the whole dist
(pruning CC list; AFAIK all will still get the message this way)
On Tuesday 30 August 2005 04:56, Steve Langasek wrote:
So we're going to have another release with a very elaborate upgrade
procedure in the release notes (which a lot of users, especially
desktop users, don't read anyway)?
On Wednesday 07 September 2005 23:21, you wrote:
It would be extremely helpful if you could find a way to reproduce
this that does not require root... any ideas?
Well, I think the problem can also be reproduced outside a
debian-installer environment (getting linux-image-2.6.12-1-386 (2.6.12-2)
Package: partconf
Version: 1.10
Severity: grave
Tags: d-i
During installation for s/390, partconf no longer recognizes partitions on
a dasd. This is probably due to recompilation against libparted 1.6.24.
pgpmSfYq3oxbn.pgp
Description: PGP signature
If one could send me the two ntfs images, before and after running
chkdsk, then I could add the needed support, suppose the problem is
indeed due NTFS changes.
I've tried this in vmware. Apparently you should be able to use the Vista
installer's Recovery Environment [1] to run chkdsk.
On Saturday 11 November 2006 04:21, Steve Langasek wrote:
I'm having a hard time distilling the information in these bug reports
into a summary of what each bug is actually about or what the current
status is.
I don't find that at all surprising as it cost me a lot of hours to get
get the
On Thursday 23 November 2006 00:27, Szaka wrote:
It's possible that it checks the boot sector for changes, e.g. against
viruses, rootkits, etc.
I still don't see why it should affect booting the _installer_. Is
reinstallation not the final (and in the case of Windows often the only)
option to
On Saturday 11 November 2006 20:43, Szakacsits Szabolcs wrote:
If one could send me the two ntfs images, before and after running
chkdsk, then I could add the needed support, suppose the problem is
indeed due NTFS changes.
Think I've got it.
I've installed Vista Beta2 on my AMD64 box, resized
On Saturday 25 November 2006 01:17, Szakacsits Szabolcs wrote:
On Sat, 25 Nov 2006, Frans Pop wrote:
I hope the info available now will be sufficient to track down the
problem. If not, I could repeat the procedure and also generate an
image after running the Windows 2000 chkdsk.
Please
marvell gigabit ethernet port is a platform device for which the
driver should be loaded.
Can anyone shed some light on this and suggest a solution?
See http://bugs.debian.org/398962 for details.
Thanks in advance,
Frans Pop
P.S. Please keep the debian BTS CCed on replies.
pgpe9DH2YAvyF.pgp
On Sunday 26 November 2006 02:13, you wrote:
Could you please also test that whether Vista boots if you remove
/pagefile.sys after ntfsresize? You can use ntfs-3g for this, it's in
Debian unstable. Usage: http://www.ntfs-3g.org/index.html#usage
Or use a LiveCD which has both. The above page
On Monday 27 November 2006 15:17, you wrote:
Nothing! In particular I found that running ntfsresize followed by
ntfsfix still causes the same vista boot problem. Then running ntfsfix
again and booting vista again causes chkdsk to run and vista to work.
So it is not what ntfsfix does but the
On Monday 27 November 2006 16:27, Anton Altaparmakov wrote:
That is wrong. It always does the same thing no matter what the
partition is marked as... Trust me, I wrote it so I should know! (-:
Oh, I trust you. However, that still does not explain what I see
happening.
Directly after
On Monday 27 November 2006 21:44, you wrote:
ntfsresize
ntfsfix ***1
ntfsfix ***2
boot vista- will fail
ntfsfix ***3
boot vista- will work
Note ***1 is what you did before, it will mark the volume dirty thus
when you do ***2 it will fail
On Monday 27 November 2006 23:45, Anton Altaparmakov wrote:
//vol = ntfs_mount(opt.volume, 0);
vol = NULL;
I'm almost afraid to have to tell you this... ;-)
After recompiling ntfsfix with this change, running it once immediately
after the ntfsresize and rebooting Vista, I _do_
On Tuesday 28 November 2006 13:08, Szakacsits Szabolcs wrote:
There are two NTFS during resizing. The original and the resized. When
the resizing is over then the latter is consistent and the old one is
irrelevant. ntfsresize doesn't work like the other utilities: mount,
modify, umount. It
On Saturday 02 December 2006 14:36, Szakacsits Szabolcs wrote:
On Sat, 2 Dec 2006, Szakacsits Szabolcs wrote:
Apparently Vista refuses to boot if an NTFS volume was mounted on
NT4 earlier. This is also what ntfsresize lied to trick Windows
to be compatible with itself.
I put a statically
Package: gnome-games-data
Version: 1:2.8.3-2
Severity: serious
During a test upgrade from Sarge to Etch I noticed the following packaging
issue. Not sure if it's a conflict with the Sarge or Etch version of
gnome-icon-theme.
Cheers,
FJP
Preparing to replace gnome-games-data 1:2.8.3-2 (using
On Sunday 03 December 2006 22:06, Andree Leidenfrost wrote:
Okidoki, what happens now? I'd be keen to see this in the package and
then in the installer ASAP.
Note that this was not the only issue affecting resizing Vista partitions
in the installer. There is also #380226 in parted. And I'm
Package: debian-installer
Severity: serious
Since about a week (switch to 2.6.18?) the installgui option on netinst
CDs fails to boot correctly. It fails to enable the framebuffer and you
end up in a messed up newt interface.
It also fails to correctly respond to a BOOT_DEBUG=3 boot parameter
On Tuesday 05 December 2006 00:06, David MartÃnez Moreno wrote:
Frans, I think that, not having a better solution, I am going to apply
the two-line patch to linux-ntfs and release a new version, is it fine
for you?
Yes, that would be fine with me.
However, I don't fully understand the
On Monday 04 December 2006 20:57, Frans Pop wrote:
With some help from Colin, I managed to find as most probably cause
that /dev/console and /dev/null have incorrect file attributes in the
gtk initrd:
I cannot reproduce this error on my own machine, so I suspect it is
something local
tags 401603 + pending
# lowering severity as the fix is already implemented for daily builds
severity 401603 important
thanks
On Wednesday 06 December 2006 10:05, Joey Hess wrote:
If I run the build by hand (in fakeroot), it's crw-r--r-- all the way
through, and is ok in the initrd. The next
Package: udev
Version: 0.103-1
Severity: serious
Seeing the following messages on my laptop very early during boot:
INIT: version 2.86 booting
Starting the hotplug events dispatcher: udevd.
Synthesyzing the initial hotplu events...done.
Waiting for /dev to be fully populated...
Package: localization-config
Severity: serious
Unfortunately the package has never really been updated for Etch and is
therefore currently unused by Debian installer. It is certain that some
of its functionality is now correctly handled by the packages it helped
configure for Sarge.
IMO
severity 358532 important
reassign 358532 hw-detect
thanks
On Thursday 23 March 2006 03:35, Blars Blarson wrote:
Severity: grave
Justification: renders package unusable
Please don't inflate severity: a reboot failure on one specific type of
system does not make the whole installer unusable.
severity 358510 important
thanks
On Thursday 23 March 2006 00:57, Glenn English wrote:
When it comes time, during the boot process, to mount the root
partition, sda has become a SATA drive. The boot kernel says sda3
doesn't exist, and drops to a shell (or when the SCSI has only one
partition,
Package: cdebconf
Version: 0.97
Severity: serious
When debconf-copydb is run from pkgsel's postinst script, it deletes the
existing /var/cache/debconf/templates.dat in /target; after it has run
only copied templates are present.
This results in the problem that has been reported that tasksel
severity 362800 important
thanks
On Saturday 15 April 2006 19:22, Nizamov Shawkat wrote:
Today I downloaded the fresh Etch iso image (CD-1, ~650Mb).
When I tried to install, installer correctly recognized media as Etch
'testing' medium Then installer required to define the online
repository
severity 363079 normal
merge 363079 362846
thanks
On Monday 17 April 2006 15:28, Harald Dunkel wrote:
-if [ ! -L -e -d /usr/X11R6/bin ]; then
+if ! [ -L /usr/X11R6/bin ] [ -d /usr/X11R6/bin ]; then
This bug was already filed as #362846 and was already fixed, though the
fixed version has
Package: klibc
Severity: serious
Version: 1.3.3-3
After an upgrade in unstable on sparc a reboot resulted in:
run-init: statfs /: invalid parameter
I'm inclined to blame klibc as that was also the cause the previous time
(#347902), but everything involved was upgraded. From /var/log/aptitude:
Package: console-tools
Version: 0.2.3dbs-61
Severity: serious
Upgrade of console-tools (and therefore console-common) fails because
console-screen.sh throws an error when started:
$ ./console-screen.sh start || echo FAIL $?
+ '[' -r /etc/console-tools/config ']'
+ . /etc/console-tools/config
++
On Thursday 04 May 2006 13:17, you wrote:
Frans Pop say that this bug is done in images after 15/04/2006, but I
burn the 3 *DVDs* of Debian Etch (17/04/2006) and I found the same
problem: The installer work ONLY with internet conection (online
repository is necessary!) I try use workarround
Package: busybox-udeb
Version: 1:1.1.2-1
Severity: critical
# echo Create | tr '[A-Z]' '[a-z]'
Segmentation fault
pgpuZaaO4XE6d.pgp
Description: PGP signature
,
Frans Pop
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
On Monday 06 February 2006 22:25, Martin Michlmayr wrote:
architecture.mk convert the architecture name in case the name in
Debian and the name in the kernel tree is different, which is the
case for powerpc (ppc), and hppa (parisc).
Manoj, maybe you can take a look at the build failures on
tags 347479 + patch
thanks
The attached patch adds some basic checks so we do not just go ahead in
situations the code is not ready to handle. Basically, partman-auto-lvm
will now fail if the device selected for autopartioning already contains
an LVM physical device.
Also, the check if the
cannot really deal with currently.
- -- Frans Pop [EMAIL PROTECTED] Sun, 29 Jan 2006 19:27:24 +0100
+ -- Frans Pop [EMAIL PROTECTED] Tue, 7 Feb 2006 16:51:38 +0100
partman-auto-lvm (8) unstable; urgency=low
Index: lvm_tools.sh
to inittab.s390-linux-gnu.
This should solve the problem.
A prompt upload with high urgency would be very much appreciated as we're
currently preparing the Etch Beta2 release of Debian Installer and this
is the only issue keeping S/390 from being supported again in this
release.
Cheers,
Frans
On Wednesday 08 February 2006 22:07, Christian Perrier wrote:
Well, even though I'm not fond of new strings so late in the release
process, I guess we can't avoid it (I wouldn't say so if this was a
real final release with a hard string freeze).
I agree, but as:
- this is a new component
- it
Package: udev
Version: 0.084-4
Severity: serious
After upgrade of udev from 0.084-3 to 0.084-4 and regenerating
initramfs-tools initrd, ide-generic is no longer loaded on boot.
I get dropped into a shell. Doing:
# modprobe ide-generic
# exit
is enough to continue and complete the boot.
/initd.d/hdparm failed
IMO it would be good to suppress such messages as, in my experience, they
will only lead to unnecessary installation and bug reports.
maks suggested to re-add the silence_exec_error patch for Beta2 and
maybe come back to this issue after that?
Thanks,
Frans Pop
On Wednesday 15 February 2006 12:50, Marco d'Itri wrote:
Sorry, the right command was udevtest /block/hda.
$ sudo udevtest /block/hda
main: looking at device '/block/hda' from subsystem 'block'
run_program: 'ata_id --export /dev/.tmp-3-0'
run_program: '/lib/udev/ata_id' (stdout) 'ID_TYPE=disk'
Marco,
Attached is the info you requested, at least I hope it is.
You asked for 'udevtest -a -p /sys/block/hdetc', but udevtest only gave me
systax errors or 'could not open file' errors. udevinfo did give a result
with those parameters, so I decided you probably mistyped.
If you actually want
On Wednesday 15 February 2006 23:48, Chris Searle wrote:
I have no idea how to go about debugging this and of course - since it
can't find the disks - no logs to look in :(
Please try the following at the shell prompt:
# modprobe ide-generic
# echo /dev/hda*
Are your partitions listed now? If
1 - 100 of 554 matches
Mail list logo