On Mon, Apr 17, 2006 at 12:29:04AM +0200, Bastian Blank <[EMAIL PROTECTED]>
wrote:
> Hi folks
>
> For sarge updates of the linux kernels, grub needs to be updated before
> linux-image*. Can this be forced by an conflict with older versions? A
> dependency is not appropriate.
Why does grub have t
On Mon, Apr 17, 2006 at 12:29:04AM +0200, Bastian Blank wrote:
> For sarge updates of the linux kernels, grub needs to be updated before
> linux-image*. Can this be forced by an conflict with older versions? A
> dependency is not appropriate.
Can you give more detail on why grub needs to be updat
Jurij Smakov wrote:
> Hi,
>
> Cord Beerman wrote:
>
> >what about that?
> >
> >debian-devel-kernel@
> >
> >Cord
>
> I would personally prefer debian-kernel-devel, but in the end of the day
> it is not that important. If you have any reasons to prefer
> debian-devel-kernel over debian-kernel-de
Hi,
Cord Beerman wrote:
what about that?
debian-devel-kernel@
Cord
I would personally prefer debian-kernel-devel, but in the end of the day
it is not that important. If you have any reasons to prefer
debian-devel-kernel over debian-kernel-devel, go ahead with it. We are
drowning in bug t
Hi folks
For sarge updates of the linux kernels, grub needs to be updated before
linux-image*. Can this be forced by an conflict with older versions? A
dependency is not appropriate.
Bastian
--
In the strict scientific sense we all feed on death -- even vegetarians.
-- Spock, "W
tags #362442 - confirmed pending
thanks
On Sat, Apr 15, 2006 at 12:52:23PM +0200, Marc Haber wrote:
> tags #362442 confirmed pending
> thanks
Errm. That was a typo. I apologize.
Greetings
Marc
--
-
Marc Haber |
Processing commands for [EMAIL PROTECTED]:
> tags #362442 - confirmed pending
Bug#362442: initramfs-tools: A few simple options for greater flexibility
Tags were: confirmed
Tags removed: confirmed, pending
> thanks
Stopping processing here.
Please contact me if you need assistance.
Debian bug t
(new) linux-2.6-exp_2.6.16-1.dsc optional devel
(new) linux-2.6-exp_2.6.16-1.tar.gz optional devel
(new) linux-headers-2.6-vserver-s390x_2.6.16-1_s390.deb optional devel
Header files for Linux kernel 2.6 on IBM zSeries machines
This package depends on the architecture-specific header files for the
linux-2.6-exp_2.6.16-1_s390.changes uploaded successfully to localhost
along with the files:
linux-2.6-exp_2.6.16-1.dsc
linux-2.6-exp_2.6.16-1.tar.gz
linux-headers-2.6.16-exp-vserver_2.6.16-1_s390.deb
linux-image-2.6.16-exp-vserver-s390x_2.6.16-1_s390.deb
linux-headers-2.6.16-exp-vserver-
On Sun, Apr 16, 2006 at 07:12:13PM +0200, David Härdeman wrote:
> On Sun, Apr 16, 2006 at 06:36:08PM +0200, maximilian attems wrote:
> >John Goerzen wrote:
> >> The fstype reports unknown for ISO9660 filesystems.
> >
> >...fix in fstype of klibc-utils would be better.
>
> I might have time to loo
Your message dated Sun, 16 Apr 2006 14:35:23 -0300
with message-id <[EMAIL PROTECTED]>
and subject line Bug#290226: acpi is dumb on 2.6.9-1-386 and 2.6.10-1-386 on
hp/compaq nx9010
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt w
On Sun, Apr 16, 2006 at 06:36:08PM +0200, maximilian attems wrote:
John Goerzen wrote:
The fstype reports unknown for ISO9660 filesystems.
...fix in fstype of klibc-utils would be better.
I might have time to look into adding ISO9660 detection to fstype
sometime next week as a short term
On Sun, 16 Apr 2006, David Härdeman wrote:
> John Goerzen wrote:
> >There are a few things I would find helpful:
> >
> >1) If scripts in local_top could change the notion of ROOT.
> >
> > I have a script that probes the system to find where the DFS CD is,
> > and then mounts it, since there i
Processing commands for [EMAIL PROTECTED]:
> # Automatically generated email from bts, devscripts version 2.9.16
> tags 362442 - pending
Bug#362442: initramfs-tools: A few simple options for greater flexibility
Tags were: pending confirmed
Tags removed: pending
>
End of message, stopping processi
On Thu, 06 Apr 2006, Nicola Manini wrote:
> > please try out the unstable initramfs-tools version 0.59b
>
> I did: complete disaster.
>
> After the udev checks, the scrips come up with a message "Waiting for the
> root filesystem" or something of that kind. Except that, afterwards, the
> /dev/h
On Sun, 19 Mar 2006, Moshe Yudkowsky wrote:
> Ok, I've tried that, see below.
>
> However, if anyone ever has a legitimate reason to use "install," they
> will suffer a boot failure and they won't be able to figure out why
> there has been a failure.
yes will need to consider that.
> I set
On Sun, 2006-04-16 at 11:33 +0200, maximilian attems wrote:
> ok, adding discs works much better with grub.
I know. I've used grub for non-LVM installations. But I also love the
reorganizing convenience of LVM. Does grub now work with LVM roots
then? This was the reason I used lilo (well, actually
Processing commands for [EMAIL PROTECTED]:
> reassign 362505 kernel-image-2.6.8-3-686
Bug#362505: via-rhine: probe of :00:0f.0 failed with error -993193440
Bug reassigned from package `general' to `kernel-image-2.6.8-3-686'.
> thanks
Stopping processing here.
Please contact me if you need as
Processing commands for [EMAIL PROTECTED]:
> reassign 361741 klibc-utils
Bug#361741: Fail to mount root filesystem
Bug reassigned from package `initramfs-tools' to `klibc-utils'.
> tags 361741 -moreinfo
Bug#361741: Fail to mount root filesystem
Tags were: moreinfo
Tags removed: moreinfo
> tags 3
John Goerzen wrote:
There are a few things I would find helpful:
1) If scripts in local_top could change the notion of ROOT.
I have a script that probes the system to find where the DFS CD is,
and then mounts it, since there is no ability to specify a custom
ROOT. Fortunately this w
Processing commands for [EMAIL PROTECTED]:
> # Automatically generated email from bts, devscripts version 2.9.16
> tags 361270 pending
Bug#361270: update-initrams doesn't call lilo, when grub is around
Tags were: moreinfo
Tags added: pending
>
End of message, stopping processing here.
Please con
Before reading your message i've tryed to follow the script launched
inside initramfs and i suspected that something went wrong in line 39 of
the script "/usr/share/initramfs-tools/scripts/local":
eval eval $(fstype < ${ROOT})
maximilian attems wrote:
On Mon, 10 Apr 2006, Cesare Leonardi wrot
linux-headers-2.6-amiga_2.6.16-7_m68k.deb
to pool/main/l/linux-2.6/linux-headers-2.6-amiga_2.6.16-7_m68k.deb
linux-headers-2.6-bvme6000_2.6.16-7_m68k.deb
to pool/main/l/linux-2.6/linux-headers-2.6-bvme6000_2.6.16-7_m68k.deb
linux-headers-2.6-hp_2.6.16-7_m68k.deb
to pool/main/l/linux-2.6/linux
linux-2.6_2.6.16-7_m68k.changes uploaded successfully to localhost
along with the files:
linux-headers-2.6.16-1-all_2.6.16-7_m68k.deb
linux-headers-2.6.16-1-all-m68k_2.6.16-7_m68k.deb
linux-headers-2.6.16-1_2.6.16-7_m68k.deb
linux-image-2.6.16-1-amiga_2.6.16-7_m68k.deb
linux-headers-2.6.1
Hi folks
I regulary get requests for amd64 kernel for debian i386. I decided to
not do that yet.
There are two or so possibilities to do that:
- Build them in the i386 build. This will raise the count of image by 4
with 2.6.17.
- Repackage the amd64 packages. This produces only network load.
B
Processing commands for [EMAIL PROTECTED]:
> # sorry, didn't spot 358816 in the first place
> severity 361368 normal
Bug#361368: linux-image-2.6.16-1-powerpc: oops loading snd-powermac, no
soundcard
Severity set to `normal'.
> merge 361368 358816
Bug#358816: Loading snd-powermac causes an oops
B
Please file a bugreport (against the source package linux-2.6), instead
of addressing the mailinglist directly.
Generally, I personally recommend using the commandline tool reportbug
to file bugreports, as it automagically includes additional valuable
info.
Specifically, please do *not* respond
> > After some research, it turned out that the initrd image file had a
> > problem. I tred to fix it creating a new initrd image with mkinitramfs
> > -k 2.6.15-1-686 -u -t, but it showed the same problem at boot up. Then I
> > used mkinitrd -o /boot/initrd-img-2.6.15-1-686 2.6.15-1-686 and it
> >
On Wed, 29 Mar 2006, Harry Coin wrote:
> I suspect this problem occurs in all cases where the bios 'boot' device
> is not the eventual final root device and
> the root device discovery / setup process takes some time to settle (usb
> storage setups, raid setups, etc.)
>
does latest initramfs-too
tags 358360 moreinfo
stop
On Wed, 22 Mar 2006, Michal Sojka wrote:
> The description of this bug is the same as for #344754. The only
> difference is the version of package. The solution presented in
> #344754 works in my case as well. The problem appears with standard
> Debian kernel 2.6.15-1-68
Processing commands for [EMAIL PROTECTED]:
> tags 358360 moreinfo
Bug#358360: initramfs-tools: Doesn't find hdd (module ide-disk)
Tags were: unreproducible
Tags added: moreinfo
> stop
Stopping processing here.
Please contact me if you need assistance.
Debian bug tracking system administrator
(a
severity 355013 normal
stop
On Thu, 02 Mar 2006, Christian Weeks wrote:
> I use LVM on all my disks. I swapped an old laptop disk into another
> laptop for testing and my laptop now fails to boot normally but rather
> drops into the busybox.
>
> An analysis of this problem indicates that there a
Processing commands for [EMAIL PROTECTED]:
> severity 355013 normal
Bug#355013: initramfs-tools: device mapper device ordering breaks boot
(sometimes)
Severity set to `normal'.
> stop
Stopping processing here.
Please contact me if you need assistance.
Debian bug tracking system administrator
(
severity 362816 important
tags 362816 moreinfo
stop
On Sat, 15 Apr 2006, Fabien Fivaz wrote:
> Package: initramfs-tools
> Version: 0.59b
> Severity: critical
> Justification: breaks the whole system
nack it works on many boxes out there according to popcon stats.
also next time when you submit
Processing commands for [EMAIL PROTECTED]:
> severity 362816 important
Bug#362816: initramfs-tools: Initramfs-tools creates a buggy initrd image file.
Severity set to `important'.
> tags 362816 moreinfo
Bug#362816: initramfs-tools: Initramfs-tools creates a buggy initrd image file.
There were no
On Fri, Apr 14, 2006 at 09:24:22PM +0200, maximilian attems wrote:
> > Having evms call update-initramfs at install time is completely gratuitous,
> > because the system *won't* be set up for evms at the time of the evms
> > postinst: either the update-initramfs will be a complete no-op and have to
36 matches
Mail list logo
