I have no idea what you mean with “command line consequences”. But I know one can destroy things with a GUI program as good as with a CLI command. Specialy when that GUI program is running owned by root. Which btw any system installer is doing.
For this I think nobody here can do anything else then suggesting more or less wild guesses. Everything that happened on your system that is done by the system administrator is done by you personally I guess. You are installing one distro after the other, maybe one over the other and nobody here can check what you did. And yes, a miss-click during an installation can create a file system over another file system when you did not realy want it. As long as you can not show a screen capuring movie of all you did we can not comment other then in generalities.
BTW, about what is on /dev/sda7. It can be that I missed something in this long and confusing thread, but I have seen in post #30 that it seemlingly mounts (no errors there), that then there is nothing (not even a lost+found directory), but I did not see what the system thinks about the file system type there (of course when it is mounted again somewhere):
What has sometimes happened here, is that I have inadvertently selected some text in one window, and then pasted it to a command line window. And the pasted commands can cause damage as well as generate errors.
The biggest risk is when the pasted text contains characters such as “>” which can redirect output to an unintended place. Because of that, I try to avoid shell meta-characters in my standard shell prompt.
I anticipate that there will be mistakes, and I try to be very awake when I run installs . . . and I am aware that most often “pilot error” is at work . . . this situation is pretty “irregular” . . . . Haven’t found the time to get over to Gecko “forum” but I will report the situation over there, as I did start another thread around a Gecko problem that warranted my re-install of the OS . . . that may or may not have led to the “sda7” problem . . . .
Thanks for following along in spite of the confusion . . . I’m over in Lu 20.04 right now and I ran that command with “sudo” and then as “sudo -i” and that brought zero data, just the blinking cursor line waiting for my next command of consequence . . . .
Got it. For the most part I’m not doing much of complication in the terminal, other than running zypper updates, or apt, or pacman . . . not really ad-libbing in the terminal . . . almost never use “>” . . . .
Obviously something 'went wrong" and as the “operator” I have to accept the consequences . . . I accept that the data is gone . . . almost totally gone . . . . I’d just like to “share” the responsibility with a third party, or second party . . . someone or thing, like the Calamares installer . . . . : - ))))))))
Just by paging through the raw string salad, you may recognize some boot-manager messages, familiar strings embedded in executables, JPEG/JFIF/MP3 comments and other binaries, file names, directory names, even text-file or spreadsheet contents you typed and saved away recently. Searching for unique user names, real-life names, project names, website addresses etc., could be worthwhile too. (In order to search while in the less pager, just hit »/« and then enter the search term; hit »n« for next find, spacebar for next screenful, etc.)
Maybe you can get a rough overview about the history of your sdb7 partition that way, and reconstruct which type of newer data may have overwritten which type of older data. Next steps could involve booting specialized CD-based forensics distros like Kali Linux and have them recover any valid file data by header- or magic-number matching. I wrote a Jpeg-undelete tool years ago for myself, and I’ve used the tool foremost a couple of times.
Also, read through all shell-history files you can get your hands on (root + standard users, Mac + Linux) — this usually jogs my memory about what I did, and where (and why, if I’m lucky), way back when:
sudo less /root/.bash_history
sudo less /root/.history # for csh
sudo less /root/.hist# for any other non-bash root shells
cat ~/.history | less
sudo cat /home/other-linux-user/.history | less
sudo cat /Users/other-macos-user/.*history | less
(Newer macOS Terminal programs save their console sessions differently, so merely looking through shell-history files may be moot there.)
Maybe journalctl (Linux) and the macOS tool »/Applications/Utilities/Console.app« let you go back far enough to where things went wrong with sdb7.
Finally, and to exclude hardware faults, check the SMART status of the device:
sudo smartctl -a /dev/sdb # Linux
/Applications/Utilities/Disk Utility.app *# macOS; I think both devices (sdb) and partitions (sdb7) can be checked and verified — repaired, even, if you’re lucky *
Thanks for stopping by as well, I checked the link to the YT page . . . just showed all of his YT videos, any particular one you were referring to? At the top was a three hour vid on “How to build your own computer”???
Alrighty, thanks for the suggestions, I did try to run your command and it brought back a “few” strings . . . I scrolled down a bit, and there was more strings . . . then I hit the arrow key and it just kept scrolling . . . and then down around number 3676 . . . buried in with some other data was the line . . . “April 1 is a very serious day for console humor” . . . except here in the US . . . April 1 is tomorrow . . . ??? : - ))
So, OK, not sure if that was something that might really “show” something . . . buried in with the thousands of strings . . . possibly your other suggestions might be valid . . . for me the time spent looking through literally thousands of strings is . . . futile??? I would need something that would get me more concise analysis of what happened to a system . . . that might indeed be worth the time. I do have both OSX and linux OSs . . . can’t exactly say that the GUI tools that OSX provides are “robust” . . . .
So, as we speak the sdb7 partition is being erased and re-layered with zeros . . . to prepare for a re-install of something, likely some form of Manjaro . . . . So I won’t be able to run any other April 1 commands on that partition . . . . Probably more or less wraps it up on this thread???
Uncle Carey does an excellent job when demonstrating efficient problem solving, As he only performs streamlined Windows 10 installs from scratch there are few problems with software. Some samples:
Software is different. But the strategy for solving software problems is the same as for hardware.
I take your reply to be itself an April fool’s joke — because otherwise, lacking any further insight, you may well be bound to repeat your errors that lead you onto your path to corrupted data the first time around.
Sincerely, best of luck!
OK homie . . . perhaps you were “serious” . . . about discovering relevant messages in over 3700 lines of micro-data . . . ??? And, indeed, the reason for posting this thread was to try to get some hints on possibly figuring out what went wrong and where . . . to try to prevent repetition of possible errors.
Possibly all of the options you provided might have actually done that, but, by the time you posted the rest of the crew had already stated several times, “really difficult to actually know” . . . based upon the infinite possibilities of “errant mouse clicks” that might have contributed . . . or some “glitch” in the Calamares installer, which I believe there have been some posts here, and I experienced said “glitches” in the OpenSUSE installer back in the Fall . . . and so I had “moved on.” My apologies to your effort to help out.
One of my mottos is, “If it’s working, it’s working . . . and if it isn’t working, then . . . it isn’t working . . .” as a philosophical commentary on life, trickled down to linux software. Simply, sdb7 was “no longer working.” Full stop. Likely we won’t know why . . . possibly for ever, or something might show up when I run the next install process . . . . I’ll post back if there are some more gory details, and then we could run through the 5K strings of “lessened” data . . . ???
So I ran my install of Manjaro XFCE back into sdb7 . . . trying as an experiment the mrmazda advice to NOT select an EFI partition for flagging the bootloader, and I did get the, “Hey, you didn’t select a partition for loading the boot” error . . . and I moved forward, install went fast.
So, I figured on reboot that the new install wouldn’t boot, so I went to TW Yast Bootloader and there only TW was listed?? so I clicked “OK” and it ran through it’s what “initrd” process . . . on reboot, nothing was there in the “main grub” . . . . Then I think I went into Gecko and did the same thing, no change. So then I booted Manjaro via SG2 and ran a large package upgrade and also ran “update-grub” . . . while I was there I set up the preferences, but seemingly wasn’t getting itself into grub.
Then I think I went to Lubuntu 20 and ran “update-grub” . . . ?? so there “Manjaro” actually showed up in the process, but still I don’t think that got it, shut it down for the night. This AM I booted up U-MATE 20 and again ran “update-grub” and then rebooted into the main EFI boot disk via OSX Boot manager . . . and finally “Manjaro” was listed and I selected it, has same error that all listings do, “No video found, booting in blind mode” . . . but it Booted into Manjaro!!!
So, is this what is meant by “os-prober”?? I tried to run that basic command in possibly one of the TW installs and it errored out . . .
Is this where I should have run #grub-mkconfig -o /boot/grub/grub.cfg in Manjaro when I first booted it with SG2 disk? Or, just running update-grub in the various other players is the way to get it on the list w/o adding more junk into the EFI partitions? Or. this added junk anyway, just in a different way that using the installer???
Hi
The Tumbleweed os-prober program should find them all, if not raise a bug report. Now in your case it’s a IMHO a unique setup, but that should not matter.
Thanks for the reply . . . well, the “problem” with the Yast Bootloader GUI app, is that it doesn’t seem to show the list of things it’s found??? It runs through it’s progress bar and then disappears itself. And didn’t seem to transfer it over to the “main grub” . . . master grub listing so that it could be booted. Is there a way to run “update-grub” in a console that would show the “findings” so that they would be “boot-able”???
But, yes, somewhat “unique” . . . ordinarily I flag the “sdb1” partition for the “efi/bootloader” and then apparently that gets put in sda1 & sdc1 as well??? And then for the three EFI (ESP) only one of them show all of the options . . . which it now does . . . possibly from the ubuntu “os-prober” that gets run with the “update-grub” command???
Anyway, for now again all 5 of the linux installs are accessible via “grub” . . . “main grub” . . . .
Well, thanks for the thought, but that would be a temporary change, one that would again change if the flashdrive was removed . . . but if you read through the thread you could see that “no flashdrives were harmed” and the data in sdb7 was entirely gone, not just renamed . . . or mis-labeled, but removed.
