Puppy Linux Discussion Forum

Having a recent ubuntu based puppy is a good option I think.

Personally, I've already decided that my daily driver will be f96-6 after bionicpup64 (one way or the other).

It would certainly be a shame about all the work, so I'm in favor of option 3.

I think it's important to think about the drv constructions before jammy64.

I can't estimate how many users would actually appreciate the function of an "extended save file".
I personally like the idea of having selected programs in the ydrv and using the adrv with smaller personal settings as a save file replacement.

@rockedge

Option 3 = Use F96 as is and begin to create the Jammy recipe. Create differently constructed adrv,bdrv and ydrv combinations.

This should be the choice. Quite frankly, I don't think regular users care how a Puppy is made. They only care about what it is and what it can do.

From puppylinux.com:

There are generally three broad categories of Puppy Linux distributions:

* official Puppy Linux distributions → maintained by Puppy Linux team, usually targeted for general purpose, and generally built using Puppy Linux system builder (called Woof-CE).

* woof-built Puppy Linux distributions → developed to suit specific needs and appearances, also targeted for general purpose, and built using Puppy Linux system builder (called Woof-CE) with some additional or modified packages.

* unofficial derivatives (“puplets”) → are usually remasters (or remasters of remasters), made and maintained by Puppy Linux enthusiasts, usually targeted for specific purposes.

F96 falls at least in the second category and is a fine example of a general purpose Pup with broad appeal. It can and will attract new users.

Here in the U.S. we have the saying

A bird in the hand is worth two in the bush

F96 is a "bird in the hand"

wizard

amethyst wrote: Tue Jan 03, 2023 5:10 pm

who decided what the use/function of this "new" bdrv should be and where it should rank in preference?

Me. Contributions to woof-CE which change this order are welcome. As long as I have a way to build a Puppy with apt, I'm good, and I don't mind how this SFS is called.

amethyst wrote: Tue Jan 03, 2023 5:10 pm

Remember that although a bdrv has not officially been part of Puppy, some of us have been using an adapted init for ages which already has a bdrv and other addition drives like cdrv, ddrv, etc. envoked and in use.

Does this mean that woof-CE is frozen and must not change to make room for new features like apt support?

And if you use a custom init, why are you so upset about the behavior of the default one?

Hello everybody:

Can you put (please) an image of system info?

Can you put an image of the wallpaper ? (a Youtube video of u using it would be marvellous)

THAKS A LOT IN ADVANCE.

Exactly for the reasons being raised over and over. This new order and functions of the additional the bdrv is confusing a lot of people. But since this is a given and decided upon already I'm not going to participate in this debate further. Got better things to do.

Why not integrate those init mods into woof-CE, so the next "official" Puppy doesn't need this customization and this constant struggle with the *drv*.sfs nonsense?

I have only recently installed F96_4-radky6-CE. I have already found it to be both polished and pretty fast on the fairly limited hardware I have. As a mere user of puppy linux I must admit that I find these alphabet .sfs confusing but accept to a point that they allow a level of modularisation.

@rockedge suggested the following options

Option 1 = Completely abandon F96 then rebuild the Fossapup64 from scratch with woof-CE right now and leave it as is or remaster this again with manual additions and configurations. To use the newer RAM usage protocols.

Option 2 = Completely abandon F96 and focus on a woof-CE recipe for a polished and complete Jammy64-CE

Option 3 = Use F96 as is and begin to create the Jammy recipe. Create differently constructed adrv,bdrv and ydrv combinations.

Option 4 = Abandon F96 and work on KLV and KLA.

Three out of four of these suggest the abandonment of F96. However, I think it would be an act of madness to abandon F96 after the time effort and expertise that has been put into it. Can I suggest that option 3 should be the way forward with the addition that if there are any areas that need a tidy up that this should be done provided it does not create a massive workload for those involved. It should then be issued as another version of puppy linux. Frankly I don't care whether it's called an update, upgrade, remaster or whatever. I do think that members of the community should be given the opportunity to try it and decide for themselves whether it's a keeper. For me I think it already is a keeper. I think these threads are understandably populated by posts from experts. I do not normally post in such threads but I think on this issue it's time for those who have little expertise but simply like using puppy linux, often on what might be called limited hardware should have a say.
The above is my two pence worth.

Regards,

Ken.

I'd like for option 3 to go forward.

amethyst wrote: Tue Jan 03, 2023 5:53 pm

Exactly for the reasons being raised over and over. This new order and functions of the additional the bdrv is confusing a lot of people. But since this is a given and decided upon already I'm not going to participate in this debate further. Got better things to do.

Sorry I put the bdrv actually in place. It's going to get whacked and removed, forgettabout it. Of course the mechanism will remain in place but the bdrv can be easily removed and no one will be confused by it's use. I see at least as confusing as using the adrv-ydrv save file concepts are.

Like I will write again, if anyone has something better lets see it in operation.

I found that Pkg2-cli elaborated on here -> viewtopic.php?t=5367 should be installed and replace the current version.

Errors occurred beginning with a repo-update using the original sc0ttman version. Once I installed the Pkg-2.0.9.pet it worked as expected.
Again I will run 2 scripts that use pkg to install Zoneminder using the built in Hiawatha web server and installs PHP7.4+ with a mariadb-server for the database. This is a pretty good test of using pkg.

We will insert and install Pkg2 into the next F96_5-radky6-CE

I am going to try this and see how it works.

What I would do is change the name of the ydrv.sfs to adrv.sfs, it basically has in it what would normally be in the adrv.sfs.
so the stuff in it is provided the correct way for the layering of the filesystem and the loading of stuff into RAM.

As it is presently setup.
There is no adrv.sfs that would override what is in the ydrv.sfs, so the ydrv.sfs is doing basically what the adrv.sfs is suppose to do.

Except for one thing:

adrv...sfs: It overrides the contents of all other sfs files.

Also consider this statement:
ydrv...sfs: It can be used to override the contents of puppy...sfs.
The puppy....sfs is the only one it is suppose to be able to override.
Look again at what adrv.sfs can override.

Again when a drv.sfs is layered into the filesystem and what is in it is important.

But if a file exists in more than one layer the one in the top-most layer is the one that is seen.
So the order of layers is significant.

* Init creates a stack containing only a directory in a RAM based tmpfs as the read-write layer.
* It then appends the puppy...sfs to this stack.
* It then processes the other sfs files, if they exist.
* It appends the fdrv...sfs.
* It appends the zdrv...sfs.
* It inserts the ydrv...sfs immediately below the read-write layer.
* It inserts the adrv...sfs immediately below the read-write layer.
* If all files are present we end up with a stack that looks like this:
tmpfs read-write
adrv...sfs read-only
ydrv...sfs read-only
puppy...sfs read-only
fdrv...sfs read-only
zdrv...sfs read-only

Changed ydrv.sfs to adrv.sfs in a frugal install of F96_4-radky6-CE.

This is first boot running in pupmode 5.

Posting from it now.

So far it all seems to be working OK.

When the boot process was loading the different sfs files.
adrv.sfs was the last one to load.

Layered filesystem stack is this:

adrv_fossapup64_9.6.sfs
bdrv_fossapup64_9.6.sfs
fdrv_fossapup64_9.6.sfs
puppy_fossapup64_9.6.sfs
zdrv_fossapup64_9.6.sfs

rockedge wrote: Tue Jan 03, 2023 4:20 pm

... a monolithic root_fs with everything in it other than a browser and ...

I think you'd want a browser (developer's choice) in the monolithic. This insure a PUP that can stand on its monolith vs ANY need for the additional Xdrv's that may be present.

rockedge wrote:

Option 1 = Completely abandon F96 then rebuild the Fossapup64 from scratch with woof-CE right now and leave it as is or remaster this again with manual additions and configurations. To use the newer RAM usage protocols.

Option 2 = Completely abandon F96 and focus on a woof-CE recipe for a polished and complete Jammy64-CE

Option 3 = Use F96 as is and begin to create the Jammy recipe. Create differently constructed adrv,bdrv and ydrv combinations.

Option 4 = Abandon F96 and work on KLV and KLA.

I think either Options 3 or 4 is an excellent choice. As suggested, already, since @peebee is supporting 32bit users, the focus 'should' be on 64bit PC as the world is giving these 17year-old things away for free in dumpsters and even PC shops. There are only so many hours in a developer's day that he would devote any time at all on PCs that are over 2 decades old...unless, of course, he/she chooses.

rockedge wrote: Tue Jan 03, 2023 7:00 pm

I'd like for option 3 to go forward.

amethyst wrote: Tue Jan 03, 2023 5:53 pm

Exactly for the reasons being raised over and over. This new order and functions of the additional the bdrv is confusing a lot of people. But since this is a given and decided upon already I'm not going to participate in this debate further. Got better things to do.

Sorry I put the bdrv actually in place. It's going to get whacked and removed, forgettabout it. Of course the mechanism will remain in place but the bdrv can be easily removed and no one will be confused by it's use. I see at least as confusing as using the adrv-ydrv save file concepts are.

Like I will write again, if anyone has something better lets see it in operation.

I'll just make a few more points and suggestions (for what it's worth) on this and then step away from this discussion:
1. There is absolutely nothing wrong with having additional drives AVAILABLE , in fact the more the better. It only holds advantages especially in terms of "modularity" and running a system in RAM only. Just think how useful this could be when you have lots of RAM. And if more additional drives were envoked, many of these issues would not even needed discussion.
2. Now, we are used to having the adrv and ydrv available (first the adrv was made available and later followed by the ydrv). In most scenarios these were not used/included in the iso. Some used its availability to load things in preference to the base sfs which can be useful. So for these users there were a certain ranking system in order with these drives, ie, adrv,ydrv,base sfs, The adrv having the highest priority for additional drives directly followed by the ydrv. This is what user were used to and even a few applications were produced with this specific order in mind. More additional drives (like the bdrv) is/are now available. Is it really unreasonable to expect that these additional drives should follow the adrv and then the ydrv in ranking order of preference (like we are used to)? I think it's reasonable and logical to keep it that way (and less confusing for users who have used the functionality of these additional drives before). Personally, I use the adrv/ydrv to save system configuration changes, my bdrv for glibc upgrade, cdrv for gtk improvements and so on. My suggestion is that the adrv and ydrv retain the order of ranking, ie. adrv directly followed by the ydrv and I suggest that these two drives are not used in the distribution iso.
3. Since the Puppy OS is basically a read-only system packed in a compressed archiving format a few things are important as far as system performance is concerned, I'll mention a few:
- at bootup, the default action is to copy the Puppy base sfs and other additional drives to RAM. I haven't checked but is the most efficient method for copying in place here? I can think of speed of copying. For example: if cp is used, rsync may be faster.
- it will be great if one could choose at bootup which additional drives to load (btw, additional drives can have personalised names, like cdrv_Firefox for identifying purposes). Especially important if we go the modular route.
- since we are working with sfs files which have to be decompressed to access the contents, the best decompression ratio should be implemented. dimkr suggested zstd and I agree with this (good compression ratio and fastest decompression). Definitely should be used for newer machines, don't know with lower end machines as far as memory consumption is concerned. The tried and tested gzip may be better for older machines (compression still and decompression still good).
And so on....

Why not just change the init script so it auto-loads SFSs named 00whatever.sfs, 01whatever2.sfs, etc' under PSUBDIR or the root, in numeric order? I'm currently testing such a change and I think this should do.

dimkr wrote: Wed Jan 04, 2023 6:16 am

Why not just change the init script so it auto-loads SFSs named 00whatever.sfs, 01whatever2.sfs, etc' under PSUBDIR or the root, in numeric order? I'm currently testing such a change and I think this should do.

I was thinking about a list or something where the user can choose during the boot stage.

Like EXTRASFSLIST in /etc/rc.d/BOOTCONFIG?

EDIT: I can add support for a extrasfslist= boot code, if that helps

dimkr wrote: Wed Jan 04, 2023 7:02 am

Like EXTRASFSLIST in /etc/rc.d/BOOTCONFIG?

EDIT: I can add support for a extrasfslist= boot code, if that helps

So basically the system searches for the additional drives (which should be in the folder with the other Puppy files) > list it at bootup so that the user can choose from a list which to load. The method how to do it does not matter as long we can achieve the result. Haven't looked myself, just a suggestion at this stage. I think it will be valuable - a total modular system running in RAM only > lots of additional drives to choose which to load. I think a few users will be interested operating like this. Yes, loading extra sfs files will obviously be useful in this situation too. The thing is how to make this the most efficient without having to spend too much time choosing at boot time. Now one can save this configuration for future boots but then a user option to be able to quickly change at boot time.

Quickpet program

The Nvidia drivers that are provided in Quickpet->Drivers

These drivers are not going to work.
They are compiled for the kernel 5.4.53 that is in Fossapup64 9.5

To work they need to be compiled for the kernel 6.0.12 that is in this F96_4-radky6-CE

Nvidia drivers are kernel specific and only work with the kernel they were compiled for.

I do not know why it is so hard for people to understand this.

What is specifically in each drv.sfs, when that drv.sfs is loaded into memory and the operating filesystem, is important to the overall operation of the computer.

Again this is specifically what should be in the specific drv.sfs's

puppy...sfs:
This is the main Puppy file, containing most, if not all, the software that is in the current Puppy.
This is the only sfs file that is required, if the init script cannot load it for any reason, the boot is abandoned.

zdrv...sfs:
This contains kernel modules(device drivers), and firmware files matching the kernel in vmlinuz.
Without this file, Puppy will usually still boot, but some devices will either not work or not work properly.

fdrv...sfs:
This contains firmware files. It can be used to override the contents of zdrv...sfs.

bdrv...sfs:
This contains a basic installation or skeleton of the compatible distro.
With this file, more binary packages from the compatible distro repos are likely to work.

ydrv...sfs:
Notionally a patch file. It can be used to override the contents of puppy...sfs.

adrv...sfs:
Notionally an application file. It overrides the contents of all other sfs files.

Maybe this will make it clearer.

The computer starts booting and the Linux kernel starts taking over control of the computer hardware using drivers and firmware specific to the hardware.
Vmlinuz the kernel with zdrv.sfs, fdrv.sfs provide the software.

Then the Puppy operating system is loaded into memory.
puppy....sfs provides this.

Then anything else for software programs are provided by bdrv.sfs, ydrv.sfs, adrv.sfs, etc.........
But these are suppose to be used for specific types of software.
The order they load into RAM is considering the type of software that they should be providing and when it should actually get loaded.
If any two of these drv.sfs has any of the exact same files.
What is in the first one to get loaded, is going to get replaced by what is in the next one loaded, and so on.

However, adrv.sfs as the final drv.sfs to be loaded into memory.
Everything that is in it, will replace anything that is the same, that was already loaded form another sfs.

When a save file/folder is made and being used.
Anything in it, will replace anything that is the same, that is provided by one of the drv.sfs's and the puppy....sfs

So as Puppy boots.
It loads in this order:
vmlinuz.
zdrv.sfs
puppy........sfs
fdrv.sfs
bdrv.sfs
ydrv.sfs
adrv.sfs
puppy save

When completed the filesystem layered stack is this:
puppy save
adrv.sfs
ydrv.sfs
brdv.sfs
fdrv.sfs
puppy...sfs
zdrv.sfs

@rockedge

Must be list of installed stuff from what you did with Puppy Package Manager.

I have done nothing using PPM.

But it has a long list in the uninstall of stuff to select to uninstall.
.

When completed the filesystem layered stack is this:
puppy save
adrv.sfs
ydrv.sfs
brdv.sfs
fdrv.sfs
puppy...sfs
zdrv.sfs

Not with this Puppy or dimkr's work as I understand it. In this Puppy the bdrv takes preference over the ydrv (in the layer as you put it). If I understand correctly, dimkr even stated that in his Puppy's the bdrv even has preference to the adrv. This is what most of the debate was about, ie. the bdrv having preference to the ydrv and in dimkr's case even the adrv. The suggestion was to keep the adrv and then the ydrv at the top of the layered stack for additional drives because that is what users are used to. Simples. Also - not all of us use a save file / folder but we still want to save our changes which may include and likely will also include changes to the system configuration. The adrv is obviously to be used in this instance as it replaces the save file/'folder. I find it hard that some don't understand this.

dimkr wrote: Wed Jan 04, 2023 6:16 am

Why not just change the init script so it auto-loads SFSs named 00whatever.sfs, 01whatever2.sfs, etc' under PSUBDIR or the root, in numeric order? I'm currently testing such a change and I think this should do.

This is already a mechanism in KLV and Firstrib and allows 0-99 as the prefix. @wiak 's initrd uses the format : XXsome_squash.sfs

With f96_4-radky6-CE I get the following result:
puppy save
adrv.sfs
brdv.sfs
ydrv.sfs
puppy...sfs
fdrv.sfs
zdrv.sfs

What I did: I wrote text files in each sfs and checked which ones remain visible.
In zdrv T1 to T6, in fdrv T1 to T5, Base T1 to T4, ydrv T1 to T3, bdrv T1 to T2, adrv T1
After starting, T1 to T6 were present.

I'm wondering, is the init-script actually Puppy version specific or dependent on the timing of changes in Woof-CE?

If pup version specific, then maybe ranking bdrv behind ydrv would be the easiest solution for this time?
If I understand correctly, would everything work as before without any other changes?

Does https://github.com/puppylinux-woof-CE/woof-CE/pull/3808 solve the issue?

In terms of the preference order of the additional drives. I have just checked the init I'm using and which I have adapted a long time ago to add a lot of additional drives. The bdrv in this one is also higher in ranking order as the ydrv. I've never noticed this before because I never used the ydrv and bdrv together. So, I suppose it's a matter of how you adapt the init to add new additional drives. However, it does seem as if the ydrv was intended to be just one level up in ranking order (above) the base sfs. But since we only had an adrv and ydrv back then this was not an issue as the adrv clearly was intended to have top priority after the save file.

The intended purpose of bdrv is "The intended use of bdrv is to contain delicate things like apt and Synaptic. They're isolated from the main SFS to make them removable, and placed above adrv and ydrv so they can't break the package manager." viewtopic.php?p=77499#p77499. So long as it is only used for such purpose its content will not over-write the contents of ydrv in the 'merge-in-RAM' file-system. It's stacking order doesn't matter.

Changes to the lower ranking ydrv will still be effective unless there is insufficient RAM into which both the ydrv and the bdrv can be copied. However, if fr-ke's examination is correct, viewtopic.php?p=77570#p77570 the logic is faulty. Far more important than to having a functioning apt or synaptic is being able to get on line to use them. And if adrv has higher priority than bdrv, there remains the potential that the content of adrv will interfere with the functionality of bdrv.

I mentioned this before and now I've found it, technosaurus' firmware-cutter, https://oldforum.puppylinux.com/viewtop ... a8#p383851 which, despite its name, also can remove unneeded drivers. Does this function under recent Puppys, particularly F96? Shouldn't a functional version be 'built-in' to the core/base.sfs?

Sorry, have to break off here. Will get back hoping other have had the opportunity to consider the ramifications of the above.

fr-ke wrote: Wed Jan 04, 2023 12:40 pm

With f96_4-radky6-CE I get the following result:
puppy save
adrv.sfs
brdv.sfs
ydrv.sfs
puppy...sfs
fdrv.sfs
zdrv.sfs

What I did: I wrote text files in each sfs and checked which ones remain visible.
In zdrv T1 to T6, in fdrv T1 to T5, Base T1 to T4, ydrv T1 to T3, bdrv T1 to T2, adrv T1
After starting, T1 to T6 were present.

I'm wondering, is the init-script actually Puppy version specific or dependent on the timing of changes in Woof-CE?

If pup version specific, then maybe ranking bdrv behind ydrv would be the easiest solution for this time?
If I understand correctly, would everything work as before without any other changes?

I'm wondering, is the init-script actually Puppy version specific or dependent on the timing of changes in Woof-CE?

If the Puppy version is being built with Woof-CE.
I would think the init-script in Woof-CE, at the time of the build, would be used.
1 hour later that init-script in Woof-CE could be changed, modified, edited, and now it would be different, from the one used in the build.

This is what it shows in my install with no ydrv.sfs
I made the ydrv an adrv and have no ydrv.
Layered filesystem stack is this:

fossapup64save
adrv_fossapup64_9.6.sfs
bdrv_fossapup64_9.6.sfs
fdrv_fossapup64_9.6.sfs
puppy_fossapup64_9.6.sfs
zdrv_fossapup64_9.6.sfs

Wonder why yours is showing the fdrv at a different load point?
Maybe because I have no ydrv.

In your file experiment you are not replacing any same name file with another same named file that is different inside the file are you?

Try your file experiment with the same names for the files.
But in each drv.sfs have what is in each file be different from what is in the same named file in another drv.sfs

Example:
zdrv.sfs T1 has this in it.
fdrv.sfs T1 has something different in it.
Base.sfs T1 still something different than the others.
Etc..........
Now see if what is in the adrv.sfs T1 is now what is in the final T1 file that will be shown in the final layered operating filesystem.

In an operating system that functions as merge-in-RAM what has to be in RAM on boot-up are the firmware and drivers upon which the use of the monitor, the key-board, mouse-trackpad depend and --if access to the web is desired during initial setup-- those drivers and firmware as well. And, of course, so much of the base/core operating system as is necessary to make use of those drivers and hardware.

The ‘no-copy’ boot argument used to limit the extent to which contents of the base/core SFS were copied into RAM so that --even on computers with low RAM-- sufficient RAM renamed available to actually operate the system. Is the ‘no-copy’ option still supported? And if so, what, if any, effect does that have with the extent to which the contents of zdrv, fdrv, bdrv, adrv and ydrv are copied into RAM? My suspicion is none.

At any rate a firmware-cutter would be very useful. I’ve seen firmware sfses as large as 340 Mbs; while the actual firmware needed by any specific computer is likely to be a couple Mbs. I think the same situation is true of drivers. Reducing what drivers and firmware occupy RAM to only those drivers and firmware actually needed for a specific computer means more RAM remains available to other uses.

While it is true that most computers today have more than sufficient RAM for any configuration of systems, it also is true that many people come to Puppy Linux precisely because their computers are ‘resource-poor’ by today’s standards.

From what I gather apt & synaptic, the applications intended to be included in bdrv*, are difficult to create and are sensitive. If to be used bdrv should have the highest priority** after changes in RAM not yet Saved and the SaveFile/Folder; and modifications to bdrv should only be possible to those sufficiently sophisticated to create bdrv in the first place. But bdrv is a luxury: F-96 can be fully used without it. The same, however, is true of adrv and ydrv regardless of what they may contain so long as it is possible to obtain a web-browser somehow.

I’ll repeat what I posted before, with slight modifications. It remains the easiest solution because it accommodates the needs of all potential users. Now that F-96 has Quickpet, flesh out the repository it accesses. A web-browser isn’t needed until boot-up and internet access is obtained. Quickpet can provide one or more web-browsers once that happens. The iso should contain no adrv and no ydrv. bdrv should have priority in the merge file system, but be included in the ISO under the name obdrv. Neither apt nor synaptic will be used during the initial boot-up. If bdrv is wanted, it’s a simple name-change and reboot. If not wanted, it can be deleted. Users can stock adrv and ydrv with whatever applications suits them.

The Quick Setup GUI (which appears when a Puppy boots to desktop the first time) should display text providing the following notices:
Web-browser: after establishing and internet connect, Menu>Setup>Quickpet can be used to obtain a Web-browse.

Users desiring to make use of the alternate package managers apt and synaptic should Left-Click/mount the Storage Medium from which Puppy booted, Right-Click the file whose name begins with obdrv and edit that to only read bdrv.

If possible, a functioning firmware and driver cutter should be included in the base/core SFS.

The publisher can decide how much else should be included in Quickpet’s repository rather than included in the core/base SFS.

-=-=-=-=-=
* IIRC, bdrv has been used in other Puppys for other purposes. And amethyst has mentioned employing a bunch of other 'alphabet' drvs. I, myself, albeit unsuccessfully, attempted to create a gdrv to 'update' tarhpup64's glibc libraries. But those past practices do not prevent us from establishing a convention that bdrv is only to be used to provide applications which must have the highest priority in the merge-file-system. By convention, we don't put anything other than firmware in fdrv; and nothing other than drivers and firmware in zdrv. Future versions of Puppys currently using bdrv for some other purpose can modify initrd to change the designation of the drv currently containing applications which do not comply with that restriction.

** I may be confused by the use of such terms as stack-position. I always thought that priority was the inverse of load-order: the last loaded/copied/indexed having higher priority than its predecessors as the last would over-write in RAM any conflicting files; or, perhaps more technically accurate, earlier created inodes in RAM would be over-written so that the inodes remaining would be those pointing to the last loaded/copied/indexed file. I'm sure it is possible to write scripts which do otherwise --treat load order differently than last-in having priority-- but wouldn't such code be more difficult to write?

@bigpup
Each text file had the drive designation of the drive in which it was placed.
T1 in adrv "adrv", in bdrv "bdrv" and so on.

fr-ke wrote: Thu Jan 05, 2023 6:44 am

@bigpup
Each text file had the drive designation of the drive in which it was placed.
T1 in adrv "adrv", in bdrv "bdrv" and so on.

So in the layered operating filesystem.
What was in T1?