locate simple file system protocol failly
The code I have so far is as follows, please excuse the low quality, I’ve just been trying to get something working so far.
Saya mendapatkan konsultasi soal proses flashing BIOS pada motherboard ASUS. Seperti yang kita tahu ASUS menyediakan tool untuk proses update/flash BIOS dengan nama Easy Flash Utility, masalahnya saat dijalankan langsung gagal.
Dari pesan errornya yang muncul “Locate Simple File System protocol failly!!” ini cukup ambigu. Saya cuma bisa menebak – nebak ada hubungannya dengan USB Flashdisk yang dipasangkan dan ada sesuatu yang gagal.
Kalau anda mengalami masalah yang sama dan sedang mencari solusi untuk mengatasinya ternyata cukup mudah. Jadi dari Flashdisknya saya cek diformat pakai NTFS, iseng saja saya format ulang ke FAT32 dan dicoba lagi. Dan sukses dikenali oleh Easy Flash. Tampaknya cuma mendukung filesystem yang spesifik programnya.
Sisanya tinggal menunggu proses flashing update BIOSnya selesai. ��
Sedikit tips soal BIOS, kalau anda tidak mengalami masalah sebaiknya dibiarkan saja jangan disentuh. Karena apabila ada masalah bisa membuat motherboardnya ngebrick.
Notes on the implementation at the end of this file
Simple File System
Design and implement a simple file system (SFS). The simple file system handles a single application at any given time, it implements no user concept, does not support protection among files. Although these assumptions are quite dramatic, it leaves the file system still usable in single-tasking environments such as digital cameras and other “embedded” environments. Also, you will implement a simplified interface to the file system with notable restrictions such as: limited length filenames, limited length file extensions, no subdirectories (i.e., only a single “root” directory), few file attributes such as size and no file permissions. A library of C functions will emulate the disk system.
The SFS should implement the following application programming interface (API). The C language based API should look like the following or be a superset of the given API (i.e., should provide more functionality).
The file system should be as simple as possible. No need not implement support for hierarchy of directories. All the files will be in a single root directory.
The mksfs() — will format the virtual disk for your own file system, i.e., create necessary disk resident data structures and initialize them. The mksfs() has a fresh flag to signal that the file system should be created from scratch. If flag is false, the file system is opened from the disk (i.e., assumes that a valid file system is already there in the filesystem. This persistence is IMPORTANT so that reusing existing data or creating a new file sytem is possible.
The sfs_ls() — will list the contents of the directory in details, i.e., including the information stored in the file control blocks. The sfs_open() — opens a file and returns the index on the file descriptor table. If file does not exist, create the new file and set size to 0.
The sfs_close() — closes a file, i.e., removes the entry from the open file descriptor table.
The sfs_write() — writes length bytes of buffered data in buf onto the open file, starting from the current file pointer. This in effect increases the size of the file by “length” bytes.
A file system is somewhat different from other components because it maintains data structures in memory as well as disk! The disk data structures are important to manage the space in disk and allocate and de-allocate the disk space in an intelligent manner. Also, the disk data structures indicate where a file is allocated. This information is necessary to access the file.
Expected Return Values
The test program expects the following return values for the functions of the SFS API.
The mksfs(int fresh) function does not return any value. It initializes a new file system or reuses an existing file system. You silently ignore any errors that may happen during the initialization of a file system or while opening an existing file system. At least with this simple implementation there is very little chance of a file system getting corrupted. So we ignore that possibility.
The sfs_ls() function does not return any value. It lists the files in the main directory. Again we are ignoring the possibility of root directory corruption.
The sfs_open(char * name) function returns the value of file descriptor associated with the opened file. If the name refers to an existing file, it is opened and a file descriptor value of greater than or equal to 0 is returned. You don’t need to allocate file descriptors 0 (standard input), 1 (standard output), and 2 (standard error). Therefore, your file descriptors can start at 0. You need to return a negative value to indicate error. You will run into an error condition if the root directory is full or the file name is invalid. For example you can impose a 12-character (8.3 characters) limit on the file names. Any input that violates this condition could lead to an error condition. It is important to note that the tester is not checking this particular condition. However, it is generating 8.3 names.
The sfs_close(int fileID) function returns an integer error code. There is only one interesting condition to check whether the fileID is a valid fileID. If it is previously closed fileID, you need to return an error. You return 0 on success and non-zero on failure.
The sfs_write() function returns the number of bytes actually written to the disk. In most cases, it should be the same as the number of bytes asked to write – length.
The sfs_read() function returns the number of bytes actually read from the disk.
The disk emulator given to you provides a constant-cost disk (CCdisk). This CCdisk can be considered as an array of sectors (blocks of fixed size). You can randomly access any given sector for reading or writing. The CCdisk is implemented as a file on the actual file system. Therefore, the data you store in the CCdisk is persistent across program invocations. Let your CCdisk have N disk sectors with each sector having a size of M bytes. The disk space should be used to allocate disk data structures of the file system as well the files. On disk data structures of the file system include the root directory, free sector list, file allocation table. You can make some simplifying assumptions here and place these data structures in fixed sectors of the disk. For example, sector 0 can be the root directory, sector 1 can be the file allocation table, and sector N-1 (last sector) can be the free sector list. Within a sector you can use fixed length data structures to store control data.
Files are identified by human readable “file names.” These are strings formed by the user that conform to the file system conventions. You can make up reasonable conventions for the SFS regarding names. A directory is a table that maps these names to data block locations. The data block locations are defined by the file allocation table (FAT). Therefore, the directory entry need not specify all the data block locations. Instead, it just points to the FAT table entry that defines the data block mappings for the file. Each FAT entry specifies the location of a single data block. This means a file needs multiple FAT entries to completely specify its mapping on the disk. To implement this requirement, the FAT entries can be organized in a linked list. It is important to realize that the FAT table is implemented in disk NOT memory. Therefore, ordinary C pointers cannot be used to implement the list in FAT. Instead you should use FAT indexes.
Figure 1 shows an example set of on disk data structures for implementing the SFS. The figure shows the allocation for an example file Test.exe. In this case, the first FAT entry for Test.exe is 3. It points to data block 92, which holds the first portion of Test.exe. Suppose a data block is 1000 bytes. Bytes 0 to 999 of Test.exe will be found in data block 92. The last data block (data block 12) may not be fully populated with Test.exe’s data. This can be determined using the size attribute. The contents of Test.exe are held in blocks 92, 96, 43, and 12 (in that order). Equal sized blocks. Number of blocks fixed and equals the capacity of the disk.
Figure 1: On-disk data structures of the file system.
In addition to the on-disk data structures, we need a set of in-memory data structures to implement the file system. The in-memory data structures improve the performance of the file system by caching the on disk information in memory. Two data structures should be used in this assignment: directory table and file descriptor table(s). The directory table keeps a copy of the directory block in memory. When you want to create, delete, read, or write a file, first operation is to find the appropriate directory entry. Therefore, directory table is a highly accessed data structure and is a good candidate to keep in memory. Another data structure to cache in the memory is the free block list. See the class notes for different implementation strategies for the free block list.
Figure 2 shows an example set of in-memory data structures. The open file descriptor table(s) can be implemented in two different ways. You can have a process specific one and a system-wide one. This is more general and closely follows the UNIX implementation. You can simplify the situation and have only the table – this is reasonable because we assume that only process is accessing a file at any given time (i.e., no simultaneous access to a single file by multiple processes).
As shown in Figure 2, the entry in the file descriptor table can be used to provide some information regarding the reading and writing locations. The mandatory information is the FAT root for the file. For example in the previous example the FAT root is 3 for Test.exe. When a file is written to, the write pointer moves by the amount of bytes that is written onto the file. In SFS, the write and read pointers are the same. When a file is opened, the pointers are set to byte zero. The only way to append to a file is to read it until the end of file and then write the new data – not the most efficient way of appending! The SFS is not required to provide a seek() command to explicitly control the position of the file pointer. Please note you are required to write data in arbitrary length chunks onto the file. In addition to these data structures, we can have caching structures for FAT and directory blocks.
Figure 2: In-memory data structures for the file system.
Following are some of the main operations supported by the filesystem: creating a file, growing a file, shrinking a file, removing a file, and directory modifications.
Notes On My Implementation
Sadly, I did not have enough time to give to conclude this project. mkfs, ls, open and close are fully implemented, read is close to done, but write is giving unexpected results. I always end up with out of bound errors.
I tried to keep the api file clean by using a second h file sfs_util.h in which I stored sfs related functions.
To run the tester, you can just execute the bash file test.sh.
If you have some experience with gdb, you can also use the following command to debug the program.
Locate simple file system protocol failly asus что делать
Found this site yesterday after trying to trouble shoot and fix what looks like a MBR Rootkit issue that came with the new system. (Called support, no help other than the news of the F9 key. I don’t have the Home versions of Win7 so that was helpful.)
Background:
Unpacked and plugged in 2 days ago. Entered BIOS and shutdown everything but the SATA ports. Setup admin PW.
Booted to OS and completed install. watched cool graphics while I waited.
Was prompted to make recovery disks right away which I thought was great. By disk two it failed. Tried again, then again, and finally again. All failed by disk two. Noticed that the TrustedInstaller was still going crazy in the Task Manager. Started looking around and found registry entries and files being created, replaced, and sevices being added and locking me out.
After 2 days of chasing and trying to remove the best I could do was reach a stale mate. If I go to far it reboots the machine and then reinstalls. Won’t boot any of my virus removal disks. Infected a usbkey and my other system when trying to resolve. An old Linux boot disk shows me that the drives and usbkey now have 4 partitions each which I can’t remove unless I fubar. As soon as they go back in to be repartitioned they get re-infected. I assume anything I burn will also be infected. A second locked usbkey with AV won’t boot either, but will be read once the OS loads.
It seems this bug uses a fake floppy in the MBR and then boots off it. It’s infected the hidden partition support told me about but it gives me a few minutes after a reimage to try and get in to stop it. If it can’t use it’s own boot loader or infect another it won’t boot. (I don’t think the chips are infected or at risk but this is the newest PC I’ve had. ACPI injects the virus right away into Linux or Windows installed or run from ramdisks.
As all this happened without my using anything other than the new equipment has anyone else noticed anything like this? The apps and OS downloads I’m getting from here now, but don’t know what good they will be since the only machines I have are now infected from trouble shooting and trying to remove the bug. (So much for my AV program on the second machine.)
Failing taking it back to the store does anyone have any advice or ideas? I’ve pulled one HDD drive out of the G73JW to deal with later and to slow down any re-infection. I have one usbkey that should be uninfected. I have one MS-XP and one MS-Visa store DVDs.
Downloading tools for rootkits and stuff to try on the infected usbkey now. Just pissed off at the waste of time and hassle. Watching the bug using the trustedinstaller to undo my lock-downs and install new services is driving me nuts.
It sounds like you’ll either need to RMA it or get a copy of the factory restore discs from Asus. I didn’t have this issue on my G73JW-XA1, so it’s possible that someone at the retailer where you purchased it mucked about with the bios before you got it.
What I’d do (short of taking it back to the store) is the following:
1) Wipe out the drive using DBAN on a known good machine
2) Boot to a known good OS and flash it with the latest version of the BIOS from the ASUS website (although you said it was infecting those, so it may be a bios issue)
3) Do a clean install of the OS from the Asus discs (I doubt that was the source of the infection since my install seems to be running just fine)
4) Cross your fingers and pray that the BIOS flash, etc. worked.
5) Use DBAN to on your other machine and do a clean install of the OS there, and use a good antivirus like Eset NOD32 or Microsoft Security Essentials
IF that doesn’t work or will take far too long to accomplish, I’d probably either try the return route or RMA it to ASUS since the BIOS itself has most likely become infected (although that’s pretty rare these days).
There are still a few CMOS warheads out there, as I came across one recently. Fortunately NOD32 Firewall isolated it, and all I needed to do was reflash the BIOS.
Anyhoo, irdmoose gave some good advice. I would definitely download a Win 7 OS Install disk and burn to disc, and wipe all the partitions. I would also reflash the BIOS to current 211. Wiping the MBR block is also recommended, as you seem to have already found out. I would make a bootable CD with the tools you need, as the CD cannot get infected once it’s burned and closed.
Thanks guys. That’s pretty much what I thought. Without another PC to make my burns and ensure I have a clean source I guess RMA is the next step. What a PITA!
Is the 211 BIOS for the G73JW? I thought it was for the H when reading your other thread?
When I called ASUS support yesterday they started telling me that my issue wasn’t covered under warrenty. When I asked for a supervisor it took 15 minutes and strangely he had the same name as the first guy, Andre. (Funny, every time I was on hold it kept reminding me how great the warrenty was!)
Since my last post I have noticed a few things in the BIOS that I think are strange. The memory shows 8192MB not GB. When I start easy flash without a disk it has a message that says; «Locate Simple File System protocol failly. Please press any key to continue.»
BIOS version I have is G73Jw 203.
Version 70.06.25.00.0B.N41G73.T15
EC Version b12c1e0203
I’ll look up the AV noted above. haven’t used it for a few years as I switched to AVG.
Thread Tools
Search Thread
Display
Found this site yesterday after trying to trouble shoot and fix what looks like a MBR Rootkit issue that came with the new system. (Called support, no help other than the news of the F9 key. I don’t have the Home versions of Win7 so that was helpful.)
Background:
Unpacked and plugged in 2 days ago. Entered BIOS and shutdown everything but the SATA ports. Setup admin PW.
Booted to OS and completed install. watched cool graphics while I waited.
Was prompted to make recovery disks right away which I thought was great. By disk two it failed. Tried again, then again, and finally again. All failed by disk two. Noticed that the TrustedInstaller was still going crazy in the Task Manager. Started looking around and found registry entries and files being created, replaced, and sevices being added and locking me out.
After 2 days of chasing and trying to remove the best I could do was reach a stale mate. If I go to far it reboots the machine and then reinstalls. Won’t boot any of my virus removal disks. Infected a usbkey and my other system when trying to resolve. An old Linux boot disk shows me that the drives and usbkey now have 4 partitions each which I can’t remove unless I fubar. As soon as they go back in to be repartitioned they get re-infected. I assume anything I burn will also be infected. A second locked usbkey with AV won’t boot either, but will be read once the OS loads.
It seems this bug uses a fake floppy in the MBR and then boots off it. It’s infected the hidden partition support told me about but it gives me a few minutes after a reimage to try and get in to stop it. If it can’t use it’s own boot loader or infect another it won’t boot. (I don’t think the chips are infected or at risk but this is the newest PC I’ve had. ACPI injects the virus right away into Linux or Windows installed or run from ramdisks.
As all this happened without my using anything other than the new equipment has anyone else noticed anything like this? The apps and OS downloads I’m getting from here now, but don’t know what good they will be since the only machines I have are now infected from trouble shooting and trying to remove the bug. (So much for my AV program on the second machine.)
Failing taking it back to the store does anyone have any advice or ideas? I’ve pulled one HDD drive out of the G73JW to deal with later and to slow down any re-infection. I have one usbkey that should be uninfected. I have one MS-XP and one MS-Visa store DVDs.
Downloading tools for rootkits and stuff to try on the infected usbkey now. Just pissed off at the waste of time and hassle. Watching the bug using the trustedinstaller to undo my lock-downs and install new services is driving me nuts.
It sounds like you’ll either need to RMA it or get a copy of the factory restore discs from Asus. I didn’t have this issue on my G73JW-XA1, so it’s possible that someone at the retailer where you purchased it mucked about with the bios before you got it.
What I’d do (short of taking it back to the store) is the following:
1) Wipe out the drive using DBAN on a known good machine
2) Boot to a known good OS and flash it with the latest version of the BIOS from the ASUS website (although you said it was infecting those, so it may be a bios issue)
3) Do a clean install of the OS from the Asus discs (I doubt that was the source of the infection since my install seems to be running just fine)
4) Cross your fingers and pray that the BIOS flash, etc. worked.
5) Use DBAN to on your other machine and do a clean install of the OS there, and use a good antivirus like Eset NOD32 or Microsoft Security Essentials
IF that doesn’t work or will take far too long to accomplish, I’d probably either try the return route or RMA it to ASUS since the BIOS itself has most likely become infected (although that’s pretty rare these days).
There are still a few CMOS warheads out there, as I came across one recently. Fortunately NOD32 Firewall isolated it, and all I needed to do was reflash the BIOS.
Anyhoo, irdmoose gave some good advice. I would definitely download a Win 7 OS Install disk and burn to disc, and wipe all the partitions. I would also reflash the BIOS to current 211. Wiping the MBR block is also recommended, as you seem to have already found out. I would make a bootable CD with the tools you need, as the CD cannot get infected once it’s burned and closed.
Thanks guys. That’s pretty much what I thought. Without another PC to make my burns and ensure I have a clean source I guess RMA is the next step. What a PITA!
Is the 211 BIOS for the G73JW? I thought it was for the H when reading your other thread?
When I called ASUS support yesterday they started telling me that my issue wasn’t covered under warrenty. When I asked for a supervisor it took 15 minutes and strangely he had the same name as the first guy, Andre. (Funny, every time I was on hold it kept reminding me how great the warrenty was!)
Since my last post I have noticed a few things in the BIOS that I think are strange. The memory shows 8192MB not GB. When I start easy flash without a disk it has a message that says; «Locate Simple File System protocol failly. Please press any key to continue.»
BIOS version I have is G73Jw 203.
Version 70.06.25.00.0B.N41G73.T15
EC Version b12c1e0203
I’ll look up the AV noted above. haven’t used it for a few years as I switched to AVG.
Linux Mint Forums
Welcome to the Linux Mint forums!
ASUS-PRO P450CA-XH51
ASUS-PRO P450CA-XH51
Post by Joe2Shoe » Sun Mar 04, 2018 7:55 pm
A friend just gave me an ASUS-PRO P450CA-XH51 laptop in pristine condition, with Windoze 10 Pro 64-bit.
Intel i5 3337U 1.80GHz CPU, 6GB RAM, Crucial 250GB SSD, Intel(R) HD Graphics 4000.
Has anyone here installed LM MATE or Cinnamon 18.3 64-bit onto one of these machines?
I just can’t stand Windoze. period.
I will boot-up a LM MATE 18.3 64-bit Live USB and give it a whirl.
Many thanks for all assistance.
Re: ASUS-PRO P450CA-XH51
Post by AZgl1500 » Sun Mar 04, 2018 8:23 pm
oh yes, that is going to be a screamer!
power on to desktop in about 10 seconds.
I am typing on an ASUS TP500L and it runs 18.3 Cinnamon with only 4 gB of RAM and it don’t even blink.
Re: ASUS-PRO P450CA-XH51
Post by Joe2Shoe » Sun Mar 04, 2018 8:43 pm
Re: ASUS-PRO P450CA-XH51
Post by Joe2Shoe » Thu Mar 08, 2018 12:09 pm
Well, I finally installed LM Cinnamon 18.3 64-bit onto this laptop, and everything was nice. The friend that gave me the laptop came over and wanted to update the BIOS, but I told him to wait until I returned, as I had to go take care of some business and that I would be back in an hour. Well, long story short, he went ahead and tried to update the BIOS and bricked the laptop.
It took me 4 days to figure out how to repair the BIOS Update Utility on the mobo. What an ordeal.
Advanced/Start Easy Flash (BIOS Update Utility)
He obviously choose the wrong setting/whatever, then after pressing Enter, the update did not finish, then the machine would not reboot.
On a fresh install of LM Mate 18.3 64-bit, choosing «Something else», this message is displayed:
GRUB installation failed.
The ‘grub-efi-amd64-signed’ package failed to install into /target/.
Without the GRUB boot loader, the installed system will not boot.
Then, on reboot, this message is displayed:
error: file ‘/grub/i386-pc/normal.mod’ not found.
Entering rescue mode.
grub rescue>
All the above messages are displayed because the BIOS Utility is corrupt.
Editing Grub, numerous LiveCDs, SuperGrub2 repairs didn’t work, or whatever didn’t work, simply because the BIOS Utility on the mobo was corrupt.
It took a lot of roundabout hoopla to get the laptop back to normal again. But, it’s 100% now, and I was able to update the BIOS.
