Package: live-helper
Version: 1.0~a16-1
Severity: normal
--- Please enter the report below this line. ---
I've a lot of packages that are installed because they are listed in the
config/chroot_local-packagelists/extra.txt and are fetched from a custom
debian archive listed in
Hi,
After the lh_* these debs are not in the cache directory and are
re-download over and over.
The caching mechanism is working fine for external repositories here
with 1.0~a16-1.
You could give us more details about the complete procedure you use.
Cheers
--
Mathieu
Chris Ross wrote:
So, it's looks pretty nice through there except for the hostname
issue (I've always seen this. Is this based on the hostname= that's
on the kernel argument list? Is it avoidable?), the only problem I
see is the odd fsck 1.40-WIP comment from fsck.
did you specify
On Jun 30, 2007, at 9:10 AM, Daniel Baumann wrote:
Chris Ross wrote:
So, it's looks pretty nice through there except for the hostname
issue (I've always seen this. Is this based on the hostname= that's
on the kernel argument list? Is it avoidable?),
did you specify an empty hostname
Chris Ross wrote:
Perhaps the '_' is irritating it?
yes, hostnames cannot have '_' caracters.
Maybe I misunderstand you, or we're talking about things in two
different directions here. :-)
well, we are talking about two different symptoms cause by the same root
problem: fsck should not
On Jun 30, 2007, at 9:39 AM, Daniel Baumann wrote:
Chris Ross wrote:
Perhaps the '_' is irritating it?
yes, hostnames cannot have '_' caracters.
Yup. I had that same thought, and have removed that character.
Thanks...
well, we are talking about two different symptoms cause by the
Alle sabato 30 giugno 2007, Daniel Baumann ha scritto:
fsck should not be run on the live system at all. we'll need to
completely disable this in the initscripts, somehow.
We could just have the initramfs touching a /fastboot file and the checkfs
init script will remove it
This because: $
On Jun 30, 2007, at 10:48 AM, Marco Amadori wrote:
fsck should not be run on the live system at all. we'll need to
completely disable this in the initscripts, somehow.
We could just have the initramfs touching a /fastboot file and
the checkfs
init script will remove it
This because: $
Marco Amadori wrote:
We could just have the initramfs touching a /fastboot file and the checkfs
init script will remove it
to complicated; i just added the removal of /etc/rcS.d/S*checkfs.sh in
12fstab.
But maybe we should offer also a boot parameter option to have this default
behaviour
Alle sabato 30 giugno 2007, Daniel Baumann ha scritto:
We could just have the initramfs touching a /fastboot file and the
checkfs init script will remove it
to complicated; i just added the removal of /etc/rcS.d/S*checkfs.sh in
12fstab.
I'll look when you commit, anyway touching a file is
Marco Amadori wrote:
to complicated; i just added the removal of /etc/rcS.d/S*checkfs.sh in
12fstab.
I'll look when you commit, anyway touching a file is not so complicated...
removing is simpler and faster since we do not need the script at all.
So you seems to need to patch also
Daniel Baumann wrote:
to complicated; i just added the removal of /etc/rcS.d/S*checkfs.sh in
12fstab.
I'm curious (and probably clueless): How does thia affect systems
installed from the live image using live-installer? Will they also lack
fs checking?
--
see shy jo
signature.asc
Alle sabato 30 giugno 2007, Joey Hess ha scritto:
Daniel Baumann wrote:
to complicated; i just added the removal of /etc/rcS.d/S*checkfs.sh in
12fstab.
I'm curious (and probably clueless): How does thia affect systems
installed from the live image using live-installer? Will they also lack
Marco Amadori wrote:
Yes they could lack it
no, they don't. because...
It will happen only if the user will use stackable fses (snapshots saved
back in the r-o media at /live)
live-installer does not and will not care about snapshots. this opens a
can of worms and is not supportable from
14 matches
Mail list logo
