Here I get
$ md5sum debian-testing-i386-netinst.iso
07b6034367c171526c4fbcdf0851162c debian-testing-i386-netinst.iso
166703104 Byte, downloaded with wget
Funny, though, that it runs properly for all the rest of the install. I
went through until the network was to be configured.
I'll try
Op 05-03-2007 om 23:15 schreef Uwe Dippel:
What next ?
Choose:
a) Reply http://lists.debian.org/debian-boot/2007/03/msg00118.html
b) Follow up http://lists.debian.org/debian-boot/2007/03/msg00119.html
c) Something other that a good community member would do.
Cheers
Geert Stappers
P.S.
Be fscking intelligent and *leave* a download for everyone to
pick it up,
before you replace it.
Leave older versions in separate directories and just change
the link to it.
Be fscking intelligent and try this:
wget
peter green wrote:
This is a problem though, using symlinks for the downloads like this
rather than just updating the links essentially means that any user
who doesn't pay carefull attention to how things are done and has a
long download containing resumes (e.g. a user who has a slow and
On Mar 5, 2007, at 5:40 PM, Joey Hess wrote:
Something wrong with rsync? I think zsync can also be used.
zsync works great. It doesn't work with DVD images -- something
about files larger than 2GB (31 bit byte offsets).
Rick
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject
Updating the links on a daily basis synchronised with CD builds is
unfortunately not possible given the design of the Debian website.
would it be possible soloution to make the links on the debian-installer page
point to a page hosted on the cdimage server (and therefore able to updated by
the
Uwe Dippel wrote:
My excuses if you read this as hostile. Ways to express oneself are
different.
Means of self-expression that don't include terms like fscking
unintelligent tend to have better results.
my suggestion would be to link to the directory instead to the file.
We do link
On Tuesday 06 March 2007 00:30, Joey Hess wrote:
We do link to directories for everything except the netinst and
businesscard. I think it would be reasonable to link to the directory
for those now (there may have been problems doing that before due to
the layout).
Done. I have long felt
On 3/4/07, Uwe Dippel [EMAIL PROTECTED] wrote:
I
I'll try another download.
Which takes around one day in MY ... .
Just for curiosity, I used the real(== from CDROM) Sarge-netinstaller of
years ago. It goes through smoothly.
Now I think to stick with it, install it, change the sources.list.
Uwe Dippel wrote:
On 3/4/07, Uwe Dippel [EMAIL PROTECTED] wrote:
I
I'll try another download.
Which takes around one day in MY ... .
Just for curiosity, I used the real(== from CDROM) Sarge-netinstaller of
years ago. It goes through smoothly.
Now I think to stick with it, install it,
On Sunday 04 March 2007 08:47, Uwe Dippel wrote:
Now I think to stick with it, install it, change the sources.list. It
should result in just the same Etch, right ?
No, not quite. For example, the system will still be using legacy
encodings while a newly installer system will use UTF-8. Eddy
On Sun, 4 Mar 2007, Eddy Petrior wrote:
Also note that will have to change the sources *after* you installed
sarge and that would mean extra traffic (if you prefer to install a
full desktop task, the sarge packages will be downloaded, then the
new ones will too). Changing before will probably
On 3/4/07, Uwe Dippel [EMAIL PROTECTED] wrote:
I'll try another download.
Which takes around one day in MY ... .
No, sorry, I'll never get it, ever. This is just silly: while I am
downloading you guys upload the latest version, and then wget switches the
length.
--17:18:44--
On Mon, 5 Mar 2007, Uwe Dippel wrote:
Be fscking intelligent and *leave* a download for everyone to pick it up,
before you replace it.
Leave older versions in separate directories and just change the link to it.
Be fscking intelligent and try this:
wget
On Mon, 5 Mar 2007 00:26:45 +0800, Uwe Dippel [EMAIL PROTECTED]
wrote:
Be fscking intelligent and *leave* a download for everyone to pick it up,
before you replace it.
Leave older versions in separate directories and just change the link to it.
Although such a hostile message deserves no reply,
Although such a hostile message deserves no reply, I point out for
others who may not know it that [1]upstream of the arch-latest directory
one finds exactly the structure described above. It's been that way for
years, as I used it to follow Sarge development.
My excuses if you read this as
Subject says it:
debian-testing-i386-netinst.iso (20070303) does not 'see' the eth0 offered
by qemu. I have checked with dmesg | grep eth0, it is empty. It is no qemu
problem, since in all other images I use: KNOPPIX, DSL, ... eth0, comes up
properly. On the .iso as well as on the ensuing 'hard
Uwe Dippel wrote:
Subject says it:
debian-testing-i386-netinst.iso (20070303) does not 'see' the eth0 offered
by qemu. I have checked with dmesg | grep eth0, it is empty. It is no qemu
problem, since in all other images I use: KNOPPIX, DSL, ... eth0, comes up
properly. On the .iso as well as
On Sunday 04 March 2007 02:35, Uwe Dippel wrote:
debian-testing-i386-netinst.iso (20070303) does not 'see' the eth0
offered by qemu. I have checked with dmesg | grep eth0, it is empty. It
is no qemu problem, since in all other images I use: KNOPPIX, DSL, ...
eth0, comes up properly. On the
Debian-Debian ?
I should have said that here it is OpenSolaris-Debian.
I don't have to hammer on the fact that qemu -cdrom DSL.iso *does* 'eth0
detected, broadcast ...'; and dmesg finds RTL-8029 just fine. Started in the
same terminal, just one line down from the non-.working netinstaller.
Uwe
I checked the md5 and compared it with the website. It is different.
Here I get
$ md5sum debian-testing-i386-netinst.iso
07b6034367c171526c4fbcdf0851162c debian-testing-i386-netinst.iso
166703104 Byte, downloaded with wget
Funny, though, that it runs properly for all the rest of the install. I
21 matches
Mail list logo
