onederer Posted July 27, 2014 Share Posted July 27, 2014 Since last week, I first lost the latest version of Mageia. I was forced to re-install the OS. I spent a lot of time setting it up again to almost the same way as the first, but lost all my personal settings, and OS settings. Well, the following morning, I turnied on the laptop, and could get nothing! I was able to backhandedly log in, but only the consoie was working. It refused to starx, or startkde. It gave me a missing magic number error. I was unable to restore that problem. I did an fsck.ext4. Again, that application also gave me the same error. It couldn't fix anything. BTW, Linux was running on an outboard USB hard drive. I couldn't even get a bad block report out ot the thing. And alt. block didn't work either. The version of Mageia is ver. 4. I didn't download it. It was an automatic distribution upgrade. Searching the Internet, provided no usable suggestions. Anyone know how to fix this? Thanks! Quote Link to comment Share on other sites More sharing options...
securitybreach Posted July 28, 2014 Share Posted July 28, 2014 It is referring to is the filesystem magic number. Boot from a liveCD and try running a fsck on the boot partition. http://www.linfo.org/magic_number.html Quote Link to comment Share on other sites More sharing options...
onederer Posted July 28, 2014 Author Share Posted July 28, 2014 Thanks for the reply. I did do that by using an older version of SUSE. It was still giving me the same error message. It was as if the hard drive was crashed. The live cd did not help. And also now, they don't use the sd** name to the drives anymore. Now it's all id numbers. Takes much longer to determine which hard drive is the bad one. From simple to complex. Why can't they leave something good alone? This is kind of early in the game, but I'm writing this unsing that SUSE OS, and installed on the same (bad) hard drive, So far so good. This time I'm only using one ext4 partition. and the other larger files, are BTRFS formatted. Don't know what caused the second wipe-out, but it seemed like a doozey. I guess that I'll live with Suse for awhile, since it is running fine, so far! As far as magic numbers, usually when one uses "fsck.ext4", the fxck application is capable of doing some repairs on these partitions. This time no matter what I was using for a command, all I got was the magic number error report. I don''t know much about magic numbers, so my odds of fixing the problem, was close to none. Even an alternate block didn't help. I had written down on a piece of paper all the related commands that I could find on the Internet, and then tried them out. I suppose that maybe some of them caused more damage? Oh well, time for rebuilding now, a new OS. Cheers! Quote Link to comment Share on other sites More sharing options...
securitybreach Posted July 28, 2014 Share Posted July 28, 2014 Well as far as the partition labels, you can run the command blkid to get the listings (may have to be root on some distros). The reason for this change was simple... Using deviceIDs makes sure that no matter the letter assigned, the label points to the right partition. For instance if you boot a livecd, sometimes your other partitions are assigned different drive letters than they normally use. Also, this tidbit is pretty neat: With UUIDs, you can give an identifier to any object in the real world. This id you give it is guaranteed to not have been used for labeling any other object in the universe so far. Guaranteed in this context means you are more likely to win the lottery without buying lottery tickets than generating a duplicate UUID. http://debuggable.co...20-6ffd4834cda3 I did not realize how unique UUIDs truly are. BTW you can still change the labels back to /dev/sd* in fstab if your are not comfortable with UUIDs. Also, you can generally just look at the first few letters and the last few letters of the string to find the match. 1 Quote Link to comment Share on other sites More sharing options...
onederer Posted July 28, 2014 Author Share Posted July 28, 2014 That command that you sent me was unknown to me. It gets me a little closer to what I needed. At least I can identify which format that matches the UUID. Now, if the current sd** would be included in this printout, we would only have to make one quick stop to match everything together. The way it is now, I can eliminate the Windows files, and the removable files. So I can concentrate on the remaining UUID's. Now, is there a command to link the UUID's with their sd** terminology? Or must the remaining UUID directories be opened to see what's inside to try to determine what's up? UUID's are fine for the machine, but hard for us humans. Even in Dolphin, they now use UUID's. This is driving me crazy! Let me know how you've figured this out. Cheers! Quote Link to comment Share on other sites More sharing options...
securitybreach Posted July 28, 2014 Share Posted July 28, 2014 Do you mean matching the uid with the partition mount point? If so, you can type the command mount to list the partitions and their mount points (if they are already mounted) and then blkid to match the uid to partition. I knows its a work around but I am searching for another method. Quote Link to comment Share on other sites More sharing options...
securitybreach Posted July 28, 2014 Share Posted July 28, 2014 Try as root, blkid -o list Although, I do not know why it wraps around the UID to the next line. 1 Quote Link to comment Share on other sites More sharing options...
securitybreach Posted July 28, 2014 Share Posted July 28, 2014 There are some useful switches that you can use for specific partitions: http://linux.die.net/man/8/blkid or run man blkid Quote Link to comment Share on other sites More sharing options...
onederer Posted July 29, 2014 Author Share Posted July 29, 2014 Thanks! New commands to add to my collection. 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.