Browsing this Thread:
1 Anonymous Users
|
Temporal Relabeling while Booting
|
||||
|---|---|---|---|---|
|
Home away from home
 
|
We can agree on "not booting at all" prevents all problems
 We can also agree, that there should be no duplicate labels in the standard Aros setup. Meaning we are not aiming to provide a solution to boot into a system, with a lot of label-duplication as default option! Volumes used by a user on a daily basis should be given unique labels. Once identified a duplication the volume should be relabeled permanently by the user, to avoid further conflicts! With that in mind we shall search for a way that allows volumes with the same label to coexist on Aros without leading to a system crash. Possible scenarios: Some drives are plugged in while the computer was powered off, or some usb-sticks were left in the computer from the last session before powering on again or rebooting. Same goes for all possible external or internal drives. On two or more of these drives are volumes with the exact same label. Results: The generic device names may have changed. So e.g. dh0: is now dh1: In this case booting may fail, because grub fails to find the right device. In some strange cases the name in grub will stay the same and only Aros gives new names to your drives. However this problem ist not related to label-duplication. After reestablishing things with grub, we may finally may run in to naming related troubles. In startup-sequence we assign "Sys" to dh0: but that is now dh1: ... booting failed But still no duplication problem. If we want to keep our new configuration, we need to adjust startup-sequence accordingly. later on while booting we need to run some scripts in "work:", but it turns out, we got two volumes with the label "work" in our system now. Luckily our failsafe mechanism prevents Aros from freezing or crashing (as it would now in reality). One of our "work" volumes is shown as "dh1_work" - indicating the drive it is located on. The volume "work" on usb-stick du0: is indeed shown as "work" as it was mounted first. Bad luck: it is the wrong "work". The scripts we need are on dh1 and not on the usb-stick. booting still fails. Now we are smart and add "bootdevice=dh1" in grub. That not only forces Aros to boot from a certain device. It also gives the system a hint in what order volumes should be mounted. This is from bottom up beginning with the specified volume: 1. specified volume (dh1) 2. volumes on the same physical drive 3. volumes on other drives at the same controller 4. other controllers Now our "work" on dh1: gets mounted first and therefore keeps the label "work", while the volume on our usb-stick is now shown as "du0_work". If there is a complete working system on that usb-stick and we decide to boot from that stick, we can specify "bootdevice=du[x]" and voila "work" on usb is correctly shown as "work".
Posted on: 2015/5/16 14:40
Edited by cybergorf on 2015/5/16 15:05:06
Edited by cybergorf on 2015/5/16 15:08:33 |
|||
|
||||
|
Re: clarification
|
||||
|---|---|---|---|---|
|
Home away from home
|
Quote:
You are correct in that they need to be unique, but that does not necessarly means rdb tells so. Quote:
Of course. My first partition's device name on my pendrive is named du0 and the second one du1, the third du2 and fourth du4, etc. It does not change the fact that i can make a second pendrive using the exact same device names in rdb and using the exact same volume label names. But that's not the problem as i see it. Quote:
While Amiga OS itself (at least back in the day) was pretty simple to handle, including cross dos, scsii HD's etc. we all agreed on using some sensible device names. Nowadays with all external devices this becomes more difficult and relying on user sense alone is not an option anymore (at least that is how i see it). See also my answer above. we moved on, making it possible to create such situations. Quote:
I needed to interpret that. And i interpreted it as you meant volume labels. It's the actual real device name in the rdb that is named exactly the same. Quote:
In theory, yes. in practise, no. Quote:
But that is where things go wrong. Let's take the lock out of the equation (as that is obviously unwanted behavior) and take a practical example again: I have a sfs rdb formatted pendrive with AROS installed on it. I boot my computer from the pendrive and we reach AROS land. Now i insert the exact same pendrive brand and model, but not sfs formatted, but FAT32 formatted. It does not have any conflicting volume names nor use the same device name (at least not visible to me). Now (i guess as that is the software telling me) poseidon goes haywire, as it seems it is not capable of determining the different pendrives from eachother. It attaches my freshly inserted pendrive but at the same time throws out my earlier attached devices, including mouse and keyboard. That has nothing todo with a renaming of volume names and/or device names, but seems to be caused by a issue that lies underneath all of that. Mind, that i can only guess here, as i am not able to debug the issue myself. When i use a different brand/model pendrive in the same situation then everything seems to work for me as expected. Quote:
Yes, but that does not change the fact that the actual real stored in rdb device names differ. What you seem to propose (see, i need to guess again ;-p) is adding an extra layer taking out the actual real device name and mix something together based on the algorythm that you showed. Although that might be a solution, i find it a rather odd one (but that might be just me).
Posted on: 2015/5/16 14:29
|
|||
|
||||
|
Re: clarification
|
||||
|---|---|---|---|---|
|
Home away from home
|
Quote:
Is that a problem? I don't think so. These generic device names serve two functions: providing a unique identifier and give some hint, what controller is used. As long as they are unique per (mount-)session everything is fine. Next time the configuration may be different and the device names are therefore different too. Thats were labels come into action.... And YES: labels should be declarative and somehow unique at the same time. This preserves us from a lot of troubles. But still there needs to be a fallback solution in place of duplicate labels. This solution needs also take booting into account! we agree on that. It needs to take ALL valid states of the OS into account! Thats why I asked you for your dirty dozen of worst case scenarios some days ago! Quote:
Lets bring closure to these things than. Quote:
yes - while I try to keep a solution as simple as possible, it should be as complex a necessary to allow it to be generally used. Quote:
I don't agree here. Thats why I brought up some idea using the "bootdevice" option (if provided) to help the user to influence the order in which devices are mounted by Aros. I will elaborate this in my next post.
Posted on: 2015/5/16 13:43
|
|||
|
||||
|
Re: clarification
|
||||
|---|---|---|---|---|
|
Home away from home
|
Quote:
No it is not possible at all. Device names need to be unique. They may be labeled the same way (e.g. "work") but the device names are different (e.g. "du0" and "du1") Quote:
??? Quote:
Yes, but they are only labeled thy same way! And as long as you plug them in the same port one after an other, they may have even the same device name. no problem. In case one of this drives can not be unmounted , when plugging out (some lock, bad behavior, should not happen, but well...), than the next stick gets a new device name. And the label needs to be shown differently too. If you plug in two or more of these sticks in at the same time, the system gives them different generic device names ("du0", "du1", "du2") The first volume mounted is shown under its original label "work". Lets say "du0" was the lucky first one to mount. so we have got device du0: with label work: now comes "du1" device du1: with label du1_work: while the first one can keep its label the 2nd needs to be given a temporal name, as long as it is mounted. Nothing is really renamed or written to that stick. Next time you plug it in alone the label will be shown as "work". last stick in: device du2: with label du2_work:
Posted on: 2015/5/16 12:57
|
|||
|
||||
|
Re: clarification
|
||||
|---|---|---|---|---|
|
Home away from home
|
Quote:
The problem is that the naming of the devicename depends on the cicumstances. e.g. usb devices that are attached are named differenlty then internal storage devices. Quote:
Yes, i think we can agree to that  Quote:
See also my answer concerning device naming. Quote:
Well, not to be a pita (which i realize i am), but you leave a lot of things wide in the open which seems you do not like to address (or avoid on purpose).. That's not a problem perse, but makes me wonder. Quote:
Yes, and that is very much appreciated. But imo it is a bandage at a place where it does not matter much. The complexity of the problem as a whole, and given that i do not know every exact detail about internals, lead me to believe it would be more benefitial to come up with a solution that is more general and can be applied to the different circumstances that can be encountered. Quote:
Which led me to believe hat there is problem that lies underneath, not with the label naming ansich. For that see also the booting problems whenever there is a device in place with a name that is also required for/by AROS during boot. It was clear for me that you wanted to focus on the part where AROS booted fine and then insert a device that could cause problems, but that's why i believe your solution to be just a bandage at the wrong place. Quote:
I can agree to that fully
Posted on: 2015/5/16 12:35
|
|||
|
||||
|
Re: clarification
|
||||
|---|---|---|---|---|
|
Home away from home
|
Quote:
It seems you are guessing a lot of things I never said und surely do not want at all, because it would complicate or even harm systems behavior.  As from my very first posting on this thread I am just suggesting a simple but smart solution for the problem of duplicated volume labels (the user given ones). Situation now is that plugging in an usb-stick will freeze the system, if there are already used (mounted) labels like "work" or "system" on that stick. A common situation for install-media or backup-media. This is one of the 1000 ways of freezing Aros ... maybe we can reduce that to 999 ways?
Posted on: 2015/5/16 11:58
|
|||
|
||||
|
Re: clarification
|
||||
|---|---|---|---|---|
|
Home away from home
|
Quote:
this matter leads to a lot of confusion obviously. :-/ Thats why I try to speak of "label" for the user given name of a volume. In contrast to the generic device name. And only in case of some double use of labels, which is of course stupid, but as pointed out may easily happen on usb-sticks and does lead to a system freeze. And only temporal! No, I do NOT suggest to change the name in the rdb, but only in the list of active devices in ram. Like ignoring the original label and assigning a new label to the (always unique) device name.
Posted on: 2015/5/16 11:38
Edited by cybergorf on 2015/5/16 12:01:09
|
|||
|
||||
|
Re: clarification
|
||||
|---|---|---|---|---|
|
Home away from home
|
Quote:
As explained above: Sorry, but that is only possible when you have both hd's/pendrives inserted at the same time and then prepare them for usage. Quote:
It's not a bug, it's progressing into the modern world. In practice: I format a pendrive, i named it usb0. I removed it and insert a new pendrive. I format that as device usb0 as well. Then my friend comes over with his pendrive. Guess what he named his AROS formatted usb-pendrive ? Quote: Devices are named by the system in a generic way, so you second "hu0" becomes "hu[next free number]". Sure. Quote: User given labels are not necessarily unique, but can be mounted under a different temporal name based on the always unique device name. So, instead of me guessing here that you want AROS to automagically change device names depending on the circumstances, what did you had in mind to accomplish that ? Quote: "work" on your additional drive is shown as "hu[next free number]_work". You do realize that for SFS prepared storage devices, that this means changing the actual devicename in rdb ?
Posted on: 2015/5/16 11:24
|
|||
|
||||
|
Re: clarification
|
||||
|---|---|---|---|---|
|
Home away from home
|
Quote:
As explained above: There can not be two devices with the same name (e.g. two hu0:) in the system! If this happens its a bug that needs to be addressed in the first place. Devices are named by the system in a generic way, so your 2nd "hu0" becomes "hu[next free number]". User given labels are not necessarily unique, but can be mounted under a different temporal name based on the always unique device name. "work" on your additional drive is shown as "hu[next free number]_work".
Posted on: 2015/5/16 11:13
|
|||
|
||||
|
Re: clarification
|
||||
|---|---|---|---|---|
|
Home away from home
|
@cdimauro:
Ah, i didn't think of that regarding the ID. Thanks for the detailed explanation. Quote: cybergorf wrote: Yes, and then i insert 2nd device hu0: which is also labeled work:. As already established: don't do stupid things. But that is exactly what the solution is attempting to fix in the first place. It seems to me that you never ran into the practical situation were more then one ntfs/fat32 partition is being accessed by AROS. My terabyte HD's are neatly partitioned, and each partition has it's own name. And that is assuming user took the liberty to actually give their partitions meaningful names (instead of an OS like windows naming at least bootpartitions the same). Unfortunately things gets worse when you add mounting usb pendrives and external hd's to the equation. So, while in theory it is very nice to have support for fat32/ntfs in practice it can be a bitch to work with (and that is with removing the handlers at boot time).
Posted on: 2015/5/16 11:01
|
|||
|
||||
You can view topic.
You cannot start a new topic.
You cannot reply to posts.
You cannot edit your posts.
You cannot delete your posts.
You cannot add new polls.
You cannot vote in polls.
You cannot attach files to posts.
You cannot post without approval.
You cannot use topic type.
You cannot use HTML syntax.
You cannot use signature.
You cannot create PDF files.
You cannot get print page.
