Thank you again Lennart, this ignorant mainframer is slowly being dragged kicking and screaming into the modern age. 1. Linux (the whole thing, not the kernal) should handle random hardware as well as any major competitors, at least windows, android, MacOS, and maybe gaming consoles. Any commodity devices sold at retail should just work as well as on the competitors. I realize actual new hardware devices are sold with proprietary binary only drivers in not all operating systems, so this is a "best effort". However, disk drives, spinning or solid state that are formatted (and hence could be filled with data by the purchaser) for one operating system, should be readable on Linux. If some niche company takes an m2 disk and packages it to look like some specialty device, say amiga, that does NOT need to be supported. aside: huh? so many variations on mbr, including one with 12 extended partitions? Is there a list of which operating systems (with what years they were active) AND which are supported by the most common current ones? https://en.wikipedia.org/wiki/Master_boot_record this is also interesting (don't recall even hearing of midnightbsd before) https://en.wikipedia.org/wiki/GUID_Partition_Table and i notice other OSes previously covered in this thread are not listed (are they all MBR only?). Some reading for me in the future, much is still beyond my comprehension. and I guess I missed something, because this page says there can be up to 23 extended partitions: https://www.freecodecamp.org/news/mbr-vs-gpt-whats-the-difference-between-an... If windows and/or MacOS, with a default install, will access an amiga filesysystem, then linux should. Since an exFAT disk without a partition table will "just work", on windows, it "should" on linux too. other than that, including a disk without a partition table but a filesytem that would work if it was in a partition table, a warning of non-blank is sufficient. and yes, I was not paying attention to the details of gparted vs other tools. I have a very poor memory for specific names (partly why I was good at assembler, the instruction names are mnemonic and follow simple patterns). I remember when, trying to install dual boot, since the top level directory and other files marked "unmoveable" and in the middle of the partition, you could only shrink windows partitions down to a little over half their original size. Then I think the linux tools got smarter, and the windows partitions could be shrunk to the minimum size needed for the os. Would it be possible for that shrinking program, or some new program, to insert a partition table in before an existing filesystem on a disk without any partition table? to this ignorant-of-the-internals person, it seems like one should be able to: --do disk "defragging/compaction" if any files are near either extreme of the filesystem --lop off the end of the filesystem to make room, for primary and backup gpts --move everything up enough to add the partition table (worst case) --or adjust block numbers in directory to account for changing origin ** --build the partition table --invoke current process for moving data from old center to new smaller center hopefully combine the steps so data is not moved more than once. ** do FILES as opposed to directories, contain absolute block numbers of other parts of the file? note that *I* do not need this, I caught this before I put anything of mine on the disks, so I can wipe them clean and start fresh, I am just thinking about the other guy who knows far less than me, and who might get pissed and decide to just stay with windows instead of converting to linux. <pre>--Carey</pre>

On 10/26/2024 10:35 PM CDT Lennart Sorensen <lsorense@csclub.uwaterloo.ca mailto:lsorense@csclub.uwaterloo.ca> wrote:

On Fri, Oct 25, 2024 at 02:59:48AM -0500, CAREY SCHUG wrote:

...

Your response is helpful Lennart, and this ignorant ex-mainframer even believes he understands. Thank you.

...

...

Will linux access an amiga filesystem? Willow? Netware? CP/M? I suspect the number of filesystems a running LINUX can actually access is small enough that adding code to recognize them without a partition table entry is reasonable.

To a large extent the answer is that yes it can. For example:

mythtv64:~/gp# find /lib/modules/6.11.2-amd64/kernel/fs/affs//lib/modules/6.11.2-amd64/kernel/fs/affs//lib/modules/6.11.2-amd64/kernel/fs/affs/affs.ko.xz mythtv64:~/gp# modinfo affs filename: /lib/modules/6.11.2-amd64/kernel/fs/affs/affs.ko.xz license: GPL description: Amiga filesystem support for Linux

I think warning about not blank is enough. You can then go use file to check what it contains and get much better results from a tool designed and maintained for exactly the purpose of identifying things.

But certainly you could expect to encounter a drive without partitions with some file system (NTFS, exFAT, FAT or even HFS+) or a partition table, usually MBR or GPT (since the mac has used GPT for years now ever since moving to x86 and not ARM processors). Hitting a partition table from Amiga or BSD or AIX or something else is highly unlikely.

...

...

And ... I would hope WE could be one (or two, or three) better then Microsoft.

In practical terms, I am not going to walk into Microcenter and buy a spinning/solid state/usb drive with an Amiga file-system on it. A new and easy to acquire drive will contain --a partition table that identifies the file-systems on it) --absolutely nothing (added in this reply) --an empty partition table --APFS (probably with a partition table) (added in this reply) --EXT4 or maybe one of a short list

the last two if removed from a computer with that OS installed, where I replaced the disk with a larger one and want to repurpose the original, but I suspect ONLY with a partition table (revised here).

Will an "absolutely empty" disk contain all zeros, or some random bit pattern from QA testing? how much testing is done of disks when manufactured? is there a universal, or one of several common "worst case" bit patterns used for testing, so that they would not be confused with a totally empty disk?

What if it contains an MBR and a GPT partition table? They are not in the same sector locations by design. What if it has GPT but the two copies are not in sync?

warning of which of the above problems should be sufficient, with wording to enable a web search to find suggested next steps. i.e. just "there may be data on this disk" is not enough for a non linux sysadmin.

...

And once I have defined partitions, gparted and/or the linux install process WILL format it at least in linux and (some?) microsoft formats, so it DOES understand them. I have never tried formatting a partition for amiga with gparted... but if so, might that be useful for running an amiga emulator?

Since apparently disks with one of a few microsoft filesystems are "common", I think it is reasonable for both Linux AND gparted to recognize them.

If I have pulled a disk out of some other computer, I should be expected to have the knowledge of how to check for a filesystem in THAT format.

another aside, just out of curiosity: If I find a mainframe storage array (in a dumpster, or "fell off a truck") made from commodity disks, do they have one of the two partition tables, and a filesystem we might know about, or just some hidden binary that only the mainframe controller knows about?

Of course parted is far from the only partitioning tool on linux. It is certainly NOT the one I would pick to use if partitioning a drive. cfdisk is so much more pleasant to work with.

I will use gparted if I need to resize partitions on a drive though. About the only think I will consider using it for.

Disk partitioning is a somewhat complicated thing, although at least on modern machines it is much much nicer than the insanity you used to have to do on Solaris or IRIX or those other old unix systems where you had to tell it the drive geometry and then create disk labels all manually.

-- Len Sorensen

--Carey