Windows 10 Pro, System Image Restore error “Element not found (0x80070490)”

I was adding a new 1TB SSD into my Dell Inspiron 3668 Desktop, and making this drive the C Drive, where Windows 10 Pro and all applications sit. And I have a previous System Image Backup ( SIB ) taken from the same system, which I wanted to restore after installing Windows.

Original configuration

There were two existing hard disks:

C drive: 1TB HDD — Windows 10 Pro and applications drive.

D drive: 128GB SSD — working drive.

There is also a read/write DVD drive.

The System Image Backup ( SIB ) was taken in this configuration.

New configuration

DELL Inspiron 3668 System Board Components.
DELL Inspiron 3668 System Board Components.

Adding a 1TB SSD, connecting it onto SATA 0 connector on the motherboard.

The existing Drive D, 128GB SSD is connecting onto SATA 2 connector.

The new 1TB SSD was initialised to GPT partition, and was partitioned into two partitions and were assigned Drive E and Drive F — assigning Drive letters at this point is rather irrelevant.

Installation Windows 10 Pro

Disconnected both 1TB HDD ( existing Drive C ) and 128GB SSD ( existing Drive D ).

Reconfigured the BIOS to boot in UEFI mode via USB “Windows 10 UEFI boot media”.

Installed Windows 10 Pro onto the first partition on the new 1TB SSD ( the only Drive that was connected. )

Windows 10 Pro was installed successfully.

The partition where Windows 10 Pro was installed became Drive C by default, the other partition was not yet active.

Restore the previous Windows 10 Pro System Image Backup ( SIB )

This SIB was on an external USB drive.

Windows 10 Pro was able to recognise this SIB, but it refused to restore, it wanted the machine to be booted up via USB “Windows 10 UEFI boot media” and restore from there.

After booting, selecting the time zone, and on the next screen, select “Repair Windows” instead of “Install”, then follow the appropriate option to restore from the mentioned SIB.

But it just simply refused to restore, reporting the error “Element not found (0x80070490)”.

— That was about 1:00 in the morning.

Searching Google gave a few results, most are from Microsoft, but none were useful!!

About an hour into the search, I came across this one post, from a site which I had not seen before, whereby they exercised their Backup and Recovery procedure for VMWare machines, and they had the same error, what they did was mounting another very small virtual drive, around 20MB and they were able to proceed.

I do apologise for not remember the site, I tried to relocate it, but could not.

So I reconnected the existing 128GB SSD to SATA 2 connector, and keeping it as Drive D as was before.

The restoration process was successfully ran.

BUT: AFTER THE SIB WAS RESTORED, the unused, inactive partition on Drive C ( the new 1TB SSD ) was removed! It now had only a single partition: but using Windows Disk Management I was able to shrink it down and made another partition as was before.

AND this does raise a concern: next time, will the restoration process remove this partition again? And so, all data will be lost!

Multiple path names for a same component in React Router

I have a Search class component, which takes a YouTube channel Id, and returns info on the public videos in the uploads playlist for this channel.

The route to this component is declared as:

<Route exact path=”/channelvideos/:channelId” render={ (props) =>
<Search channelId={props.match.params.channelId}/>
} />

On the UI side, there is a fixed link and dynamic links which use this component. The fixed link uses my YouTube channel Id, and it’s always visible, it can be clicked on at any time..

The UI for the fixed link is:

<Link to={`/channelvideos/${process.env.REACT_APP_CHANNEL_ID}`}>Hoàng Kỳ Channel</Link>

where process.env.REACT_APP_CHANNEL_ID holds my YouTube channel Id.

The UI for the dynamic links is similar:

<Link to={`/channelvideos/${item.id}`}>{item.title}</Link>

( The Search component will have to look in this.props for channelId ).

The problem: clicking on a dynamic link retrieves videos for that channel, and that’s correct. Now, click on the fixed link ( i.e. the link with label Hoàng Kỳ Channel ) — NOTHING HAPPENS!

This is because Search is still in the DOM; while componentDidMount() needs to run!

I’ve chosen the solution suggested in the following post https://github.com/ReactTraining/react-router/issues/1669#issuecomment-386254968. And so, the route is modified to:

<Route exact path=”/channelvideos/:channelId” render={ (props) =>
<Search channelId={props.match.params.channelId} key={props.match.params.channelId}/>
} />

It has key={props.match.params.channelId} added.

This means that old Search will unmount, a new Search will mount, and componentDidMount() fires: the entire new component rendered. Fetching of videos info takes place within componentDidMount(). New content replaces existing content, so I don’t think re-rendering the entire component is a performance penalty?

Comming from Delphi, PHP etc… background, I am still getting my head around React, Redux etc… I’m not certain if this is the most appropriate solution. Refactoring will possibly take place as I go along… For now, I settle for this solution.

Tiếng Việt, IT ( Information Technology ) Công Nghệ Thông Tin: những Nghiên Cứu Cần Thiết!

Vấn Đề

Tiếng Việt độc âm. Nhưng chữ Việt không độc âm.

Hải đường mơn mởn cành tơ
Hải đường mơn mởn cành tơ

Hai câu thơ bên dưới trong Truyện Kiều, có bao nhiêu âm, và bao nhiêu chữ?

Hải đường mơn mởn cành tơ
Ngày Xuân càng gió càng mưa càng nồng

— Có tổng cộng 14 ( mười bốn ) âm, nhưng chỉ có 12 ( mười hai ) chữ!

Trong các ngôn ngữ Châu Âu, một chuỗi mẫu tự liền nhau, có một khoảng trống ở sau, hoặc khoảng trống ở trước và sau là một chữ. Thí dụ:

I am writing now.

Thì “I“, “am“, “writing” và “now” là chữ.

Vô cùng đơn giản. Tiếng Việt không đơn giản như vậy: đây không phải là đặc điểm của tiếng Việt, một vài ngôn ngữ Á Châu khác cũng có chung điểm này với tiếng Việt.

*
* *

Natural Language Processing ( NLP ) và Computational Linguistics

Có bao giờ quý vị đã thử sử dụng Google để dịch từ tiếng Anh sang tiếng Việt?

— Thường thì trật lất hết!

Trong khi từ tiếng Anh sang các tiếng Âu khác ( hay ngược lại ), tiếng Nhật sang tiếng Anh, tiếng Tàu sang tiếng Anh độ chính xác khá cao.

Trong một cuộc triển lãm máy “vi tính” ( thời đó thì chưa “vi” ) thuộc loại đầu tiên, người ta xiểng dương công dụng “dịch thuật tự động” — họ biểu diễn “dịch” vài câu từ tiếng Anh sang tiếng Nga, và ngược lại.

( Thành thật xin lỗi, vì không dẫn tài liệu chính xác. Tôi đọc hồi 1990s. )

Thật sự đó chỉ là màn biểu diễn bồng bột… Nhưng áp dụng máy vi tính vào “xử lý” ngôn ngữ, theo đà phát triển của máy vi tính đã thành chuyên ngành riêng biệt của khoa học vi tính: Natural Language Processing ( NLP ) và Computational Linguistics.

— Diễn tả sơ lược ở bề mặt thì NLP và Computational Linguistics là sử dụng khoa học vi tính ( máy vi tính ) để phân tích cấu trúc ngữ pháp, đánh vần v.v… và từ đó làm bàn đạp để làm được nhiều việc khác khó hơn. Thí dụ: kiểm tra ngữ pháp, tự động chỉnh sửa chính tả, chữ sang bài đọc tự động hoặc chúng ta đọc tự động sang chữ… và dĩ nhiên dịch thuật tự động hay Machine Translation.

Thập niên 1990s, nghiên cứu về NLP / Computational Linguistics / Machine Translation rất mạnh. Chắc có lẽ đến bây giờ nghiên cứu vẫn chưa ngưng, đặc biệt với những khám phá ngày càng cao của Artificial Intelligence.

Thí dụ: người ta tạo ra một cô Android xinh như mộng và cố gắng cho cô này khả năng đối đáp bằng ngôn ngữ bình thường. Đó là một áp dụng của NLP / Computational Linguistics / Artificial Intelligence.

Thập niên 1990s, trong thư viện của đại học RMIT ( đã có một chi nhánh ở Việt Nam từ lâu ), có gần như nguyên một tầng chỉ chứa sách vỡ về NLP / Computational Linguistics / Machine Translation. Chủ yếu liên quan đến tiếng Anh.

Thời đó, tiếng Tàu, tiếng Nhật, tiếng Ấn cũng đã có những nghiên cứu đáng kể.

Cho nên đừng ngạc nhiên vì sao Google “dịch” tiếng Việt quá tệ: ngay cả một tự điển Anh-Việt online nghiêm chỉnh chúng ta còn chưa có.

*
* *

Trở Lại Vấn Đề của Tiếng Việt

Như đã bàn về phần “âm” và “chữ” ở bên trên, chúng ta có thể thấy, trong một câu tiếng Việt, trước khi phân tích ngữ pháp, chúng ta phải biết đâu là âm đâu là chữ.

— Hình như vì tiếng Việt là ngôn ngữ đầu tiên của chúng ta nên chúng ta phân biệt một cách thật “tự động”?

Nhưng computers ( software của máy vi tính ) thì không! Chúng ta cần phải có những phương pháp để phân tích dẫn đến kết quả chính xác.

Hải đường mơn mởn cành tơ
Ngày Xuân càng gió càng mưa càng nồng

Chúng ta biết được “hải đường” là chữ hai âm, “mơn mởn” là chữ hai âm, còn lại là những chữ độc âm.

— Vấn đề là làm sao để computers “hiểu” được và đưa ra kết quả giống chúng ta!

Không qua được “cửa ải” nhận diện “đâu là chữ” này, thì những phân tích ngữ pháp cần thiết ở độ cao hơn, thí dụ, thành phần ngữ pháp của câu, sẽ không xảy ra được.

Bây giờ, mời quý vị xem ba câu sau:

Ông ấy bà con với tôi.

Bà con đi chợ rồi.

Bà con ơi, xin giữ im lặng.

Hai âm liền nhau “” và “con” trong ba câu, vai trò cấu trúc ngữ pháp có khác nhau không?

Bà con” trong câu đầu và cuối là chữ hai âm. Còn trong câu thứ nhì, là hai chữ độc âm riêng biệt!

Cho nên trong tiếng Việt, vấn đề nhận diện ( biên giới của ) mỗi chữ trong một câu không đơn giản.

*
* *

Nghiên cứu về NLP / Computational Linguistics / Machine Translation áp dụng cho tiếng Việt tôi không tiếp tục.

Sử dụng kiến thức cũ, đưa ra một vài vấn đề ngõ hầu cùng nhau suy gẫm cho một sự khiếm khuyết thua kém của chúng ta.

Chúng ta thua và sau thế giới nhiều quá. Chỉ khi nào chúng ta có một xã hội đàng hoàng, một nền chính trị Tự Do và Công Bằng chúng ta mới có hy vọng phục hưng là cái học của nước nhà. Và sau đó ráng sức đuổi cho kịp thiên hạ.

09/09/2018.

Tìm Hiểu Cơ Bản về Mã Hóa: “Encryption” hay “Encrypted” Tin Nhắn / Emails v.v…

Khi chúng ta lên mạng, vào bất kỳ nơi nào nếu thấy địa chỉ bắt đầu bằng “https”, thí dụ https://www.facebook.com/ — thì tất cả những gì chúng ta thấy trên màn hình, hoặc viết gửi đi v.v… trên nguyên tắc, đều được mã hóa.

— Có nghĩa là trong quá trình chuyển đi, chuyển lại, có ai đó ăn cắp những thông tin này, họ cũng không đọc được hay “giải mã” được.

Thí dụ, khi chúng ta mua đồ trên Amazon, Hoa Kỳ, và gửi thông tin về thẻ tín dụng sang Hoa Kỳ, có kẻ nào đó ăn cắp được những thông tin này trên đường di chuyển — chúng cũng không giải mã được thông tin để đọc được thẻ tín dụng để ăn cắp tiền.

Nhìn chung, “sức mạnh” của mã hóa không phải ở phương pháp ( algorithm ) mã hóa mà ở “sức mạnh” của chìa khóa mã hóa ( encryption key ).

Chìa khóa 128-bit đã được sử dụng khá lâu và chưa ai bẻ được.

Vậy “encryption key” bảo vệ thông tin ra sao?

“Bit” là số nhị phân. Một bit chỉ có thể có một trong hai giá trị: 0 hoặc 1.

Giải thích 128-bit encryption có lẽ hơi rắc rối. Thử tìm hiểu bằng bằng chìa khóa 2-bit trước.

Một bit có hai giá trị. Tập hợp của hai bit sẽ tạo ra bốn giá trị khác nhau, vì là 2 lũy thừa 2 ( 2^2 = 4 ):

Nhị phân: 00 –> hệ số mười, thập phân, là 0
Nhị phân: 01 –> hệ số mười là 1
Nhị phân: 10 –> hệ số mườk là 2
Nhị phân: 11 –> hệ số mười là 3

“Brute-force attack” là cái kiểu tấn công giải mã Vai U Thịt Bắp, tấn công bằng “vũ lực” bên kia đạn sắt bên ta đầu chì, thì người ta sẽ:

— Sử dụng chìa khóa 00 để giải, nếu không được thì chìa khóa 01, tiếp theo là 10, sau cùng là 11.

Trong bốn chìa khóa này, sẽ có một chìa giải mã được thông tin đã được mã hóa.

Như vậy, với cái chìa khóa 2-bit, thì tỷ lệ thành công của brute-force attack là 25%. Theo cách tính:

1 / ( 2^2 ) = 1 / 4 = 25%

Thêm một thí dụ nữa. Hãy tưởng tượng, chìa khóa bây giờ là 3-bit, thì chúng ta có tổng cộng là tám ( 8 ) chìa khóa khác nhau vì:

2^3 = 2 * 2 * 2 = 8

Đây là giá trị của tám ( 8 ) chìa khóa:

000
001
010
011
100
101
110
111

Trong tám ( 8 ) chìa khóa này, chỉ có một ( 1 ) là có giá trị. Vậy xác suất thành công của brute-force attack là 12.5%:

1 / ( 2^3 ) = 1 / 8 = 12.5%

Như vậy, chìa khóa 128-bit có tổng cộng là 2^128 chìa khóa! Và trong đó chỉ có một chìa khóa là giải được!

2^128 là khoảng chừng 340,282,366,920,938,000,000,000,000,000,000,000,000 hay 3.4028237e+38!

Như vậy cái xác suất thành công của brute-force attack với chìa khóa 128-bit là:

1 / ( 2^128) = 1 / 340,282,366,920,938,000,000,000,000,000,000,000,000 = ??%

Hiện tại, 128-bit chưa bị bẻ gãy vì có quá nhiều chìa khóa để thử!

Xin lưu ý, đây chỉ là cách giải thích rất cơ bản. Không đến nơi đến chốn. Encryption trong IT là một nhánh chuyên môn dành riêng cho những bộ não toán học siêu việt!

*
* *

Chìa khóa 128-bit đã được sử dụng khá lâu và chưa ai bẻ được.

Nhưng hiện tại, người ta đã sử dụng chìa khóa 256-bit ( 128 * 2 = 256 ), và đã 1,024-bit ( 256 * 2 ).

— Và Google cũng đã sử dụng chìa khóa 2,048-bit ( 1024 * 2 ) rồi.

02/07/2018