On Friday 12 September 2008, maximilian attems wrote:
I thought about that, but that assumes the default of initramfs-tools
won't ever change. I'd prefer not to base code on that assumption.
i'm happy with d-i setting it for specific embedded arch, but please
drop that file when it is
sorry for the late dropin, haven't seen that before today #498712
came in. which clearly shows the uglyness of the current situation,
why should the same variable be set on *two* places.
On Mon, 25 Aug 2008, Frans Pop wrote:
On Monday 25 August 2008, Martin Michlmayr wrote:
- the question was
Just for the record, this works as expected. Thanks a lot for
implementing this, Frans!
--
Martin Michlmayr
http://www.cyrius.com/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Frans,
There's one thing that imho could be improved with the current
driver-policy handling. IMHO it would make sense not to create the
/etc/initramfs-tools/conf.d/driver-policy file if these conditions are
met:
- the question was not asked (because debconf priority medium)
- the policy is
On Monday 25 August 2008, Martin Michlmayr wrote:
- the question was not asked (because debconf priority medium)
That would break the case where the architecture default if different from
the default of initramfs-tools.
- the policy is the same as the default of initramfs-tools (most)
I
* Frans Pop [EMAIL PROTECTED] [2008-08-25 10:10]:
On Monday 25 August 2008, Martin Michlmayr wrote:
- the question was not asked (because debconf priority medium)
That would break the case where the architecture default if different from
the default of initramfs-tools
This would be met
* Jérémy Bobbio [EMAIL PROTECTED] [2008-08-17 01:05]:
The patch has been commited by Christian, although I have then removed
the defaulting to dep on i386 and amd64 based on your comments.
Please make the necessary adjustements for the relevant NAS devices.
Done.
--
Martin Michlmayr
On Fri, Aug 15, 2008 at 10:05:59PM +0300, Martin Michlmayr wrote:
Frans said earlier:
It is also needed for e.g. arm where in some cases the initrd is
getting too big for the flash memory it needs to fit in.
So, do you think that it would make sense for NAS or similar devices?
On Sun, Aug 10, 2008 at 09:03:46AM +0300, Martin Michlmayr wrote:
* Frans Pop [EMAIL PROTECTED] [2008-08-09 19:53]:
With the default initrd now being over 6 GB on amd64 and the fact
that lilo has structural problems with large initrds, I think that
implementing something like the attached
* Jérémy Bobbio [EMAIL PROTECTED] [2008-08-15 17:51]:
2) The LILO bug has been fixed.
Frans said earlier:
It is also needed for e.g. arm where in some cases the initrd is
getting too big for the flash memory it needs to fit in.
So, do you think that it would make sense for NAS or
* Frans Pop [EMAIL PROTECTED] [2008-08-09 19:53]:
With the default initrd now being over 6 GB on amd64 and the fact
that lilo has structural problems with large initrds, I think that
implementing something like the attached patch for Lenny is almost
unavoidable.
Nice patch. I wouldn't change
Package: base-installer
Version: 1.93
Severity: wishlist
Tags: patch
With the default initrd now being over 6 GB on amd64 and the fact that
lilo has structural problems with large initrds, I think that
implementing something like the attached patch for Lenny is almost
unavoidable.
It is also
On Saturday 09 August 2008, Frans Pop wrote:
With the default initrd now being over 6 GB on amd64 and the fact that
That should have been MB. Still insane.
signature.asc
Description: This is a digitally signed message part.
13 matches
Mail list logo
