login
Search
We make the source code available, and yet noone here has even sat down for 30 seconds and gone and checked the kernel msdos mount code and realized that it almost nothing it can validate a filesystem on. It saw that space of disk, validated it as msdos, and mounted it. This is not ffs. When you do stuff like that, we are not your nanny.
does that almost nothing include the partition type number? because i dont see why would the kernel msdos mount code are you really implying that there is no way to identify a partition as various types of FAT? i think it's time that you did some reading.. -f -- to get a loan you must prove you don't need it.
You are more likely to see things if you look for them first...
Hi Frantisek. It is not what happened. The -t msdos was forced by you. But you were not trying to mount a filesystem with type A6. A typo can happen but your mistake is in your interpretation of what has happened after the typo. Take a break and then think about it carefully. Regards, David
ah shit. you are right :] and it worked because ffs does not overwrite the beginning of the partition. i misinterpreted what happened, but this is still a problem, right? :] -f -- when dating a homeless girl you can drop her off anywhere.
It's a "problem" in that something bad happened, but that is because of an operator error. In particular a root operator error: being root has the potential for unlimited error. There is no fix or check for "rm -rf /", is there. I've not looked at the code so I can't intelligently comment on what checks you can or cannot do, but the fundamental issue is that root has to be aware of every command entered, and must be prepared to fix *anything*. An OS cannot prevent you from most problems. Well, Windows tries, but look at what it feel like to use it... -- STeve Andre' Disease Control Warden Dept. of Political Science Michigan State University A day without Windows is like a day without a nuclear incident.
Ok, when I first learnt how to use unix nearly 20 years ago, one of the things I learnt was that a privileged user can break shit, but should not cause kernels to hang or crash. That would be considered a bug. Only DOS and windows 3.1 do that :) -- Sent from my mobile device http://www.glumbert.com/media/shift http://www.youtube.com/watch?v=tGvHNNOLnCk "This officer's men seem to follow him merely out of idle curiosity." -- Sandhurst officer cadet evaluation. "Securing an environment of Windows platforms from abuse - external or internal - is akin to trying to install sprinklers in a fireworks factory where smoking on the job is permitted." -- Gene Spafford learn french: http://www.youtube.com/watch?v=30v_g83VHK4
Hahahaha cp /etc/termcap /dev/mem That has crashed *every* version UNIX I have worked with, substituting an alternative large file on those pure sysv systems without /etc/termcap, of course. But let's say we figure out a way to do what you suggest and have the kernel robust and protected against all actions of a privileged user. What does that get us? They can still fuck up ld.so or libc, and poof, most the programs on the system will crash when started! Overwrite /etc/passwd with /dev/random and rename /bin and your system will stop being useful. WHAT PROBLEM ARE YOU TRYING TO SOLVE? Philip Guenther
the borderline between the useful and useless error checking is sometimes a bit fuzzy i think. i personally think this is an issue, perhaps not an important one, but one that i dont associate with bsd superior quality, that's all. i mean what was the chance of happening of this? but it could help make the system more robust.. it highlighted an issue "outside the box". -f -- bungee diving - living it up when you're going down!
Not THAT fuzzy. Foreign file systems NEVER get prime attention. When you do stupid things the results are rather predictable and you compound your error by trying to blame everybody else for your own singular lack of sanity.
i did not blame anyone for my mistake. just because you report what happened to you and ask what the others think about, doesnt mean that i blame them or demand a fix. it could very well have happened that someone said, yes this might be a bug, and someone might have tried to fix it. the end. instead of saying right at beginning that for this and this reason this and this happened and for this and this reason it is not considered a problem, this thread could have been a valuable resource for the archive; but i was sent reading the source, my parents were insulted and i was sent to drown in a lake. now i also lack sanity. well done misc@, living up to your name. the bootcamp of the internet. -f -- to know the road ahead, ask those coming back.
It's better to create a crappy diff that gets rejected than whine incessantly on a mailing list that by your own admission has a reputation for being like boot camp. You claim to know a decent amount about the situation, why not at least take a crack at a fix?
so sending half-baked crappy diffs will estabilish one as a useful, non-whining member of the community, right? "incessantly"? maybe you could look in the archives how much i post on this list. so wait, if i had submitted a "shot in the dark" bug report with sendbug, it'd be just closed with some comment or so, but first posting questions about it will get you flame and a label of being a whiner. my "whining", is a comparison of experiences with others, questions if someone can reproduce a particular problem i am having, whether it is considered a problem at all, and so on. a practice i thought about as the first step of bug reporting and as such a perfectly valid subject for a mailing list of this type. me and my assumptions. i dont understand why some people take problems reported so personally, as if a personal attack, and/or also interpreting it as a demand for an instant fix or i dont know what. it is not, wake up please. as for "go read the sources" every time there is a problem, even the developers are not familiar on the source level with every single part of the kernel and the system. they will go and ask the guy who knows it the best. i dont get it why is it expected of us, the users. maybe sendbug should be renamed to sendwhining -f -- mips => meaningless index of processor speed
Methinks you misinterpret who is being attacked. According to your interpretation, what was your purpose, However those developers are not only capable of reading some of the source, they have WRITTEN some of it.
Oh...you're on the paid support plan? My bad. You get OpenBSD for free. That's pretty amazing, isn't it? Why is it hard to believe that reframing a potential solution as "here's a diff" instead of "I broke my system as root and you need to take time out of your day to help me" will get better results? Sure, the diff may get rejected, but at least you're showing a touch bit more effort than the effort it takes to fire up your e-mail client.
I'm top posting because I think people have read enough. My sudo policy only allows me to test this; $ /usr/bin/sudo /sbin/mount_msdos -o nodev,nosuid,noexec /dev/sd0c /mnt/usb0 and I get mount_msdos: /dev/sd0c on /mnt/usb0: Inappropriate file type or format So I see no problem and Being able to force a system to do weird things can be useful anyway. As a side note and for people to be aware, I have seen BBB resets and hangs followed by hangs and crash dumps sometimes self initiating but especially when the usb is unplugged without waiting for it to settle down. This has occurred on 4.6 stable and now a july snapshot but only with some usbs like 8Gig microsds (4.6), a cheap 128mb disk (4.7 july) and a usb to ide (2.5inch) converter (4.7 July). The funny thing is I had no problem with these on a snapshot from a little before the 4.7 release date. I thought it was one particular laptopwhich was the worst for it, but I've had it happen on 3 different systems, 1 desktop and 2 laptops. I haven't said anything till now because I want to do some testing and comparison and don't have time right now (only affects some usbs, some of the time anyway), but I figured it's best to air it even if there's little to go on right now, in case anyone else has had this happen. On Mon, 26 Jul 2010 06:06:42 -0500
You mean the ones who like it so much they travel it twice?
I think that is a fundamentally flawed assumption. Root can do *ANYTHING*. Anything at all. Sure, preventing crashes is good, but you can't get around the fact that root is omniscient. -- STeve Andre' Disease Control Warden Dept. of Political Science Michigan State University A day without Windows is like a day without a nuclear incident.
Had this 'root' been *omniscient*, the incident wouldn't have happened. You probably meant to say that root is, in fact *omnipotent* ! -- I'm a VIP at my local liquor store and I'm root. Fear me ! -- PGP-Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x78AE48D9 PGP-Fingerprint: B4B5 2521 73BF 4BA3 13D2 80ED CF26 BE66 78AE 48D9
Unfortunately it's not that black and white, root can do some evil stuff with the mem/kmem, drm/xf86 and a boat loat of other gateways into kernel land. The point is that root can do a lot of stupid things, this is a feature, not a bug.. abuse wisely. In this case the kernel was told, by root, to interpret garbage on some partition.. pleasing 'root' is a high priority to 'kernel', they have a friends with benefits relationship. It's the best peep show I've seen, excluding all the ones with boobs. Enjoy Unix, I sure do. -Bryan.
If ffs had overwritten the beginning of the partition you would have ended
with a *different* error message and the kernel would not have crashed.
But more likely, the situation you describe could have never ever
occurred. Nobody else wants it this way, for a reason. You still haven't
thought about it enough nor you haven't learnt enough.
=> Your homework is to figure out what the other error message would be
and why.
(Trying to create a diff would help you to learn too, sending a bug report
will not.)
Regards,
David
since my first email, i see what i did wrong... that was the point of writing to the mail list in the first place, to see if i was doing something silly. turns out i was. does that warrant abuse? of course it does, i am not new here. i also see, that now this problem became simply a "should we babysit root" issue, and i dont want root to be babysit either. but regardless of that, i think leaving old garbage after newfs-ing a partition is not a good idea in any case and it's one of those things i wouldn't it would be the same error message ffs gives when given a non-ffs partition: this is simply not true. writing a useful, informative bug report needs research, testing, etc. i have learnt a lot by sending bugs. in fact, did not send bug reports because in the process of writing it i realized what i was doing wrong. maybe if i had started writing that report for this issue, i would have realized the mistake myself. -f -- to have a friend you must first be one.
On Mon, Jul 26, 2010 at 12:04:04PM +0200, frantisek holop wrote:
| but regardless of that, i think leaving old garbage
| after newfs-ing a partition is not a good idea in
| any case and it's one of those things i wouldn't
| except either. my mistake again.
Different filesystems use different parts of the disk, this is a fact
of life. For any and all re-use of disks, I tend to recommend to zero
out as much as you can wait for before putting a new OS on a disk.
After having dealt with the weird linuxisms that come up when not
properly wiping your disk not too long ago, my believe in this
approach has been greatly reaffirmed.
(in some cases, linux can put some metadata on either or both the
beginning and end of a disk - wiping only the first few megs leaves
the data at the end for great "fun" but not much profit upon
reinstalling).
I've not had much issues in this area with OpenBSD myself, but then I
tend to not mix different filesystems on my OpenBSD disks anyway (my
machines usually just run one OS). It still doesn't hurt to wipe the
disk though.
Paul 'WEiRD' de Weerd
+++++++++++>-]<.>++[<------------>-]<+.--------------.[-]
http://www.weirdnet.nl/
On Mon, 26 Jul 2010 12:23:36 +0200 The most bizarre case I've come across was with windows XP. I've wiped a partition before and had windows fail to install because there was something at the beginning of the disk that needed wiping. After a few tries and not wanting to rebuild my tables, I cleared a partition on another disk. It then wouldn't install to the new disk untill I unplugged that other disk. I then replugged it after install and all was sweet (seemingly atleast).
No, it would not be. Try harder. Regards, David
If you wanted to mount according to the partition type number, DON'T USE '-t <blah>'. We give you the option to OVERRIDE the partition type number and you made use of that override. You have taken command and we will watch your further progress with interest. We give you the pistol. Even bullets. Shooting the rabbit or your foot is up to you.
I believe that this thread is the result of documentation error on the mount(8) man page. A patch for the man page is at the end of this message. The problem is that the man page says: The argument following the -t is used to indicate the file system type. The type ffs is the default. This is incorrect. According to lines 248 through 251 of the source file at http://www.openbsd.org/cgi-bin/cvsweb/src/sbin/mount/mount.c?annotate=1.50 the actual default behavior is to check the disklabel's filesystem type: If -t flag has not been specified, and spec contains either a ':' or a '@' then assume that an NFS filesystem is being specified ala Sun. If not, check the disklabel for a known filesystem type. The original poster in this thread is wondering why mount(8) did not check the disklabel's filesystem type when he specified the -t option. The answer is that mount(8) checks the disklabel's filesystem type by default, but that -t overrides that default behavior. --- sbin/mount/mount.8.orig Mon Jul 26 11:59:30 2010 +++ sbin/mount/mount.8 Mon Jul 26 12:48:45 2010 @@ -269,12 +269,15 @@ The argument following the .Fl t is used to indicate the file system type. -The type -.Ar ffs -is the default. +If this option is omitted, then +.Nm +attempts to guess a file system type using the +.Xr disklabel 5 +and other information. The .Fl t option can be used +to override this behavior and to indicate that the actions should only be taken on file systems of the specified type. More than one type may be specified in a comma separated list.
