On 09/01/2011 09:33 AM, Ronny Standtke wrote:
I actually can lend you an Intel Mac mini. I can organize everything
minus the part about the invoice. Interested?
you can, but i'll will not get arround to it before mid of october,
possibly even later, don't know yet.
--
Address:Daniel
> however, if you're sincere lend me an intel mac (either a notebook or a
> mini with either an hdmi or vga adapter), don't forget to include the
> address where to ship it back to, the correct amount of stamps for
> returning it, the address and name where to send the invoice to, and
> send me
On 09/01/2011 08:35 AM, Ronny Standtke wrote:
You are officially invited to come over to our place and use all the
infrastructure you want.
apart from the fact that efi support is low on my todo list and i've got
more important things to do first for this month.. traveling is out of
the quest
> rather than sit down for one day and add grub-efi support in lb to fix
> the original problem.
As I alread said, this is not within my area of expertise.
> one day for adding grub-efi support is more than enough; and no, i can't do
> it, i don't have the hardware for it.
You are officially in
On 09/01/2011 12:04 AM, Ronny Standtke wrote:
Turning a useful contribution into an argumentum ad personam is quite lousy.
And words like "always" are *always* wrong in this context.
you're actively advertising a workaround that is wrong (see mails in the
june thread) and has potential for hig
> > The original problem is that we can't boot the USB flash drive on a Mac.
> > Until this is not fixed we need the workaround. Do we agree on that?
>
> no.
OK, I retry with a shorter boolean expression: The original problem is that we
can't boot the USB flash drive on a Mac. Do we agree on tha
On 08/30/2011 11:12 PM, Ronny Standtke wrote:
The original problem is that we can't boot the USB flash drive on a Mac. Until
this is not fixed we need the workaround. Do we agree on that?
no.
it always the same with you, you insist on doing workarounds instead of
(helping) to fix the problem.
> again, for everone else: don't do workarounds and fix the original problem.
The original problem is that we can't boot the USB flash drive on a Mac. Until
this is not fixed we need the workaround. Do we agree on that?
--
To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org
with a su
On 08/30/2011 06:34 PM, Ronny Standtke wrote:
Again a short summary why we need this hook:
[...]
We must *PREVENT*(!) kernel upgrades because otherwise they run into
inconsistencies when using the system on a Mac (available kernel modules
suddenly don't fit the currently used kernel, etc.). T
Hi all
I just upgraded the pinning hook so that it also works with packages
already defined in /etc/apt/preferences (e.g. because you want to take
them from backports.debian.org, etc.)
Again a short summary why we need this hook:
The users of our Debian Live based distribution have a DVD with
> i see you have not understood anything i wrote.
What a bold statement. From my point of view it's you who is trying very hard
to misunderstand and to misinterpret.
> this happened for several times in the past time on this list. i therefore
> conclude that we apparently can't communicate toge
On 06/12/2011 09:54 AM, Ronny Standtke wrote:
So far I have not seen an alternative proposal that correctly works in all
situations.
i see you have not understood anything i wrote. this happened for
several times in the past time on this list. i therefore conclude that
we apparently can't com
> depends on how you define 'consistent'.
'Consistency' means in this case that all kernel related files (modules,
headers, ...) that are visible after the boot process finished (and
percistency is activated) exactly match the kernel version used for booting up
the system.
> if you just mean '
s burden is taken off your shoulders with the the pinning hook, it does
this *automatically* for you: it just adds the packages to pin with their
current version number of the current build to the apt preferences file.
> Even using pinning the kernel upgrade can't build new initrd/vmlinu
On 06/10/2011 05:38 PM, Ronny Standtke wrote:
> Which of the packages pinned in the hook do you think can
> successfully be upgraded on a Debian Live system (in its current design)
> and still have a consistent system afterwards?
depends on how you define 'consistent'. if you just mean 'bootable',
hello everyone.
sry, i dont understand what is this [pinning hook] for.
I may be wrong, but AFAIK kernel upgrade in a live system can't be done
because live-build prevent it from happening by "trunkating"
update-initramfs command before it is included in the final live
> your suggested hook disables to many packages to achieve that, so this
> can't really be the solution to it.
As far as I see this, it's just the kernel and its directly related
packages. Which of the packages pinned in the hook do you think can
successfully be upgraded on a Debian Live system (
On 06/10/2011 05:08 PM, Ronny Standtke wrote:
That's what I meant.
your suggested hook disables to many packages to achieve that, so this
can't really be the solution to it.
This will fail in situations where you have your live-rw on a writable
media (e.g. USB flash drive) but your live ima
> the only files that cannot be upgraded normally is vmlinuz and
> initrd.img.
That's what I meant.
> since the default on a live system with persistency should
> be to behave like a regular system, the default on a live system with
> persistency should therefore be to copy out the initrd and
On 06/10/2011 03:01 PM, Ronny Standtke wrote:
Because kernel, initramfs and live-boot are loaded and run before
persistence is even activated.
i don't think so.
the only files that cannot be upgraded normally is vmlinuz and
initrd.img. since the default on a live system with persistency shoul
2011/6/10 Ronny Standtke
> > > While most of the software packages on such a system can be upgraded,
> some just
> > > can't.
> >
> > why?
>
> Because kernel, initramfs and live-boot are loaded and run before
> persistence is even activated.
>
Makes sense, probably it should be done as default.
> > While most of the software packages on such a system can be upgraded, some
> > just
> > can't.
>
> why?
Because kernel, initramfs and live-boot are loaded and run before
persistence is even activated.
--
To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org
with a subject of "uns
On 06/10/2011 10:45 AM, Ronny Standtke wrote:
> While most of the software packages on such a system can be upgraded, some
> just
> can't.
why?
--
Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email: daniel.baum...@progress-technologies.net
Internet: http://peopl
Hi all
I use Debian Live most of the time with enabled persistence. While most
of the software packages on such a system can be upgraded, some just
can't. Therefore, I created a small hook to pin those packages (see
attachment). It works great for my purposes.
Feel free to use, improve, add this
24 matches
Mail list logo
