Problem with recovery partition data
dteed at artistic.ca
Tue Apr 13 22:17:50 CEST 2004
I read someone saying they had excellent performance with lzop, so
I switched to an initrd with lzop as the default at the same
time I picked up your latest updates on Monday. So I guess
it can't be data corruption on that level. I did another test
this afternoon - checked that the original did work with F11,
sent it, restored to the same machine and hard drive and F11
did not work. This run was with the acpid stopped and KDE
sound server not starting on the server machine.
Given that a dd style of imaging should be working, where do you
suggest I start looking for something that could be more robust?
Should I replace busybox with another kernel that might provide
better module support for the ethernet, etc.? Should I get
rid of Xandros for the server and try another Linux distribution like
Slackware for the TFTPD and DHCP platform (which again allows to
substitute kernels for something that might be better)?
I can only assume the F11 flaw is a symptom of data loss in this
process, since the software sees the partition table information as
simple 1's and 0's. If it is possible for the F11 feature to be
busted, it might also be possible for other data to be wrong
but superficially appear to be mostly OK.
At this stage in our work we need to verify in the next few days
that udpcast will work for us or look for another application
or commercial product.
On Tue, 13 Apr 2004, Alain Knaff wrote:
> begin Tuesday 13 April 2004 20:11, Donald Teed quote:
> > I guess that given the nature of UDP we have no way of knowing whether
> > data transferred is going through correctly. Is there something
> > that can be done to improve on this situation?
> One trick is to use compression (lzop). Although this doesn't prevent
> bit errors, it would make them very obvious: rather than having
> slightly different copies, it would abort with a CRC error.
> On the LLL project, we almost always use compression (it makes cast
> times much shorter), and in several years of operations, we only had a
> single case where a bit error occurred and made the compression abort.
More information about the Udpcast