Please let me know which banks DON'T work with FireFox
Banque de Luxembourg and their Fund market (try using the "Direct Access" option menu on the left hand side to view one of their "colored" funds (profiles) and weep...).
The idiots have implemented a check for visual-basic support in the browser, and refuse access to any browser that doesn't have it. The funny thing, however, is that the application itself (display of fund graphs) doesn't need Visual Basic at all, and works just fine when you bypass the stoopid check by going directly to the final URL!
A similar thing exists in their
Please let me know which banks DON'T work with FireFox
Banque de Luxembourg and their Fund market (try using the "Direct Access" option menu on the left hand side to view one of their "colored" funds (profiles) and weep...).
The idiots have implemented a check for visual-basic support in the browser, and refuse access to any browser that doesn't have it. The funny thing, however, is that the application itself (display of fund graphs) doesn't need Visual Basic at all, and works just fine when you bypass the stoopid check by going directly to the final URL!
A similar thing exists in their
homebanking application, even though the app itself, again, doesn't make any actual use of VB! However, in addition to the VB check, the homebanking also does a server-side User-Agent check, so you need to fake that one as well (for homebanking, but not for the fund graphs). Weird.
They could do this using existing anti-corruption/money laundering legislation.
As far as money-laundering is concerned: For a very long time, most anti-money laundering laws worldwide were worded in such a way that they only applied to hiding the origin of money coming from drug-related crimes. "Laundering" money coming from other crimes, such as extortion, theft, fraud,... was not considered to fall under these laws! The reason for this was that most of these laws were enacted in the framework of the US "war against drugs".
It's only rather recently that European anti-money laundering laws have been expanded to apply to the proceeds of all crimes. However, AFAIK the US aml laws still only apply to drug money...
Furthermore, it's easy to replace a transaction and modify the display. For example, the user wishes to make two transactions A, and B. He enters them and then sends them to his bank. Underwater, the malicious program changed these transactions, but does not show the user. It remembers the id's of these transactions and shows the original intended transactions whenever they come up on the user's screen.
But eventually, the user starts getting calls from the intended recipients of these transactions, asking him why he hasn't paid his bills yet...
Moreover, most banks still send transaction confirmations on paper, so 3 days later, the user will notice what's up.
If the thief's bank is doing its job, it will not allow him to withdraw the money whithin these 3 days, so at that point everything can still be reversed. Probable modus operandi of such thieves will be to steal from lots of accounts at once, and the number of incoming transfers within such short period of time will set of alarms at incoming bank, who watch for this kind of behavior (because some kinds of drug money laundering shows a similar pattern of behavior, and banks are very careful at catching these, as the penalties for becoming an unwitting associate of drug money laundering are quite stiff).
In order to avoid a sudden surge of incoming transfers, the thief would have to spread his activity over a longer timeframe, in order to stay under the radar. But that again would make it much more likely that his account will have been frozen/closed before he can collect the loot...
It's very easy for spyware/malware to do a man in the middle attack and insert any number of transactions which it will hide from you by sitting between you, your browser and your bank.
True. However, he will have to do it while the session is active, which makes it quite easy to trace him to the exact cybercafé where it happened. With more passive approaches, a thief could use sniffed codes a while later, making it lots harder to find out which of the many cybercafés from which you browsed your bank accounts when holiday sniffed your numbers.
Moreover, the more secure TAN code schemes guarantee that each TAN can only be used for one single transfer, meaning that a man-in-the-middle would need to "eat" a legitimate transfer to insert his own. So this legitimate transfer would not be done, guaranteeing that the victim will notice rather soon that something is off.
Since the programs are running on the endpoint of the SSL connection, SSL is not going to help you either.
Their system: a chip card reader which would encrypt the bank-to-customer communication on card. Their rationale was that this way, it would be virus proof, because the customer's private key would be stored nowhere on his PC, nor would the SSL engine run on the PC.
What they were forgetting however, was that the data to be encrypted (amounts, target account of bank transfer) were entered on the PC's keyboard, and could already have been clobbered by a Trojan before they even reached the chip card for encryption!
And no, the card itself didn't have a display, where it could display, for doublechecking, the data that it received (some German banks apparently use such systems, but obviously these cards are much more expensive to make than plain chipcards, so BGL opted for the less expensive solution).
Of course, the card reader was utterly dependant on Internet Explorer and a Microsoft OS running on the PC, so the end-effect was that the system was even less secure than it would have been without the card reader!
Hi, I'm not informed much about American and other foreign banks, but here in The Netherlands it works the following:
(Almost all) The banks over here use a kind of calculator device. You insert your pass into it. Your normal pass you use for withdrawal from ATM's....
Here is Luxembourg, banks are too cheap for handing out these calculator thingies. Instead they use a scratch-off plastic card with 16 alphanumeric digits on it. When logging in to their service, the site choses 2 (or some 3) positions out of the 16 possible, and you have to enter the corresponding digits.
This key is different every X seconds (I don't know the interval).
Well, here in Luxembourg, the "good" banks do it the same: the key (in our case: choice of scratch card numbers) is valid a set amount of time. However, some of the (less technically savy banks) propose you a different choice of digits each time you hit reload... so a thief who has sniffed some numbers (but not all) can just keep on hitting reload until the bank asks for numbers that he has... not good!
If you want to transfer money, you get another screen. You have to insert the number shown on the screen into the device. After you hit 'OK', another number is shown on the device, you type this in the inputbox of the website. After it is verified, the transfer will be processed.
Our banks do not have this additional security yet... (Apart from maybe Cortal-Consors. I know their German operation has such a system).
This is all done on HTTPS...
In Luxembourg too. No bank is foolish enough to use plain http.
and works with most browsers.
Unfortunately, this is not the case in Luxembourg (although some progress was made over the course of last year).
The currently worst offenders have a gateway page which features a Rube-Goldberg like chain of Java Applets, Java Script code, and VB code which only works on Internet Explorer (the Java Applet is MS proprietary java (using the proprietary com.ms.util.SystemVersionManager class...). The output of this is fed, via the VB script, and then the Javascript (!) into a second URL, which gives you access to the Web application itself. Interestingly enough, once that gate is passed, there is no further dependancy on MS-ware, and you can cheat yourself access to the contents (graphs of their mutual funds) by entering that second URL manually.
For their homebanking they have the same "proprietary applet" hack, and in addition a server-implemented browser check. Manually enter the JVM=1 bit into the URL, and fake an Internet Exploder User Agent and you are in! What the hell are they thinking?
I believe this is one of the most secure methods I can imagine. It is not flawless maybe, but it works and there is much needed to hijack information from the sessions. Without the device, the pass and the account number one can do nothing. Without the PIN you still go nowhere....
Indeed, the number generated by the device makes it secure even against keystroke loggers that may be installed (but don't challenge your luck either...)
AFAIK you *cannot* patent game mechanics in the US.
You cannot patent software in Europe either (at least not until the Parliament approves of the Krecké-directive in the second reading...). This howver didn't stop rogue companies such as Teles from registering such patents, and sadly enough, it didn't stop the courts from
finding in their favor either...
When my father was a kid, he needed to have drawn blood too. All went well until the doctor's phone rang. "Just hold it with your other hand and don't move". Then he went off to chat for 10 minutes... (!).
Christ, take off your tinfoil! This is an entirely reasonable and proper use of legislative power.
This bill stops Bad Guys® from stealing the inexperienced users' life savings before they actually steal anyone's money.
Theft and fraud are already illegal. Who says that this law will do anything against phishers? The reason why phishing thrives is not because it is legal, but because it's hard to investigate and/or police just can't be bothered.
It does not outlaw building any website, just those designed with the intent and purpose to steal your bank password.
How do you prove intent? And what is the exact wording of the bill? If the intent is truly to steal and defraud, we've already got laws. We don't need any laws either forbidding to "carry weapons with intents of threatening peasants to give up their wallets". Mugging is already forbidden, and anything such a hypothecal law might achieve is inconvenience the butcher who brings a new knife to his shop...
A Luxembourgish Linux user got threats from a bank because he featured a look-alike login page on his Website. Purpose of that login page: strip an obnoxious browser check. But that's not how the bank tried to spin it.
Now, leaving because you don't like the programming language--and one that you don't really know? Well, that's just silly.... . No matter how trivial or horrific the situation, your next employer is primarily interested in how you handled it. Were you a professional adult or a spoiled child? Needless to say, they aren't hiring the latter...
Of course the tidbit about Microsoft, that's not what are going to tell your next boss. That's for your friends at the the pub, or for Slashdot. With your next boss, use more "professional" sounding reasons: lack of perspective, lack of autonomy, job below your capacities and all that vague bull.
A couple of years ago, I was in a similar kind of situation, and I made sure not to even mention the word "Linux" in the hiring interview of my new job. It was only when my new boss started on that subject that we exchanged a few words about it. Of course, once on the new job, I exercised less restraint about it (but in hindsight: I probably should have...)
This is interesting. Thanks. Just wondering though whether you can set up that install server on any Unix box, or whether the server already would need to be a Solaris box. In the latter case, you might have a chicken and egg problem...
[keyfobs] In theory, I don't think you should have to mount those at all.
Hmm, this sounds interesting, never did actually try...
Tried it, there was indeed a/dev/usb/mass-storage0 entry that appeared as soon as I inserted my SanDisk cruzer, but nothing was mounted (... nor was that device node readable).
Summary: You first use prtconf -v to find out the USB vendor and product id of your device (equivalent of Linux' lsusb etc commands) and then append the following line to/kernel/drv/scsa2usb.conf (or/kernel/drv/usba10_scsa2usb.conf, depending on your kernel patch level):
After addding this, I rebooted, and as soon as I plugged in the SanDisk Cruzer or my Sony camera, they were automatically mounted on/rmdisk/noname and/rmdisk/unnamed_rmdisk. Cool!
This blog post [+kb mode and Terminate_Server]may be helpful.
Yep, that works. Only sore point: the needed +kb option also has the side-effect of disabling Alt+Gr... But using Shift+Delete instead of AltGr+Delete solved the issue.
Of course, in the case where you'd need it the most (messed up X install and no network), you'd have a hard time to set it up in the first place...
Works fine on other versions. Did you specify the directory where your packages are stored [right], or did you specify the directory where your package is stored [wrong]?
Actually I did pkgadd -d directorypackage, in two separate parameters, where directory was the where the packages where stored. That would be right?
However, oldmanmtn has pointed out a different syntax, with one argument after -d, namely the directory of the package. I haven't tried that one. Well, I'll have to do some further tests this evening, to see which variant works, and which doesn't...
if you install from the "Install" CD with a supported video card, you get an X installer
Actually, during install, X was just fine on both laptops. The messed up display happened after install was finished. The text installer on the "low memory" laptop was running in a dterm, under X.
If you toss that disc and just shove in Software 1/1, you get the good (curses) installer.
The CD used on both laptops was CD 1 (of 4), I didn't download any special CD with drivers for my graphics card.
Actually, the first UNIX to run on an x86 platform was SCO XENIX,
Followed by many others, such as Minix (who can ignore with a straight face that Minix ran on the PC before Linux did?), Coherent ("first casualty"), misc BSD variants, and many many others. Linux was not the first Unix to run on the PC, it was (... and is...) merely the best;-)
That's why the grand-parent ironized about the "well informed opinion" of that Sun CIO... I'm just wondering, wasn't even SunOs (predecessor of Solaris) itself among the many Unix variants that ran on the PC before Linux existed?
You don't have to copy them anywhere. Either "pkgadd -d/cdrom/..." and select your package from the list, or "pkgadd -d/cdrom/.../package_name".
Yeah, tried that, but made one small error, and specified base directory and package as separate params, and then gave up on it.
[keyfobs] In theory, I don't think you should have to mount those at all.
Hmm, this sounds interesting, never did actually try...
On a real PC, you can often redirect the console to a serial line and use "tip" (or some Linux equivalent) to get to the machine's console.
On a real PC. On a laptop without a serial port, this is somewhat harder, if all you have is a USB-to-serial cable, which would itself need a special driver...
You can also try PXE booting your machine. Since the boot/install image is on a server, you can easily insert your driver into the image so it is available at install time.
This is interesting. How exactly would you set it up? I know how to do this with Linux, but Solaris is mostly new to me (only used it as an unpriv'd user eons ago, when I was a student, but never admin'ed it). Where on the tftp server do you put the kernel, where do you find the kernel on the install media, how do you make the equivalent of the initrd, what is the Solaris equivalent of pxelinux, etc?
if you use the Xorg server instead of Xsun. I thought Xorg was the default in s10?
It is... Although, ironically, in my case the Xorg was the one with the messed-up display: the fix (on the old laptop...) was to change to Xsun. Weird...
If ctrl-alt-backspace isn't working, try using the crtl and alt on the right side of the keyboard.
Didn't think about that one. For some reason, I always use ctrl and alt from the left side. Thanks.
Could be. The old has 256 MB, while the new one has 512MB, IIRC.
But is the Solaris installed really that bloated that it has to drop back into a text-mode installer if it has "only" than 256MB ?!?
Probably a not-totally-conformant CD drive that may not be "offically" supported under Solaris.
It's a plain ATAPI drive... What happened was that after the boot the installer asked for CD #2, and I accidentally inserted #3. Of course it complained, but it refused to eject it! Even the button on the drive was ignored. Typing eject into a second dterm didn't do anything either. Time for a paperclip. After putting CD #2 in, it didn't recognize that one either. Eventually I clicked skip, then the installer asked for #3. After putting that in, it got ignored. Rebooting (without a CD) brought me back (after a while) to the installer asking for #3. No way to convince it to go back to #2... Eventually, I had to start over. There goes a Saturday afternoon!
You don't have to copy the packages. "pkgadd -d..." works fine.
I noticed this option, but pkgadd seemed to consistently ignore it...
"boot -s" or something similar from the OK> prompt will get you to single-user mode.
Didn't try that one. This will be useful for the next time. Thanks.
No idea. The Sun hardware I work on is off in a server room - and I've never used USB keyfobs or similar on Solaris.
Keyfobs are handy to transfer the network driver to the Solaris box if you don't want to burn a CD (which is still slower to burn than simply write the stuff on the fob)
You're right, I should have qualified that as "dyed in the wool Oracle DBA's".
Hmmm, but then, "dyed in the wool MySql DBA's" will tend to stick with Linux and MySql instead... And "dyed in the wool Sequel Server DBA's" would likewise stick with Windows...
Slashdot Mirror
Banque de Luxembourg and their Fund market (try using the "Direct Access" option menu on the left hand side to view one of their "colored" funds (profiles) and weep...).
The idiots have implemented a check for visual-basic support in the browser, and refuse access to any browser that doesn't have it. The funny thing, however, is that the application itself (display of fund graphs) doesn't need Visual Basic at all, and works just fine when you bypass the stoopid check by going directly to the final URL!
A similar thing exists in their Please let me know which banks DON'T work with FireFox
Banque de Luxembourg and their Fund market (try using the "Direct Access" option menu on the left hand side to view one of their "colored" funds (profiles) and weep...).
The idiots have implemented a check for visual-basic support in the browser, and refuse access to any browser that doesn't have it. The funny thing, however, is that the application itself (display of fund graphs) doesn't need Visual Basic at all, and works just fine when you bypass the stoopid check by going directly to the final URL!
A similar thing exists in their homebanking application, even though the app itself, again, doesn't make any actual use of VB! However, in addition to the VB check, the homebanking also does a server-side User-Agent check, so you need to fake that one as well (for homebanking, but not for the fund graphs). Weird.
No IE, no VB, No service :-(
As far as money-laundering is concerned: For a very long time, most anti-money laundering laws worldwide were worded in such a way that they only applied to hiding the origin of money coming from drug-related crimes. "Laundering" money coming from other crimes, such as extortion, theft, fraud,... was not considered to fall under these laws! The reason for this was that most of these laws were enacted in the framework of the US "war against drugs".
It's only rather recently that European anti-money laundering laws have been expanded to apply to the proceeds of all crimes. However, AFAIK the US aml laws still only apply to drug money...
Adsense is still not working fully. On many sites ( example), clicks on ads only work roughly one time out of three.
But eventually, the user starts getting calls from the intended recipients of these transactions, asking him why he hasn't paid his bills yet...
Moreover, most banks still send transaction confirmations on paper, so 3 days later, the user will notice what's up.
If the thief's bank is doing its job, it will not allow him to withdraw the money whithin these 3 days, so at that point everything can still be reversed. Probable modus operandi of such thieves will be to steal from lots of accounts at once, and the number of incoming transfers within such short period of time will set of alarms at incoming bank, who watch for this kind of behavior (because some kinds of drug money laundering shows a similar pattern of behavior, and banks are very careful at catching these, as the penalties for becoming an unwitting associate of drug money laundering are quite stiff).
In order to avoid a sudden surge of incoming transfers, the thief would have to spread his activity over a longer timeframe, in order to stay under the radar. But that again would make it much more likely that his account will have been frozen/closed before he can collect the loot...
True. However, he will have to do it while the session is active, which makes it quite easy to trace him to the exact cybercafé where it happened. With more passive approaches, a thief could use sniffed codes a while later, making it lots harder to find out which of the many cybercafés from which you browsed your bank accounts when holiday sniffed your numbers.
Moreover, the more secure TAN code schemes guarantee that each TAN can only be used for one single transfer, meaning that a man-in-the-middle would need to "eat" a legitimate transfer to insert his own. So this legitimate transfer would not be done, guaranteeing that the victim will notice rather soon that something is off.
Since the programs are running on the endpoint of the SSL connection, SSL is not going to help you either.
Exactly. A couple of years ago, Banque Générale du Luxembourg had a flawed system which ignored this basic point.
Their system: a chip card reader which would encrypt the bank-to-customer communication on card. Their rationale was that this way, it would be virus proof, because the customer's private key would be stored nowhere on his PC, nor would the SSL engine run on the PC.
What they were forgetting however, was that the data to be encrypted (amounts, target account of bank transfer) were entered on the PC's keyboard, and could already have been clobbered by a Trojan before they even reached the chip card for encryption!
And no, the card itself didn't have a display, where it could display, for doublechecking, the data that it received (some German banks apparently use such systems, but obviously these cards are much more expensive to make than plain chipcards, so BGL opted for the less expensive solution).
Of course, the card reader was utterly dependant on Internet Explorer and a Microsoft OS running on the PC, so the end-effect was that the system was even less secure than it would have been without the card reader!
(Almost all) The banks over here use a kind of calculator device. You insert your pass into it. Your normal pass you use for withdrawal from ATM's....
Here is Luxembourg, banks are too cheap for handing out these calculator thingies. Instead they use a scratch-off plastic card with 16 alphanumeric digits on it. When logging in to their service, the site choses 2 (or some 3) positions out of the 16 possible, and you have to enter the corresponding digits.
This key is different every X seconds (I don't know the interval).
Well, here in Luxembourg, the "good" banks do it the same: the key (in our case: choice of scratch card numbers) is valid a set amount of time. However, some of the (less technically savy banks) propose you a different choice of digits each time you hit reload... so a thief who has sniffed some numbers (but not all) can just keep on hitting reload until the bank asks for numbers that he has... not good!
If you want to transfer money, you get another screen. You have to insert the number shown on the screen into the device. After you hit 'OK', another number is shown on the device, you type this in the inputbox of the website. After it is verified, the transfer will be processed.
Our banks do not have this additional security yet... (Apart from maybe Cortal-Consors. I know their German operation has such a system).
This is all done on HTTPS...
In Luxembourg too. No bank is foolish enough to use plain http. and works with most browsers.
Unfortunately, this is not the case in Luxembourg (although some progress was made over the course of last year).
The currently worst offenders have a gateway page which features a Rube-Goldberg like chain of Java Applets, Java Script code, and VB code which only works on Internet Explorer (the Java Applet is MS proprietary java (using the proprietary com.ms.util.SystemVersionManager class...). The output of this is fed, via the VB script, and then the Javascript (!) into a second URL, which gives you access to the Web application itself. Interestingly enough, once that gate is passed, there is no further dependancy on MS-ware, and you can cheat yourself access to the contents (graphs of their mutual funds) by entering that second URL manually.
For their homebanking they have the same "proprietary applet" hack, and in addition a server-implemented browser check. Manually enter the JVM=1 bit into the URL, and fake an Internet Exploder User Agent and you are in! What the hell are they thinking?
I believe this is one of the most secure methods I can imagine. It is not flawless maybe, but it works and there is much needed to hijack information from the sessions. Without the device, the pass and the account number one can do nothing. Without the PIN you still go nowhere....
Indeed, the number generated by the device makes it secure even against keystroke loggers that may be installed (but don't challenge your luck either...)
You cannot patent software in Europe either (at least not until the Parliament approves of the Krecké-directive in the second reading...). This howver didn't stop rogue companies such as Teles from registering such patents, and sadly enough, it didn't stop the courts from finding in their favor either...
pbranes has already posted the very same comment, three times to this story, word for word. And zillions of times to previous firefox stories.
De Krécké as och nët besser wéi de Metzleschjong!
Yes.
This bill stops Bad Guys® from stealing the inexperienced users' life savings before they actually steal anyone's money.
Theft and fraud are already illegal. Who says that this law will do anything against phishers? The reason why phishing thrives is not because it is legal, but because it's hard to investigate and/or police just can't be bothered.
It does not outlaw building any website, just those designed with the intent and purpose to steal your bank password.
How do you prove intent? And what is the exact wording of the bill? If the intent is truly to steal and defraud, we've already got laws. We don't need any laws either forbidding to "carry weapons with intents of threatening peasants to give up their wallets". Mugging is already forbidden, and anything such a hypothecal law might achieve is inconvenience the butcher who brings a new knife to his shop...
A Luxembourgish Linux user got threats from a bank because he featured a look-alike login page on his Website. Purpose of that login page: strip an obnoxious browser check. But that's not how the bank tried to spin it.
And also people who try to ensure interoperability of bank sites with "non-standard" browsers.
Don't laugh... it did actually happen!
Of course the tidbit about Microsoft, that's not what are going to tell your next boss. That's for your friends at the the pub, or for Slashdot. With your next boss, use more "professional" sounding reasons: lack of perspective, lack of autonomy, job below your capacities and all that vague bull.
A couple of years ago, I was in a similar kind of situation, and I made sure not to even mention the word "Linux" in the hiring interview of my new job. It was only when my new boss started on that subject that we exchanged a few words about it. Of course, once on the new job, I exercised less restraint about it (but in hindsight: I probably should have...)
This is interesting. Thanks. Just wondering though whether you can set up that install server on any Unix box, or whether the server already would need to be a Solaris box. In the latter case, you might have a chicken and egg problem...
Hmm, this sounds interesting, never did actually try...
Tried it, there was indeed a /dev/usb/mass-storage0 entry that appeared as soon as I inserted my SanDisk cruzer, but nothing was mounted (... nor was that device node readable).
After a bit of googling around, I came accross the following post: Re: LaCie disk on usb 2.0
Summary: You first use prtconf -v to find out the USB vendor and product id of your device (equivalent of Linux' lsusb etc commands) and then append the following line to /kernel/drv/scsa2usb.conf (or /kernel/drv/usba10_scsa2usb.conf, depending on your kernel patch level):
attribute-override-list = "vid=0x781 pid=0x8888 rev=* subclass=ufi protocol=cb modesense=false reduced-cmd-support=true";
If you have more than one USB storage device, add a vid=... clause for each of them, separated by comma:
attribute-override-list = "vid=0x781 pid=0x8888 rev=* subclass=ufi protocol=cb modesense=false reduced-cmd-support=true", "vid=0x54c pid=0x10 rev=* subclass=ufi protocol=cb modesense=false reduced-cmd-support=true";
After addding this, I rebooted, and as soon as I plugged in the SanDisk Cruzer or my Sony camera, they were automatically mounted on /rmdisk/noname and /rmdisk/unnamed_rmdisk. Cool!
Yep, that works. Only sore point: the needed +kb option also has the side-effect of disabling Alt+Gr... But using Shift+Delete instead of AltGr+Delete solved the issue.
Of course, in the case where you'd need it the most (messed up X install and no network), you'd have a hard time to set it up in the first place...
Which is what I ended up doing, and from that point on, Solaris would recognize no CD at all as correct, not even the #2 that it was expecting...
Actually I did pkgadd -d directory package, in two separate parameters, where directory was the where the packages where stored. That would be right?
However, oldmanmtn has pointed out a different syntax, with one argument after -d, namely the directory of the package. I haven't tried that one. Well, I'll have to do some further tests this evening, to see which variant works, and which doesn't...
if you install from the "Install" CD with a supported video card, you get an X installer
Actually, during install, X was just fine on both laptops. The messed up display happened after install was finished. The text installer on the "low memory" laptop was running in a dterm, under X.
If you toss that disc and just shove in Software 1/1, you get the good (curses) installer.
The CD used on both laptops was CD 1 (of 4), I didn't download any special CD with drivers for my graphics card.
It does on any new partition it creates. But it still manages to become confused if a 82 partition happens to be already present during installation.
Followed by many others, such as Minix (who can ignore with a straight face that Minix ran on the PC before Linux did?), Coherent ("first casualty"), misc BSD variants, and many many others. Linux was not the first Unix to run on the PC, it was (... and is...) merely the best ;-)
That's why the grand-parent ironized about the "well informed opinion" of that Sun CIO... I'm just wondering, wasn't even SunOs (predecessor of Solaris) itself among the many Unix variants that ran on the PC before Linux existed?
Yeah, tried that, but made one small error, and specified base directory and package as separate params, and then gave up on it.
[keyfobs] In theory, I don't think you should have to mount those at all.
Hmm, this sounds interesting, never did actually try...
On a real PC, you can often redirect the console to a serial line and use "tip" (or some Linux equivalent) to get to the machine's console.
On a real PC. On a laptop without a serial port, this is somewhat harder, if all you have is a USB-to-serial cable, which would itself need a special driver...
You can also try PXE booting your machine. Since the boot/install image is on a server, you can easily insert your driver into the image so it is available at install time.
This is interesting. How exactly would you set it up? I know how to do this with Linux, but Solaris is mostly new to me (only used it as an unpriv'd user eons ago, when I was a student, but never admin'ed it). Where on the tftp server do you put the kernel, where do you find the kernel on the install media, how do you make the equivalent of the initrd, what is the Solaris equivalent of pxelinux, etc?
It is... Although, ironically, in my case the Xorg was the one with the messed-up display: the fix (on the old laptop...) was to change to Xsun. Weird...
If ctrl-alt-backspace isn't working, try using the crtl and alt on the right side of the keyboard.
Didn't think about that one. For some reason, I always use ctrl and alt from the left side. Thanks.
Could be. The old has 256 MB, while the new one has 512MB, IIRC.
But is the Solaris installed really that bloated that it has to drop back into a text-mode installer if it has "only" than 256MB ?!?
Probably a not-totally-conformant CD drive that may not be "offically" supported under Solaris.
It's a plain ATAPI drive... What happened was that after the boot the installer asked for CD #2, and I accidentally inserted #3. Of course it complained, but it refused to eject it! Even the button on the drive was ignored. Typing eject into a second dterm didn't do anything either. Time for a paperclip. After putting CD #2 in, it didn't recognize that one either. Eventually I clicked skip, then the installer asked for #3. After putting that in, it got ignored. Rebooting (without a CD) brought me back (after a while) to the installer asking for #3. No way to convince it to go back to #2... Eventually, I had to start over. There goes a Saturday afternoon!
You don't have to copy the packages. "pkgadd -d ..." works fine.
I noticed this option, but pkgadd seemed to consistently ignore it...
"boot -s" or something similar from the OK> prompt will get you to single-user mode.
Didn't try that one. This will be useful for the next time. Thanks.
No idea. The Sun hardware I work on is off in a server room - and I've never used USB keyfobs or similar on Solaris.
Keyfobs are handy to transfer the network driver to the Solaris box if you don't want to burn a CD (which is still slower to burn than simply write the stuff on the fob)
Hmmm, but then, "dyed in the wool MySql DBA's" will tend to stick with Linux and MySql instead... And "dyed in the wool Sequel Server DBA's" would likewise stick with Windows...