Last night (2017.08.22) there was an announcement that there was a
bouncing baby new update release for
npm so I
attempted to install it:
npm i npm -g
/home/candycane/.npm-g/bin/npm -> /home/candycane/.npm-g/lib/node_modules/npm/bin/npm-cli.js
/home/candycane/.npm-g/bin/npx -> /home/candycane/.npm-g/lib/node_modules/npm/bin/npx-cli.js
+ npm@5.3.0
updated 1 package in 14.971s
That... only took 15 seconds versus the now anticipated (and fairly normal) half hour. It's supposed to be... v.5.4.0, but that says 5.3.0 as does
npm -v. *?*
So I just set it to the side and moved on to attempting to get
hsfconfig to actually config my HSF modem. Yeah, I know ~~~~> *ewwwww*
A long time ago, I had that all working. Unfortunately there have been a number of hard drive crashes during times when I couldn't afford backup supplies. That meant I lost all my notes including some seriously tear stained ones about the whole HSF modem process. *sighhhh*
Things I can still remember to do include popping over to
Linmodems, catching up on their methodology, and then attempting to apply it to my user specific setup. This also coincidentally came up on
Debian-User. I need to finally read all the way through and see what they ended with as a final outcome there at Debian.
It feels like that was the thread where it was suggested to the OP (original poster) that their time would be better spent just buying a hardware based modem instead of fighting this many years' long issue. I am more like the OP in this case. I have learned a ton of shtuff while fighting... this very specific and very many years' long proprietary software issue.
Somewhere in the middle of all this, I got the bright idea to additionally... take this opportunity to self-teach on how to
mangle install... the latest
stable Linux kernel offering from kernel.org.
Yeah, I don't know, either. I guess the mischievous little elves twiddling their thumbs somewhere in the back of my mind decided I just hadn't flocked things up enough yet.
So where that's at this second is that last night I started following the destructions on the
KernelBuild Guide to building the Linux kernel page k/t
kernelnewbies. Even posted my first post on their listserv last night, mostly a quick recap of my own current path and a few related links if I'm remembering correctly.
Their
KernelBuild notes seem to do the trick. I had spent over an hour the night before trying to find something, anything that was cognitively friendly. That search eventually and finally pointed back to
kernelnewbies whom I had just found days before that. *here's your sign*
It takes many hours to attempt this, but most of that time is you giving your computer its head... while you go out to see a movie. #Life Lesson learned on the fly is that you probably better make that movie a double feature.
The preliminary steps include installing some additional software that occasionally involves a "dev", as in developer development type, identifier. For most people, that install step is pretty painless these days.
Years ago *for me*, that step was a show stopper because those packages had to be built from scratch. Invariably those show stoppers would fail more often than not and for nearly every reason known under the Sun. Except that, uh-uh, nuh-uhhh, they did
not have to be built from scratch, even back then.
What I didn't understand back then was how many Linux distributions work. The installation process is semi-automatic these days. The user's only chore in most cases is to decide what they'd like to see installed on their computers. After that, their favorite package manager takes over and completes the process.
For me, that "
package manager" is
apt-get. A browser's CTRL+F or similar "find" feature used on the words "package manager" will land a few viable alternatives on Debian's
admin packages subsection.
That admin packages subsection is specifically for
Debian Buster Testing which is the release that I'm using right now. To switch to another release's similar page, it's as simple as replacing the word "buster" in the link, the URL, with others like
stretch,
jessie,
wheezy, and
sid. That's a very nice feature that saves wear and tear on their servers, for one thing, because web surfers don't have to mess around with in between links to get what we need.
Ok. Newly churned up Linux kernel. It's apparently done. It rumbled on for a
long time throughout the night. That part comes from the mix of deciding on your .config file choice and then performing the
make command. I went the
cp /boot/config-`uname -r`* .config to snag my existing,
working config file and then simply ran
make.
That secondarily suggested
make -jX deal felt like it did something funky. I canned it, ran
make clean, and tried it again just as
make. I'll read up on it one of these days if going that route suddenly becomes a tweak that I need to do to help chug things along a little faster than last night. #toDo. :)
The only thing I had to do when I got up this morning was:
sudo make modules_install install
The KernelNewbies author rambles a second there about install options, but that specific line worked perfectly fine on my end. I started out by verifying the potential existence of the author's "installkernel" reference.
locate installkernel said, "Yup, it's there." Implementing the related
sudo make modules_install install command took
way less time than the initial compile, but it still took a while.
AND... it went ahead and ran
update-grub while it was at it. That's a nice perk, Debian. #ThankYou :)
Now I need to
reboot. What they're saying there at the end about
reboot'ing is that you need to know how to seriously manipulate whatever controls your boot process.
After the "installkernel" process, I checked my /boot/grub/grub.cfg. There were references to both kernels now residing on that partition which reminds me there's still one more step left. All my manually created possibilities in /etc/grub.d/40_custom were in the house, too.
That means it's almost time to attempt a
reboot. That thing that I was just reminded of, though, was that I need to go in as root... and point /vmlinuz and /initrd.img at the new configuration files. That's done with symlinking. As example,
*I* manually perform that action via
ln -s boot/initrd.img-4.12.8 initrd.img while sitting in the root directory followed immediately with similar for
vmlinuz.
Next step is to verify that the size of the symlinks matches the file they each respectively point to in the /boot directory. If their sizes don't match, that's my sign that something went wrong with the symlinking.
Today's new symlinks
do match up right, but, wow, what a difference in size. The old /initrd.img was 18.7MB, and the new one... is a whopping 249.9MB! OUCH!
#1 I wonder how that will affect boot up time. #2 is that I understand that it's because(y) I did the whole raw kernel deal. The smaller, previous one was basically pre-existing somehow with respect to being only AMD64 indicated. *that makes sense* :)
I really need to stop,
reboot, and test it. That's scary... is what that is...... but here I go-o-o-o-o!!
!!!!****WOOHOO, IT WORKS****!!!!
There didn't seem to be a significant time lag in the bootup time, either. I did catch one heart stopping flash on the screen where it said......
RIP
NO JOKE. I actually gasped as that flipped by. I don't know what it had to do with, and I'm in too much forward motion right now to attempt to track it down via a
grep in hopes of tripping over a log containing that very small word.
NOW... I am... what am I doing? Oh, installing the latest
opera-beta browser. Again, yeah, I know. It seems like almost every browser has its detractors these days. That one is working more often than the rest do on dialup
for *ME* so there you go.
In the process of installing that, I just realized what a message had been telling me before. The way I've been installing
opera is to go to their website, manually download the latest update (via
wget -c [Internet-path-to-file])
if one exists for Linux, and then
dpkg -i [entire-package-name] from within the archive's new home directory.
While running
dpkg -i, the first window says:
│ Opera can configure your system to include new versions of the Opera
│ package together with the regular system upgrades. Enabling this option
│ is highly recommended to make sure you receive critical security updates
│ in a timely manner.
│
│ If you agree, Opera will install a file into /etc/apt/sources.list.d, so
│ that the Opera package is upgraded to any available newer release as
│ part of your regular system upgrade.
│
│ Do you want to update Opera together with the rest of the system?
To which I each time emphatically have replied, "
OMG, YOU WANT TO DO WHAT WHERE?!?!?!"
*heh*
As of my experience with installing
npm and
nodejs recently... *I'm over it*
What that wants to do is create a file that points to the repository that contains the files, the
opera/
opera-beta archives, exactly like the ones I've been manually downloading when I remember to do so. This was a #Life Lesson learned on the fly this past week when I stumbled over where
nodejs had quietly installed /etc/apt/sources.list.d/nodesource.list in my file hierarchy. *ok, now I see*
So now I understand more. And I'm going to go the route of letting
opera do what
nodejs did. My poor Debian is no longer a pure anything, but it's working, and I'm talking about resources I trust because of how high profile they are right now. #doneDeal.
This is the end result of what it all has my permission to do (until further notice):
The image is depicting that my /etc/apt/sources.list.d directory now contains both nodesource.list and opera-beta.list. Let's hope I continue to remember that I played an active role in how they got there.... :)
After
dpkg -i [full-package-name] came that gut wrenching moment where you open the browser up... and there was that brand new window... with not one single one of my old currently-in-use tabs to be found. *cr4p*
Took me a few seconds to decide to go to the /home/[user] directory (via file manager
thunar) and nose around for anything that looked familiar. CTRL+H to display hidden files and directories unearthed .cache and .config. I hit up .cache first, but only for a few seconds after I remembered it's one directory I block during my
rsync backups. That means it's not a player here.
Next I went into .config, and there they sat... side-by-side...
opera and
opera-beta with their own,
separate directories. That means
opera-beta created its own whole new thing and that I now need to figure out how to move my old history into that directory.
First way I thought to do so was to simply copy and paste as myself. That failed. Quick instant memory recall was that copy and paste found some special files that I couldn't copy over as a normal user. Had I tried to do so as root, that
might have worked but would then ultimately fail. My experience is that root plants its hardcore (inaccessible) permissions on files it copies and pastes via right click yada-yada.
Enter
rsync which handles special files most fabulously. And that's exactly what it did because
opera-beta began to immediately display my previous tabs and bookmarks afterward. We are so talking
*SCORE*!
On that high note, I do believe that I'm going to take a break. My brain's not sure where to go next after all this successfully successful success this morning. *kvell-kvell!*
* to be continued.......... *
