Neil Bothwick wrote:
> On Wed, 18 Mar 2020 16:46:35 -0700, Ian Zimmerman wrote:
>
>> On 2020-03-18 18:25, Dale wrote:
>>
>>> BTW, can a label be changed without redoing the file system? I seem to
>>> recall that being done during the file system creation.
>> Yes, e2label for ext[2-4] , fatlabel
On Wed, 18 Mar 2020 16:46:35 -0700, Ian Zimmerman wrote:
> On 2020-03-18 18:25, Dale wrote:
>
> > BTW, can a label be changed without redoing the file system? I seem to
> > recall that being done during the file system creation.
>
> Yes, e2label for ext[2-4] , fatlabel for vfat. Don't know
On 2020-03-18 18:25, Dale wrote:
> BTW, can a label be changed without redoing the file system? I seem to
> recall that being done during the file system creation.
Yes, e2label for ext[2-4] , fatlabel for vfat. Don't know about others
but probably most of them allow something similar.
--
Ian
Ian Zimmerman wrote:
> On 2020-03-18 22:57, n952162 wrote:
>
>> Well, some new recognitions ...
>>
>> It turns out that those /dev/disk subdirectories don't necessarily have
>> all the disk devices represented:
>>
>> 1. by-id/
>> 2. by-partuuid/
>> 3. by-path/
>> 4. by-uuid/
> There is also
On 2020.03.18 18:59, Ian Zimmerman wrote:
After a hiatus I am trying to create my own ebuild repository again.
I
need a way to test the separate steps (fetch, prepare, comiple,
install
etc.) and I would like to do all of them as a regular user (not root,
not portage). I tried what I
On 2020-03-18 22:57, n952162 wrote:
> Well, some new recognitions ...
>
> It turns out that those /dev/disk subdirectories don't necessarily have
> all the disk devices represented:
>
> 1. by-id/
> 2. by-partuuid/
> 3. by-path/
> 4. by-uuid/
There is also by-label, which you can reference from
After a hiatus I am trying to create my own ebuild repository again. I
need a way to test the separate steps (fetch, prepare, comiple, install
etc.) and I would like to do all of them as a regular user (not root,
not portage). I tried what I thought was the most natural attempt - run
the ebuild
Well, some new recognitions ...
It turns out that those /dev/disk subdirectories don't necessarily have
all the disk devices represented:
1. by-id/
2. by-partuuid/
3. by-path/
4. by-uuid/
On my computer, only by-id/ - the subdirectory that's not set up in time
- has links to /dev/sda?.
On Wed, 18 Mar 2020 10:47:12 -0400, Rich Freeman wrote:
> > If you rely on raid, and use spinning rust, DON'T buy cheap drives. I
> > like Seagate, and bought myself Barracudas. Big mistake. Next time
> > round, I bought Ironwolves. Hopefully that system will soon be up and
> > running, and I'll
On Wednesday, 18 March 2020 19:02:56 GMT n952162 wrote:
> Incidentally, in order to debug that, I set the /etc/rc.conf *rc_logger*
> variable to YES:
>
> rc_logger="YES"
>
> I'm not sure why that's not the default, as it appears to be on ubuntu,
> assuming that similar-seeming functionality
Incidentally, in order to debug that, I set the /etc/rc.conf *rc_logger*
variable to YES:
rc_logger="YES"
I'm not sure why that's not the default, as it appears to be on ubuntu,
assuming that similar-seeming functionality really is similar.
On 2020-03-18 19:35, n952162 wrote:
Okay, after
Okay, after many hours of investigation and experimentation, I finally
figured this out.
For many years now, I have written my /etc/fstab using the
/dev/disk/by-id directory, because I think it's easier to keep track of
the names there - it's the only way to do it symbolically.
It's always
I tried that and it failed with: openrc-run may not run directly
On 2020-03-17 14:14, Neil Bothwick wrote:
On Tue, 17 Mar 2020 13:37:52 +0100, n952162 wrote:
Question 2: how can one see the output from the RC "e-trace" statements
(e.g. ebegin/eend)?
I don't find it in /var/log/*
How about:
antlists wrote:
> On 17/03/2020 11:54, madscientistatlarge wrote:
>> The issue is not usually end of trusted life, but rather random
>> failure. I've barely managed to recover failed hard drives, That is
>> less likely on SSD though possibly less likely to happen.
>
> The drive may be less likely
On 17/03/2020 05:59, tu...@posteo.de wrote:
Hi,
currentlu I am setting up a new PC for my 12-years old one,
which has reached the limits of its "computational power" :)
SSDs are a common replacement for HDs nowaday -- but I still trust my
HDs more than this "flashy" things...call me retro or
On Wed, Mar 18, 2020 at 7:47 AM Rich Freeman wrote:
>
> It might be cheaper to just get three drives with 3x
> redundancy than two super-expensive ones with 2x redundancy.
>
If someone goes this direction then try to get the drives from multiple
sales channels to reduce the probability of all
On Wed, Mar 18, 2020 at 9:49 AM antlists wrote:
>
> On 17/03/2020 14:29, Grant Edwards wrote:
> > On 2020-03-17, Neil Bothwick wrote:
> >
> >> Same here. The main advantage of spinning HDs are that they are cheaper
> >> to replace when they fail. I only use them when I need lots of space.
> >
>
On 17/03/2020 14:29, Grant Edwards wrote:
On 2020-03-17, Neil Bothwick wrote:
Same here. The main advantage of spinning HDs are that they are cheaper
to replace when they fail. I only use them when I need lots of space.
Me too. If I didn't have my desktop set up as a DVR with 5TB of
On 17/03/2020 11:54, madscientistatlarge wrote:
The issue is not usually end of trusted life, but rather random failure. I've
barely managed to recover failed hard drives, That is less likely on SSD though
possibly less likely to happen.
The drive may be less likely to fail, but I'd say
Hi,
On mar. 17 mars 15:47:36 2020, the...@sys-concept.com wrote:
> How to block in .htaccess file certain IP range?
>
> I have bot from huawei.com on my server for several days:
> IP: 114.119.128.0 - 114.119.191.255
> Or just block all China
In a case like this, I’m not trying to bother about
Hello, an addendum without digging up the details ...
On Tue, 17 Mar 2020, David Haller wrote:
>On Tue, 17 Mar 2020, Grant Edwards wrote:
>>I've put five Samsung SATA drives into various things in the past few
>>years with flawless results. Samsung is one of the big manufacturers
>>of flash
21 matches
Mail list logo