IDE drive seen as sda; now I'm stuck

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

IDE drive seen as sda; now I'm stuck

Mike Spencer

This may sound complicated but it may not be so very much so if you
know more than I do.

Machine 1 has a native SATA HD and IDE connectors as well.

Installed new Linux (SLackware 14.2) on the SATA HD. All in order.

Connected a 500 G IDE drive to an IDE connector and installed new
Linux on it, too.   The system saw the IDE drive as /dev/sdb, i.e as
if it were a SATA drive. I don't understand why but I carried on.
Install proceeded as expected.

Using the CMOS menu ("hit F12 for boot options"), I can choose from

     + onboard SATA drive
     + onboard IDE drive
     + onboard DVD
     + onboard floppy

Choosing "onboard IDE drive" from the menu, the system boots from the
IDE drive. So the CMOS is seeing it as IDE even though Linux thinks
it's a SATA.  All is well with the new install on the IDE drive.

Transfer ~/*, archival data, make numerous tweaks.  Still boots & runs
fine.

Now I move that IDE HD to another machine, Machine 2, whose HD was
native IDE, connect it to IDE connectors.  Boot fails.  (Expected.
I'll come back to this.)

Booting from an install DVD, as root, cfdisk sees the new IDE HD as sda.
cfdisk says there *is* no hda.  What?  Not as expected.

I had expected that this HD would be seen, when plugged into Machine
2, as hda.  I had expected to boot from DVD, edit lilo.conf to have:

    boot = /dev/hda

    image = /boot/vmlinuz
      root = /dev/hda3

and run lilo.  But because the system only sees sda, lilo won't do
this. "Fatal: open /dev/hda: No such device..."

How do I make Machine 2 see this HD as hda?

I don't know where the data bits reside that causes the HD to be seen
as sda when connected to an IDE plug in a machine that was IDE native
from the start.

The MBR itself doesn't contain any references to "sda" or "hda" but
lilo must have put that data somewhere when the IDE drive was running
on Machine 1.  And Machine 2 failed to boot (I'm guessing here)
because of it?

Would (from a DVD boot) doing

    mount -t ext4 /dev/sda3 /mnt
    chroot /mnt
    lilo -b /dev/sda

but with the hda lines above in lilo.conf fix it on reboot?

Sounds like a shot in the dark: -b forces *write* to (what is
presently) sda but lilo would need to find location data for hda when,
as far as lilo can tell, hda doesn't exist.  

Running lilo -v -t -b /dev/sda (-t == dry-run) produces warnings but
none relevant to the problem.

I *reallly* don't understand this sda vs. hda business.
/proc/partitions doesn't exist under a DVD rescue boot.  Where does
the kernel get the data for /proc/partitions at boot time?  Can I
change that?


I really *really* don't want to do the partitioning over because I
have many hours into transferring data and doing something like 50
separate tweaks to configure everything, a tedious and painstaking
task.

Help?

--
Michael Spencer                  Nova Scotia, Canada


_______________________________________________
nSLUG mailing list
[hidden email]
http://nslug.ns.ca/mailman/listinfo/nslug
Reply | Threaded
Open this post in threaded view
|

Re: IDE drive seen as sda; now I'm stuck

George N. White III


On Sat, 26 Oct 2019 at 03:02, Mike Spencer <[hidden email]> wrote:

This may sound complicated but it may not be so very much so if you
know more than I do.

Machine 1 has a native SATA HD and IDE connectors as well.

Installed new Linux (SLackware 14.2) on the SATA HD. All in order.

Connected a 500 G IDE drive to an IDE connector and installed new
Linux on it, too.   The system saw the IDE drive as /dev/sdb, i.e as
if it were a SATA drive. I don't understand why but I carried on.
Install proceeded as expected.

See: https://unix.stackexchange.com/questions/2447/names-for-ata-and-sata-disks-in-linux

Using the CMOS menu ("hit F12 for boot options"), I can choose from

     + onboard SATA drive
     + onboard IDE drive
     + onboard DVD
     + onboard floppy

Choosing "onboard IDE drive" from the menu, the system boots from the
IDE drive. So the CMOS is seeing it as IDE even though Linux thinks
it's a SATA.  All is well with the new install on the IDE drive.

Both IDE and SATA are sdX to many recent linux distros.   

Transfer ~/*, archival data, make numerous tweaks.  Still boots & runs
fine.

Now I move that IDE HD to another machine, Machine 2, whose HD was
native IDE, connect it to IDE connectors.  Boot fails.  (Expected.
I'll come back to this.)

Booting from an install DVD, as root, cfdisk sees the new IDE HD as sda.
cfdisk says there *is* no hda.  What?  Not as expected.

I had expected that this HD would be seen, when plugged into Machine
2, as hda.  I had expected to boot from DVD, edit lilo.conf to have:

    boot = /dev/hda

    image = /boot/vmlinuz
      root = /dev/hda3

and run lilo.  But because the system only sees sda, lilo won't do
this. "Fatal: open /dev/hda: No such device..."

How do I make Machine 2 see this HD as hda?

You don't, it is sda.

I don't know where the data bits reside that causes the HD to be seen
as sda when connected to an IDE plug in a machine that was IDE native
from the start.

The MBR itself doesn't contain any references to "sda" or "hda" but
lilo must have put that data somewhere when the IDE drive was running
on Machine 1.  And Machine 2 failed to boot (I'm guessing here)
because of it?

Would (from a DVD boot) doing

    mount -t ext4 /dev/sda3 /mnt
    chroot /mnt
    lilo -b /dev/sda

but with the hda lines above in lilo.conf fix it on reboot?

Sounds like a shot in the dark: -b forces *write* to (what is
presently) sda but lilo would need to find location data for hda when,
as far as lilo can tell, hda doesn't exist. 

Running lilo -v -t -b /dev/sda (-t == dry-run) produces warnings but
none relevant to the problem.

I *reallly* don't understand this sda vs. hda business.
/proc/partitions doesn't exist under a DVD rescue boot.  Where does
the kernel get the data for /proc/partitions at boot time?  Can I
change that?

Does  Slackware 14.2 have udev or eudev?  See
 

I really *really* don't want to do the partitioning over because I
have many hours into transferring data and doing something like 50
separate tweaks to configure everything, a tedious and painstaking
task.

Use "sda" instead of "hda".

--
George N. White III


_______________________________________________
nSLUG mailing list
[hidden email]
http://nslug.ns.ca/mailman/listinfo/nslug
Reply | Threaded
Open this post in threaded view
|

Re: IDE drive seen as sda; now I'm stuck

Joel Maxwell
Absolutely correct.  The Linux kernel dropped the hdX naming scheme
around version 3.x.  IDE/PATA and SATA controllers become too similar
to each other in driver code and the distinct monikers didn't make
sense for multiple reasons.

Though because of that rationale I am not sure why mmcblkNpM nodes ever
came into existence.

--
Regards,
Joel Maxuel

On Sat, 2019-10-26 at 09:13 -0300, George N. White III wrote:

>
>
> On Sat, 26 Oct 2019 at 03:02, Mike Spencer <[hidden email]>
> wrote:
> > This may sound complicated but it may not be so very much so if you
> > know more than I do.
> >
> > Machine 1 has a native SATA HD and IDE connectors as well.
> >
> > Installed new Linux (SLackware 14.2) on the SATA HD. All in order.
> >
> > Connected a 500 G IDE drive to an IDE connector and installed new
> > Linux on it, too.   The system saw the IDE drive as /dev/sdb, i.e
> > as
> > if it were a SATA drive. I don't understand why but I carried on.
> > Install proceeded as expected.
>
> See: https://unix.stackexchange.com/questions/2447/names-for-ata-and-
> sata-disks-in-linux
> > Using the CMOS menu ("hit F12 for boot options"), I can choose from
> >
> >      + onboard SATA drive
> >      + onboard IDE drive
> >      + onboard DVD
> >      + onboard floppy
> >
> > Choosing "onboard IDE drive" from the menu, the system boots from
> > the
> > IDE drive. So the CMOS is seeing it as IDE even though Linux thinks
> > it's a SATA.  All is well with the new install on the IDE drive.
>
> Both IDE and SATA are sdX to many recent linux distros.    
> > Transfer ~/*, archival data, make numerous tweaks.  Still boots &
> > runs
> > fine. 
> >
> > Now I move that IDE HD to another machine, Machine 2, whose HD was
> > native IDE, connect it to IDE connectors.  Boot fails.  (Expected.
> > I'll come back to this.)
> >
> > Booting from an install DVD, as root, cfdisk sees the new IDE HD as
> > sda.
> > cfdisk says there *is* no hda.  What?  Not as expected.
> >
> > I had expected that this HD would be seen, when plugged into
> > Machine
> > 2, as hda.  I had expected to boot from DVD, edit lilo.conf to
> > have:
> >
> >     boot = /dev/hda
> >
> >     image = /boot/vmlinuz
> >       root = /dev/hda3
> >
> > and run lilo.  But because the system only sees sda, lilo won't do
> > this. "Fatal: open /dev/hda: No such device..."
> >
> > How do I make Machine 2 see this HD as hda?
>
> You don't, it is sda.
> > I don't know where the data bits reside that causes the HD to be
> > seen
> > as sda when connected to an IDE plug in a machine that was IDE
> > native
> > from the start.
> >
> > The MBR itself doesn't contain any references to "sda" or "hda" but
> > lilo must have put that data somewhere when the IDE drive was
> > running
> > on Machine 1.  And Machine 2 failed to boot (I'm guessing here)
> > because of it?
> >
> > Would (from a DVD boot) doing
> >
> >     mount -t ext4 /dev/sda3 /mnt
> >     chroot /mnt
> >     lilo -b /dev/sda
> >
> > but with the hda lines above in lilo.conf fix it on reboot?
> >
> > Sounds like a shot in the dark: -b forces *write* to (what is
> > presently) sda but lilo would need to find location data for hda
> > when,
> > as far as lilo can tell, hda doesn't exist.  
> >
> > Running lilo -v -t -b /dev/sda (-t == dry-run) produces warnings
> > but
> > none relevant to the problem.
> >
> > I *reallly* don't understand this sda vs. hda business.
> > /proc/partitions doesn't exist under a DVD rescue boot.  Where does
> > the kernel get the data for /proc/partitions at boot time?  Can I
> > change that?
> >
>
> Does  Slackware 14.2 have udev or eudev?  See
> https://www.linuxquestions.org/questions/slackware-14/switching-from-
> udev-to-eudev-4175559368/
>  
> > I really *really* don't want to do the partitioning over because I
> > have many hours into transferring data and doing something like 50
> > separate tweaks to configure everything, a tedious and painstaking
> > task.
>
> Use "sda" instead of "hda".
>
> _______________________________________________
> nSLUG mailing list
> [hidden email]
> http://nslug.ns.ca/mailman/listinfo/nslug
_______________________________________________
nSLUG mailing list
[hidden email]
http://nslug.ns.ca/mailman/listinfo/nslug
Reply | Threaded
Open this post in threaded view
|

Re: IDE drive seen as sda; now I'm stuck

Mike Spencer
In reply to this post by George N. White III

George wrote:

> Both IDE and SATA are sdX to many recent linux distros.

That's the key bit I didn't know!  All well now.  Boot successful,
basic functionality and all data available.

I had painted^H^H^H^H^H^H^H configured myself into a corner, assuming
that the IDE-native hardware would compel hdX designations.

I *have* installed newer kernels but this is the first time in years
that I had to jocky a HD around between different computers to get
where I needed to be.

Tnx,
- Mike
_______________________________________________
nSLUG mailing list
[hidden email]
http://nslug.ns.ca/mailman/listinfo/nslug
Reply | Threaded
Open this post in threaded view
|

Re: IDE drive seen as sda; now I'm stuck

Dop Ganger
In reply to this post by Mike Spencer
On Sat, 26 Oct 2019, Mike Spencer wrote:

> How do I make Machine 2 see this HD as hda?

Use disk= to define a disk as a specific BIOS id (possibly with the
assistance of "static-BIOS-codes"). Alternatively set up multiple boot
stanzas, each referencing one possibility that may boot (/dev/sda,
/dev/sdb, /dev/hda, /dev/hdb) and then you just have to iterate over the
combinations to see which boots.

Alternatively alternatively, if your lilo is new enough use the volume ID,
details at https://github.com/a2o/lilo/blob/master/readme/README.volumeID

Cheers... Dop.
_______________________________________________
nSLUG mailing list
[hidden email]
http://nslug.ns.ca/mailman/listinfo/nslug
Reply | Threaded
Open this post in threaded view
|

Re: IDE drive seen as sda; now I'm stuck

Oliver Doepner
Legacy IDE drivers - the ones that use/dev/hdx - are on the way out.

LibATA is the modern IDE support layer, has been around for ages and
uses the /dev/sdx naming scheme.

See this article,for example:

https://www.phoronix.com/scan.php?page=news_item&px=Linux-Legacy-IDE-Deprecated

On 10/29/19, Dop Ganger <[hidden email]> wrote:

> On Sat, 26 Oct 2019, Mike Spencer wrote:
>
>> How do I make Machine 2 see this HD as hda?
>
> Use disk= to define a disk as a specific BIOS id (possibly with the
> assistance of "static-BIOS-codes"). Alternatively set up multiple boot
> stanzas, each referencing one possibility that may boot (/dev/sda,
> /dev/sdb, /dev/hda, /dev/hdb) and then you just have to iterate over the
> combinations to see which boots.
>
> Alternatively alternatively, if your lilo is new enough use the volume ID,
> details at https://github.com/a2o/lilo/blob/master/readme/README.volumeID
>
> Cheers... Dop.
> _______________________________________________
> nSLUG mailing list
> [hidden email]
> http://nslug.ns.ca/mailman/listinfo/nslug
>


--
--
Oliver Doepner
http://odoepner.github.io/
_______________________________________________
nSLUG mailing list
[hidden email]
http://nslug.ns.ca/mailman/listinfo/nslug
Reply | Threaded
Open this post in threaded view
|

IDE drive seen as sda; now I'm stuck

Mike Spencer

> Legacy IDE drivers - the ones that use/dev/hdx - are on the way out.


Yes.  I've now had this all explained to me at great length on
alt.os.linux.slackware.

I had a misconcepton that something in the hardware would determine
whether Linux saw a HD as sda or hda.  So I configured the HD in the
machine on which it was mounted when I did the new system install.
That machine was native SATA.

But I configured everything -- lilo.conf, /etc/fatsb -- as if, once
plugged into the destination machine (that was native-PATA) it would
be seen as hda.

All fixed now.  Boots fine  into sda3 as /.

Other problems, though.  E.g. /etc/rc.d/rc.inet1.conf has data filled
in for eth0.  The relevant udev file references eth0.  But after boot,
dmesg has lines about renaming "eth126 renamed from eth0" and "eth1
renamed from eth126.  And there's no inetd available.  Say what?!

Unless I go into rc.inet1.conf and populate the eth1 entry with the
desired 192.168.0.n address -- the same one already set for eth0 -- and
mask.  Then inetd is good after inetd restart.

Why is this happening?  It ain't never done that before.

(This machine has no wireless so wlan0 isn't an issue.)

There's more -- some bother with sendmail fr'gzample, but one thing
at a time, eh?

-m
--
Michael Spencer                  Nova Scotia, Canada
_______________________________________________
nSLUG mailing list
[hidden email]
http://nslug.ns.ca/mailman/listinfo/nslug
Reply | Threaded
Open this post in threaded view
|

Re: IDE drive seen as sda; now I'm stuck

Dop Ganger
On Wed, 30 Oct 2019, Mike Spencer wrote:

>> Legacy IDE drivers - the ones that use/dev/hdx - are on the way out.

Don't listen to him, Mike, you can make this system last a little bit
longer I'm sure!

> I had a misconcepton that something in the hardware would determine
> whether Linux saw a HD as sda or hda.  So I configured the HD in the
> machine on which it was mounted when I did the new system install.
> That machine was native SATA.

Weeeeeell yes and no. There are ways to force the kernel into thinking
(eg) /dev/sda is called /dev/hda but they are brittle and prone to
failure. I think you're probably best off looking at UUIDs instead. Take a
look at
https://docs.slackware.com/howtos:slackware_admin:how_to_configure_fstab_and_lilo.conf_with_persistent_naming 
and see if that does the trick, if you are considering making a drive you
can bounce around systems.

The advantage of persistent naming is that lilo will boot from a partition
with a unique UUID, wherever the partition is. The disadvantage of
persisitent naming is that lilo will boot from a partition with a unique
UUID, *wherever* the partition is.

> Other problems, though.  E.g. /etc/rc.d/rc.inet1.conf has data filled
> in for eth0.  The relevant udev file references eth0.  But after boot,
> dmesg has lines about renaming "eth126 renamed from eth0" and "eth1
> renamed from eth126.  And there's no inetd available.  Say what?!

I think you need to disable persistent naming.
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ 
has some gory details on what and why, the section you want is "I don't
like this, how do I disable this?" - probably setting net.ifnames=0 on the
kernel command line.

> There's more -- some bother with sendmail fr'gzample, but one thing
> at a time, eh?

Oh, there's always bother in the sendmail stand.

Cheers... Dop.
_______________________________________________
nSLUG mailing list
[hidden email]
http://nslug.ns.ca/mailman/listinfo/nslug
Reply | Threaded
Open this post in threaded view
|

Re: IDE drive seen as sda; now I'm stuck

Oliver Doepner
Dop,

As far as I understand, Mike already has the drive working with sdx
device name and using the default libata driver.

Not sure why anyone would insist on lots of config work to force the
use of a legacy driver and an outdate naming standard?

Cheers
Oliver


--
--
Oliver Doepner
http://odoepner.github.io/
_______________________________________________
nSLUG mailing list
[hidden email]
http://nslug.ns.ca/mailman/listinfo/nslug
Reply | Threaded
Open this post in threaded view
|

Re: IDE drive seen as sda; now I'm stuck

Ben Armstrong-2
Because he can ... and it will make him happy? ... I assume. But that's Mike's choice. It's just encouraging to hear from Dop that not all choices by Linux devs that are seemingly foisted off on users who were happy with the status quo need to be just tolerated with disgruntlement, even if Mike decides it's already a "done deal" and not worth further effort.

Ben

On Thu, Oct 31, 2019 at 7:40 AM Oliver Doepner <[hidden email]> wrote:
Dop,

As far as I understand, Mike already has the drive working with sdx
device name and using the default libata driver.

Not sure why anyone would insist on lots of config work to force the
use of a legacy driver and an outdate naming standard?

Cheers
Oliver


--
--
Oliver Doepner
http://odoepner.github.io/
_______________________________________________
nSLUG mailing list
[hidden email]
http://nslug.ns.ca/mailman/listinfo/nslug

_______________________________________________
nSLUG mailing list
[hidden email]
http://nslug.ns.ca/mailman/listinfo/nslug
Reply | Threaded
Open this post in threaded view
|

Re: IDE drive seen as sda; now I'm stuck

Dop Ganger
On Thu, 31 Oct 2019, Ben Armstrong wrote:

> Because he can ... and it will make him happy? ... I assume. But that's Mike's choice.

Exactly. And Mike has a history of... well loved hardware being kept alive
as long as possible, so it's not beyond the bounds of probability that the
drive will migrate around. Ultimately I am generally averse to the popular
movement to turf old hardware and replace it with new every few years, and
I'm not convinced that the argument that the greater power usage justifies
new hardware (in which case, why aren't we all on Raspberry Pis?).

On an unrelated note, *is* that you I see regularly on the Mainland trails
and BLT inspecting foliage, or is there someone out there wondering why on
earth some cyclist keeps calling them Ben?

Cheers... Dop.
_______________________________________________
nSLUG mailing list
[hidden email]
http://nslug.ns.ca/mailman/listinfo/nslug
Reply | Threaded
Open this post in threaded view
|

Re: IDE drive seen as sda; now I'm stuck

Ben Armstrong-2
Less recently of late but otherwise, yes, that sounds like me. If I failed
to make any signs of recognition, please give it a try to connect the dots
for me next time. I'm often somewhat poor at putting names and faces of
people seen in completely different contexts together!

Ben

On October 31, 2019 9:00:19 a.m. Dop Ganger <[hidden email]> wrote:

> On Thu, 31 Oct 2019, Ben Armstrong wrote:
>
>> Because he can ... and it will make him happy? ... I assume. But that's
>> Mike's choice.
>
> Exactly. And Mike has a history of... well loved hardware being kept alive
> as long as possible, so it's not beyond the bounds of probability that the
> drive will migrate around. Ultimately I am generally averse to the popular
> movement to turf old hardware and replace it with new every few years, and
> I'm not convinced that the argument that the greater power usage justifies
> new hardware (in which case, why aren't we all on Raspberry Pis?).
>
> On an unrelated note, *is* that you I see regularly on the Mainland trails
> and BLT inspecting foliage, or is there someone out there wondering why on
> earth some cyclist keeps calling them Ben?
>
> Cheers... Dop.
> _______________________________________________
> nSLUG mailing list
> [hidden email]
> http://nslug.ns.ca/mailman/listinfo/nslug



_______________________________________________
nSLUG mailing list
[hidden email]
http://nslug.ns.ca/mailman/listinfo/nslug
Reply | Threaded
Open this post in threaded view
|

Re: IDE drive seen as sda; now I'm stuck

Oliver Doepner
The libata migration did not leave old hardware behind.

Not sure what you guys are going on about.

--
--
Oliver Doepner
http://odoepner.github.io/
_______________________________________________
nSLUG mailing list
[hidden email]
http://nslug.ns.ca/mailman/listinfo/nslug
Reply | Threaded
Open this post in threaded view
|

META, FYI, Wash Dog First (Re: IDE drive seen as sda)

Mike Spencer
In reply to this post by Ben Armstrong-2

This post qualifies as Meta, FYI, Wash Dog First.  No new problems
presented, new questions asked  or new solutions offered.

Oliver Doepner wrote:

od> As far as I understand, Mike already has the drive working with
od> sdx device name and using the default libata driver.

Yes.

od> Not sure why anyone would insist on lots of config work to force
od> the use of a legacy driver and an outdated naming standard?

to which Ben replied:

ben> Because he can ... and it will make him happy?

and Dop added:

dop> And Mike has a history of... well loved hardware being kept alive
dop> as long as possible...

Just for the record and for enteratinment purposes (for possibly boring
values of "entertainment" -- wash dog first etc.) here's how I got
into this.  Three elements conspired:

    + A technical problem on a mobo/CPU old enough that no one was
      likely to know a fix

    + That I was upgrading from Slackware 11, 2.4 kernel, ext2 f/s to
      Slackware 14.2, 4.x kernel, ext4 f/s.

    + My ignorance

I like this IBM MT-M 8193, P4 computer.  CPU & RAM adequate for my
needs.  It's IDE-native but has plugs on the mobo for SATA.  And the
IDE drive crashed. All of ~/* vanished.

Couldn't find an IDE HD, got a SATA drive and cables, plugged into one
of the mobo plugs, restored ~/ from backups and everything else from
the failed HD.  

All was well for years except that:

   + Copying large files to the HD blocked the CPU.  X became
     unresponsive, everything slowed to a crawl.  And the copying was  
     slow, too.

   + playing a DVD video caused the clock to lose ca. 20 min for a 2 hr
     movie.

Since these anomalies began with use of the onboard SATA capability
and I could turn up no other explanation, I inferred that it was a
problem with the (now very old hardware) IBM SATA support.  So I
planned to replace the SATA HD with an IDE HD.

And my reasons for clinging to Slack 11 were becoming invalid so I
thought to upgrade at the same time.

The upgrade gap was much too large to use Slackware's update utility
and it was complicated by the fact that a newly created ext4 f/s would
be unmountable by the old kernel that only knew ext2 & ext3.  Allso
copying all the data over the LAN or a USB-mounted HD would be very
slow.

So,

     + Upgrade a spare SATA-native machine where there was no
       important data.

     + Mount the new IDE HD on it, install the Linux system on it.
       Get the new HD so it would boot the spare machine.

     + Remove the native SATA drive from the spare machine, insert the
       SATA drive from my main computer. Copy ~/, all other data, do
       lots of config details on the new HD.

Here's where my ignorance came into play.  The new HD was seen in the
spare machine as sdb (when booting from its own HD) or sda (when
booting from the new system on the new HD).  But I thought this was due
to some hardware thing that I didn't understand.  So I assumed that,
once physically installed on the original, target IBM, it would *have*
to be hda -- that I would have to find a way to have it seen as hda
before it would be functional.

Ho hum.  I have now been enlightened about that.  The new IDE HD is
plugged into the IDE connector, is seen as sda, boots fine, data all
there, X and shells work.  

No report as yet on whether or not the two anomalies have been
corrected because there are yet several other config details to
resolve.

dop> Ultimately I am generally averse to the popular movement to turf
dop> old hardware and replace it with new every few years...

So am I.  This is where I repeat that my electric toaster is 106 years
old and working every day that the wood-fired kitchen range isn't
going.  :-)  Retiring our 40+ year old fridge was the right thing to
do.  Not so the decade+ old IBM.

ben> It's just encouraging to hear from Dop that not all choices by
ben> Linux devs that are seemingly foisted off on users who were happy
ben> with the status quo need to be just tolerated with
ben> disgruntlement, even if Mike decides it's already a "done deal"
ben> and not worth further effort.

So far, Linux developments haven't put me off my feed, if only I could
just keep abreast/aware of them.  I'm not qualified to opine on
systemd from a technical standpoint but from a user standpoint, I
already understand the scripts in /etc/rc.d, have (barely adequate)
working knowledge of sh/bash. I don't look forward to having to
understand a whole new method of managing config.  Not too happy with
udev but so far have managed not to be seriously annoyed.  Happily,
Slackware has not, as of 14.2, switched to systemd and no rumors from
Patrick V. suggest that the next release will either.

Emacs is another matter.  I thought perhaps it was time to bite the
bullet and move from GNU Emacs 20 to 24, not the most recent but the
version distributed with Slack 14.2.  I've just spent hours trying to
defeat numerous new features -- colorization, various highlighting,
changed behavior of some commands and of some buffer modes.  I'm a
little weak in lisp but with help from a Good Guy on gnu.emacs.help, a
whole gaggle of such features have been slain.  And now I find that it
wants to reformat all my email and Usenet files going back 30 years
(some ported in from former Unix accounts.)

I'm just about to give up and revert to Emacs 20.  First, I'll try
installing both versions and making 20 the default with symlinks.  If
that turns out to be can of worms, I'll go  with 20 alone.

Sent from my laptop, using Emacs 20.  Still don't have inetd, route,
dialup and sendmail working as desired on the new install.  Questions
to follow in other posts.

--
Michael Spencer                  Nova Scotia, Canada
_______________________________________________
nSLUG mailing list
[hidden email]
http://nslug.ns.ca/mailman/listinfo/nslug
Reply | Threaded
Open this post in threaded view
|

Re: META, FYI, Wash Dog First (Re: IDE drive seen as sda)

Dop Ganger
On Fri, 1 Nov 2019, Mike Spencer wrote:

> All was well for years except that:
>
>   + Copying large files to the HD blocked the CPU.  X became
>     unresponsive, everything slowed to a crawl.  And the copying was
>     slow, too.

https://www.flamingspork.com/projects/libeatmydata/ disables fsync for any
commands run under it, and markedly speeds up anything trying to
interleave reads and writes (rm -r in particular makes a difference). It's
called eatmydata because if the power goes out, data isn't synced and is
lost - it's up to the user to either wait for the system to flush out data
on its own according to the vagaries of /proc/sys/vm/dirty*, or run
sync(1).

As an aside, for Debian users, the following will do something similar
(but with a sync at the end) to make dpkg operations less of a pig:

echo force-unsafe-io > /etc/dpkg/dpkg.cfg.d/02apt-speedup

Cheers... Dop.
_______________________________________________
nSLUG mailing list
[hidden email]
http://nslug.ns.ca/mailman/listinfo/nslug