I have got an old EEE 900 pc.. I wanted to install a really light weight os to try out.
But i can't find out from internet if it is 32bit or 64bits supported .. i suppose it is 32bits.. but not sure.
Since most Linux os has dropped 32bits support.. Hence my choice is limited.
The laptop was previously installed android os on it..

Since i don't have windows installed on it, i have no idea how to check what it supports..

I just manage to find out it uses Processor 900MHz Intel Celeron M

Did a googling:
Intel website said the processor is actually named:
Intel® Celeron® M Processor ULV 353 (512K Cache, 900 MHz, 400 MHz FSB)

Memory Specifications: Physical Address Extensions 32-bit
Instruction Set 32-bit

If the processor model is correct, i am making a guess:
since memory is 32 bits and instruction set is 32 bits.. that means it only support 32 bits os..
Correct me if i am wrong.

I have installed "slax-32bit-9.11.0.iso" (the only one that support 32bits) onto usbstick using:
But when power up the laptop with the usb, it just does not boot into it.
When i tried with my ventoy usb, it is able to boot into ventoy menu.

What could be wrong here ? the iso is not supported ?
the DD command burnt wrong ?
or i should format the usbstick before dd ?

Thx

Hello! I am also an EEE PC enthusiast. Most were 32-bit only. In fact, I think ALL of them were released as 32-bit machines, but some of the last models (I have a 1025-C) had Atom processors that supported 64-bit operations (N2600 and N2800, the two trailing zeros indicated 64-bit capability I believe). I think those were the exception, and the vast majority of EEE PC's were indeed truly 32-bit only. From the output you posted, yours is definitely 32-bit only. Those memory specifications are the dead giveaway, you are correct on that one.

Your usb writing commands also seem fine to me. Are you sure you need the conv=fdatasync part? I never use that myself, although I run a sync command after the dd is finished.

Have you tried any other ISO's? A good known working one that is easy to download is the Slackware mini install iso. You don't have to actually install anything with it, but if you can just get it to boot that would be a good indicator at least. I use this one a lot on my 32-bit machines and it works every time, no special tricks needed.

Anyway, my best hunch is to try a few different ISO's and see if any of them work with that same USB stick. Best of luck.

Oh, one last idea... are you selecting the USB drive from the boot menu when you power up the machine? I assume you are, but I would be foolish not to ask.

2 members found this post helpful.

That slax-32bit-9.11.0.iso is not a hybrid ISO, and simply copying it to a USB stick with "dd" will not yield a bootable device.

1 members found this post helpful.

Hii!!

Great to know someone like EEE PC as well.. lol.. I bought this laptop in usa over 20 years i believe (if my memory does not fail me). it still running like a champ! only battery is dead.

Since you said it is 32 bits, i believe it is also.
Ya, i did select to boot up from usb, that's why it is able to run ventoy usb.. but not the slack that i dd..
When i read back my previous record, i believe the 32bit slax iso is a NON-HYBRID iso image.. hence dd when dd direct burn it onto usb stick, it does not run.
According to the GURUs here , Non hybrid iso are like CDROM format, it is not able to be burn directly onto usbstick. because usb stick does not run cdrom format.

They also said CDROM iso first sector is partitiontable,
While standard usbstick and hdd first sector is bootloader.. hence the difference.

I am trying to learn how to mount the non hybrid iso onto loop and then somehow make it into a bootable iso.. still reading.
If anybody know, i do appreciate some help.. save me some time crawling in googles to gather pieces of info together.

Good day to you. Your post cheer my evening, we both eee PC fan.. lol
Last time i used the eee pc on train, an old lady said to her partner : "i can't believe nowaday pc becomes so small !" .. i was like ha ha ha... (laughing in my heart)..

I will try your recommended iso as well. Thx

May i ask what is sync command does ? I don't understand the definition:
Synchronize cached writes to persistent storage
How you run the sync command after dd ?

Thx

Can you tell me how you tell that it is not hybrid iso ?
Thx

There is a tool called "isohybrid" that will do the conversion. Not knowing what OS you have running makes it hard to be more specific.

When I make a usb installer, I use the command
where sdx is the appropriate designation of the usb. The status option gives me an indication of how the copying is going and the sync command, run after dd has finished, ensures that the buffers really are flushed and everything is on the usb.

Linux does not automatically write stuff to disk. The kernel stores (caches) the output of programs in its buffers, then writes them to disk (aka "persistent storage") when there is a lull in the action. The sync command is a way of forcing the kernel to write out its buffers to disk on demand. The umount command also forces this action before unmounting the device.

Q1.
Does dd read data from iso image and just keep in buffer (ram) without writting into usbstick ? hence we need to force it to do so ?
Isn't DD utility is used to hard copy data bit by bit from iso file into usbstick when we run the Why then the need to run sync command after dd finish "burn" iso into usb stick ?

Q2.
What happen if i just run without running $sync command after dd finished copying , will some part of data (read from iso file) just left laying around in buffer without writting into usb stick ?

Why not just use this dd's option to flush ?

Neither dd nor any other userspace command can write directly to hardware. It's always the kernel which does that. As far as dd "knows", it works just as you have described. But actually its inputs come from the kernel, not directly from a file, and its outputs go back to the kernel again.
Exactly! If you don't run either sync or umount (which runs the sync system call for you), your usb stick won't contain a true image of what you think you have copied onto it. Unless, that is, some time has elapsed and the data has been written out in the normal course of events. So just pulling out a usb drive is a risky business. You should always unmount it properly first.

1 members found this post helpful.

Thanks Hazel, your reply is very enlightening..

I see.

You meant the data (of the iso image file) is actually read by kernel (because you said user space command can't access directly to hardware) under request of dd and store it in buffer , then "dd" software tell kernel to push the data from the buffer into the usbstick (persistent storage).
Is that it ? dd does nothing but instructing kernel to do this and that ..


Oh i see; if i don't do a sync after dd, i might got only a portion of the data that i suppose to get..

However i am wonder why dd program itself does not tell kernel to sync (push all the relevant buffered data to the usb stick) after the dd process comes to the end ? did the dd programmer forgotten to add the last step of work into the code ?

so, next time i can just execute a "sync" command before unplug usb data storage ? How does the sync know which part of buffer to be push into persistent storage ? i don't think it will push all temperary buffer into persistent storage.. because there is no option.

Not quite. Programs don't usually tell the kernel when to write to disk; the kernel decides that for itself depending on how busy it is. Disk writes are usually carried out in quiet moments.
Yes! But you don't usually need to sync explicitly because umount does it for you.
I don't know the answer to that but I suspect that letting the kernel balance out its workload is more efficient than individual programs ordering the kernel to do writes on their behalf.
No, just unmount it. That will automatically do the sync operation for you.
Sync usually empties all the kernel output buffers. That's probably why it would be a bit antisocial for every program to demand it. I don't know what happens when you sync a particular file. There must be some way for the kernel to know which buffer is involved.

1 members found this post helpful.

People have gone to installing without answering the 32/64 bit question.

From post #1, you've a Celeron. That's a cheapskate 64bit cpu, with a 32bit data bus. In the old days, it was much cheaper to build with a half-width data bus, because all the last generation support chips which would be cheaper, and available. Some examples

• Intel's 8088 = 16bit cpu with an 8 bit data bus
• Motorola's 68008 = 16 bit cpu with 8 bit data bus.
• Celeron = 64bit cpu with 32bit data bus

So the Celeron does a 64bit load/write in 2 chunks of 32. It does a 128 bit load or write in 4 chunks of 32, so it is fully functional as a 64bit cpu - it's just a slower and crappier 64 bit cpu

I'll leave the install details to those already helping you.
32 or 64 bit OSes will work fine on a Celeron. In the bad old days when Assembler was written, one would develop a knowledge of how many cycles an instruction took to complete. These half-width cpus took much longer than the rest, and were ethically ugly, but they worked.