Hi All,

    Maybe I am a bit dense here, but the man page for "at"
is more than a bit confusing to me.

    What I want to do is run the follow two commands
as root at a specific time:

        su root -c "touch /forcefsck; reboot"

    How do I do that with "at"?

Many thanks,
-T

On Friday 27 January 2012 13:16, in comp.os.linux.misc, Todd@invalid.invalid
wrote:

> Hi All,
> 
>     Maybe I am a bit dense here, but the man page for "at"
> is more than a bit confusing to me.
> 
>     What I want to do is run the follow two commands
> as root at a specific time:
> 
>         su root -c "touch /forcefsck; reboot"
> 
>     How do I do that with "at"?

Not easily

Your su command will need access to a tty device (real or pseudo) in order
to acquire root's password. The at(1) command doesn't provide such a file.
This means that your su command will fail or hang, and won't get far enough
to process it's commandline.

Assuming that you remove such password protection around root, then you
could just
  echo 'su root -c "touch /forcefsck; reboot"' | at now + 5 minutes
to have the command executed in five minutes (substitute the appropriate
at(1) options for your intended schedule).

HTH
-- 
Lew Pitcher

On Friday 27 January 2012 13:43, in comp.os.linux.misc,
lpitcher@teksavvy.com wrote:

> On Friday 27 January 2012 13:16, in comp.os.linux.misc,
> Todd@invalid.invalid wrote:
> 
>> Hi All,
>> 
>>     Maybe I am a bit dense here, but the man page for "at"
>> is more than a bit confusing to me.
>> 
>>     What I want to do is run the follow two commands
>> as root at a specific time:
>> 
>>         su root -c "touch /forcefsck; reboot"
>> 
>>     How do I do that with "at"?
> 
> Not easily
> 
> Your su command will need access to a tty device (real or pseudo) in order
> to acquire root's password. The at(1) command doesn't provide such a file.
> This means that your su command will fail or hang, and won't get far
> enough to process it's commandline.
> 
> Assuming that you remove such password protection around root, then you
> could just
>   echo 'su root -c "touch /forcefsck; reboot"' | at now + 5 minutes
> to have the command executed in five minutes (substitute the appropriate
> at(1) options for your intended schedule).

A possible workaround of the su password problem:
  su root -c 'echo "touch /forcefsck; reboot" | at now + 5 minutes'
and answer the password request immediately

Note: I have not tried this; you may have to fiddle with the quotes (single
and double), and password prompt.

HTH
-- 
Lew Pitcher

Todd <Todd@invalid.invalid> writes:
>    Maybe I am a bit dense here, but the man page for "at"
> is more than a bit confusing to me.
>
>    What I want to do is run the follow two commands
> as root at a specific time:
>
>        su root -c "touch /forcefsck; reboot"
>
>    How do I do that with "at"?

Become root first, then run 'at'.

-- 
http://www.greenend.org.uk/rjk/

On 01/27/2012 11:10 AM, Richard Kettlewell wrote:
> Todd<Todd@invalid.invalid>  writes:
>>     Maybe I am a bit dense here, but the man page for "at"
>> is more than a bit confusing to me.
>>
>>     What I want to do is run the follow two commands
>> as root at a specific time:
>>
>>         su root -c "touch /forcefsck; reboot"
>>
>>     How do I do that with "at"?
>
> Become root first, then run 'at'.
>

an example?

On 2012-01-27, Todd <Todd@invalid.invalid> wrote:
>
>     What I want to do is run the follow two commands
> as root at a specific time:
>
>         su root -c "touch /forcefsck; reboot"

Is there a particular reason you do not wish to use cron?  Because doing
something at a specific time is easy with cron; I might use at when I
want to say "five minutes from now" but I'd use cron for "11pm every
other night".

--keith


-- 
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information

On 2012-01-27, Todd <Todd@invalid.invalid> wrote:
> Hi All,
>
>     Maybe I am a bit dense here, but the man page for "at"
> is more than a bit confusing to me.
>
>     What I want to do is run the follow two commands
> as root at a specific time:
>
>         su root -c "touch /forcefsck; reboot"

Well, the problem is that when you do that su to root, you will be asked
for a password. 
However you can su to root right now and then run at as root. 
at 9:45 Jun 14
at> touch /forcefsck; reboot
at>^D

(^D=control D)

>
>     How do I do that with "at"?
>
> Many thanks,
> -T

At Fri, 27 Jan 2012 13:45:34 -0500 Lew Pitcher <lpitcher@teksavvy.com> wrote:

> 
> On Friday 27 January 2012 13:43, in comp.os.linux.misc,
> lpitcher@teksavvy.com wrote:
> 
> > On Friday 27 January 2012 13:16, in comp.os.linux.misc,
> > Todd@invalid.invalid wrote:
> > 
> >> Hi All,
> >> 
> >>     Maybe I am a bit dense here, but the man page for "at"
> >> is more than a bit confusing to me.
> >> 
> >>     What I want to do is run the follow two commands
> >> as root at a specific time:
> >> 
> >>         su root -c "touch /forcefsck; reboot"
> >> 
> >>     How do I do that with "at"?
> > 
> > Not easily
> > 
> > Your su command will need access to a tty device (real or pseudo) in order
> > to acquire root's password. The at(1) command doesn't provide such a file.
> > This means that your su command will fail or hang, and won't get far
> > enough to process it's commandline.
> > 
> > Assuming that you remove such password protection around root, then you
> > could just
> >   echo 'su root -c "touch /forcefsck; reboot"' | at now + 5 minutes
> > to have the command executed in five minutes (substitute the appropriate
> > at(1) options for your intended schedule).
> 
> A possible workaround of the su password problem:
>   su root -c 'echo "touch /forcefsck; reboot" | at now + 5 minutes'
> and answer the password request immediately
> 
> Note: I have not tried this; you may have to fiddle with the quotes (single
> and double), and password prompt.

I have done:

sudo at now + 5 minutes <somejob.bat

where somejob.bat contains commands to be run as root.

# Shutdown in 5 minutes and force a fsck on boot.
sudo /sbin/shutdown -F +5

# Shutdown at 11pm and force a fsck on boot.
sudo /sbin/shutdown -F 23:00

(sudo does pretty much what su does.)

> 
> HTH

-- 
Robert Heller             -- 978-544-6933 / heller@deepsoft.com
Deepwoods Software        -- http://www.deepsoft.com/
()  ascii ribbon campaign -- against html e-mail
/\  www.asciiribbon.org   -- against proprietary attachments


                                                                                 

At Fri, 27 Jan 2012 11:17:43 -0800 Todd <Todd@invalid.invalid> wrote:

> 
> On 01/27/2012 11:10 AM, Richard Kettlewell wrote:
> > Todd<Todd@invalid.invalid>  writes:
> >>     Maybe I am a bit dense here, but the man page for "at"
> >> is more than a bit confusing to me.
> >>
> >>     What I want to do is run the follow two commands
> >> as root at a specific time:
> >>
> >>         su root -c "touch /forcefsck; reboot"
> >>
> >>     How do I do that with "at"?
> >
> > Become root first, then run 'at'.
> >
> 
> an example?
>                   

su -l
# at ...
#^D

See my other message for more possibities.


-- 
Robert Heller             -- 978-544-6933 / heller@deepsoft.com
Deepwoods Software        -- http://www.deepsoft.com/
()  ascii ribbon campaign -- against html e-mail
/\  www.asciiribbon.org   -- against proprietary attachments


                                                                                   

At Fri, 27 Jan 2012 12:23:54 -0800 Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> wrote:

> 
> On 2012-01-27, Todd <Todd@invalid.invalid> wrote:
> >
> >     What I want to do is run the follow two commands
> > as root at a specific time:
> >
> >         su root -c "touch /forcefsck; reboot"
> 
> Is there a particular reason you do not wish to use cron?  Because doing
> something at a specific time is easy with cron; I might use at when I
> want to say "five minutes from now" but I'd use cron for "11pm every
> other night".

cron only makes sense for a repeated event or activity.

shutdown itself allows for scheduled shutdowns and has options to force
fsck.  The OP is just wanting to do it 'the (needlessly) hard way'. 
Unless this is some sort of homework program for system admin 101.

> 
> --keith
> 
> 

-- 
Robert Heller             -- 978-544-6933 / heller@deepsoft.com
Deepwoods Software        -- http://www.deepsoft.com/
()  ascii ribbon campaign -- against html e-mail
/\  www.asciiribbon.org   -- against proprietary attachments


         

On 2012-01-27, Robert Heller <heller@deepsoft.com> wrote:
> At Fri, 27 Jan 2012 12:23:54 -0800 Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> wrote:
>
>> 
>> On 2012-01-27, Todd <Todd@invalid.invalid> wrote:
>> >
>> >     What I want to do is run the follow two commands
>> > as root at a specific time:
>> >
>> >         su root -c "touch /forcefsck; reboot"
>> 
>> Is there a particular reason you do not wish to use cron?  Because doing
>> something at a specific time is easy with cron; I might use at when I
>> want to say "five minutes from now" but I'd use cron for "11pm every
>> other night".
>
> cron only makes sense for a repeated event or activity.

The OP did not specify, but I inferred that he wanted to reboot every so
often, in order to force an fsck.  If that's not correct he needs to
clarify.

--keith



-- 
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information

At Fri, 27 Jan 2012 17:22:41 -0800 Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> wrote:

> 
> On 2012-01-27, Robert Heller <heller@deepsoft.com> wrote:
> > At Fri, 27 Jan 2012 12:23:54 -0800 Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> wrote:
> >
> >> 
> >> On 2012-01-27, Todd <Todd@invalid.invalid> wrote:
> >> >
> >> >     What I want to do is run the follow two commands
> >> > as root at a specific time:
> >> >
> >> >         su root -c "touch /forcefsck; reboot"
> >> 
> >> Is there a particular reason you do not wish to use cron?  Because doing
> >> something at a specific time is easy with cron; I might use at when I
> >> want to say "five minutes from now" but I'd use cron for "11pm every
> >> other night".
> >
> > cron only makes sense for a repeated event or activity.
> 
> The OP did not specify, but I inferred that he wanted to reboot every so
> often, in order to force an fsck.  If that's not correct he needs to
> clarify.

*I* assumed that since the OP asked about at, he was looking for a
one-time event.  Maybe he is running some task and wants to schedule a
one time reboot at some time in the future when he is not in front of
the machine or something.

> 
> --keith
> 
> 
> 

-- 
Robert Heller             -- 978-544-6933 / heller@deepsoft.com
Deepwoods Software        -- http://www.deepsoft.com/
()  ascii ribbon campaign -- against html e-mail
/\  www.asciiribbon.org   -- against proprietary attachments


       

On 01/27/2012 01:34 PM, Robert Heller wrote:
> # Shutdown in 5 minutes and force a fsck on boot.
> sudo /sbin/shutdown -F +5
>
> # Shutdown at 11pm and force a fsck on boot.
> sudo /sbin/shutdown -F 23:00

"-f" got removed from Red Hat:

https://bugzilla.redhat.com/show_bug.cgi?id=784960
https://bugzilla.redhat.com/show_bug.cgi?id=733874

:'(

-T

On 01/27/2012 12:23 PM, Keith Keller wrote:
> On 2012-01-27, Todd<Todd@invalid.invalid>  wrote:
>>
>>      What I want to do is run the follow two commands
>> as root at a specific time:
>>
>>          su root -c "touch /forcefsck; reboot"
>
> Is there a particular reason you do not wish to use cron?  Because doing
> something at a specific time is easy with cron; I might use at when I
> want to say "five minutes from now" but I'd use cron for "11pm every
> other night".
>
> --keith
>
>

I like to use cron for repeating tasks.  other than that, cron is
a pain in the ...

On 01/27/2012 01:35 PM, Robert Heller wrote:
> shutdown itself allows for scheduled shutdowns and has options to force
> fsck.  The OP is just wanting to do it 'the (needlessly) hard way'.
> Unless this is some sort of homework program for system admin 101.

"-F" got removed from Red Hat:

The hard way was the point I made to Red Hat.  Their opinion is that
if a hard way exists, there is no reason to fix things.

https://bugzilla.redhat.com/show_bug.cgi?id=784960
https://bugzilla.redhat.com/show_bug.cgi?id=733874

:'(

-T

On 01/27/2012 05:22 PM, Keith Keller wrote:
> The OP did not specify, but I inferred that he wanted to reboot every so
> often, in order to force an fsck.  If that's not correct he needs to
> clarify.

It is for targeted reboots with fsck to get fsck out of the way so
the customer does not have wait around practice his swearing
technique (my name prominently inserted) while he waits for a
long fsck on reboot.

We have a lot of power problems are these parts.  And, some of my 
customers turn their servers off over the weekend.

I mainly use the targeted reboots to clear AHCI failure to mount
issued with removable backup disks.

-T

On 01/27/2012 06:25 PM, Robert Heller wrote:
> *I*  assumed that since the OP asked about at, he was looking for a
> one-time event.  Maybe he is running some task and wants to schedule a
> one time reboot at some time in the future when he is not in front of
> the machine or something.

Yep.  Anyone have an example of how to use "at"?

On 01/27/2012 12:26 PM, unruh wrote:
> at 9:45 Jun 14
> at>  touch /forcefsck; reboot
> at>^D

No wonder I did not understand.

Thank you!

On Fri, 27 Jan 2012 22:49:38 -0800, Todd wrote:
>
> Yep.  Anyone have an example of how to use "at"?


You can put any commands you like in a script and launch it. Example:

at -f aa 00:30                  submits batch job in the morning or
at -f script.ksh now+1minute    for the case where now second is close to 59

For extra points, do a
man at

On 01/27/2012 11:16 PM, Bit Twister wrote:
> For extra points, do a
> man at

I did.  No clue what they were trying to say.
That is why I asked.

-T

"Just Google it!".  The new "RTFM".  :'(

Fri, 27 Jan 2012 22:41:37 -0800, Todd did cat :

> On 01/27/2012 01:34 PM, Robert Heller wrote:
>> # Shutdown in 5 minutes and force a fsck on boot.
>> sudo /sbin/shutdown -F +5
>>
>> # Shutdown at 11pm and force a fsck on boot.
>> sudo /sbin/shutdown -F 23:00
> 
> "-f" got removed from Red Hat:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=784960
> https://bugzilla.redhat.com/show_bug.cgi?id=733874
> 
> :'(

bad distro, change distro. More I'd say that RH seems to go out of
the Linux/GNU path, for instance I have had the impression they're
going to "use" (excuse the mind stretch here) systemd.
So, I'd think it's not only that -F on shutdown was
removed from RH but that RH is now removed from distros list
and should shutdown ;-)

(hey, we're in colmisc after all ;>)

At Fri, 27 Jan 2012 22:49:02 -0800 Todd <Todd@invalid.invalid> wrote:

> 
> On 01/27/2012 05:22 PM, Keith Keller wrote:
> > The OP did not specify, but I inferred that he wanted to reboot every so
> > often, in order to force an fsck.  If that's not correct he needs to
> > clarify.
> 
> It is for targeted reboots with fsck to get fsck out of the way so
> the customer does not have wait around practice his swearing
> technique (my name prominently inserted) while he waits for a
> long fsck on reboot.
> 
> We have a lot of power problems are these parts.  And, some of my 
> customers turn their servers off over the weekend.

It sounds like you need UPSes (and no, I don't mean the people with the
brown trucks).  APC makes a line of linux friendly UPSes and apcupsd is
available in the EPel repository.

> 
> I mainly use the targeted reboots to clear AHCI failure to mount
> issued with removable backup disks.
> 
> -T
>       

-- 
Robert Heller             -- 978-544-6933 / heller@deepsoft.com
Deepwoods Software        -- http://www.deepsoft.com/
()  ascii ribbon campaign -- against html e-mail
/\  www.asciiribbon.org   -- against proprietary attachments


                               

On Saturday 28 January 2012 11:27, Loki Harfagr conveyed the following 
to comp.os.linux.misc...

> Fri, 27 Jan 2012 22:41:37 -0800, Todd did cat :
> 
>> On 01/27/2012 01:34 PM, Robert Heller wrote:
>>> # Shutdown in 5 minutes and force a fsck on boot.
>>> sudo /sbin/shutdown -F +5
>>>
>>> # Shutdown at 11pm and force a fsck on boot.
>>> sudo /sbin/shutdown -F 23:00
>> 
>> "-f" got removed from Red Hat:
>> 
>> https://bugzilla.redhat.com/show_bug.cgi?id=784960
>> https://bugzilla.redhat.com/show_bug.cgi?id=733874
>> 
>> :'(
> 
> bad distro, change distro. More I'd say that RH seems to go out of
> the Linux/GNU path, for instance I have had the impression they're
> going to "use" (excuse the mind stretch here) systemd.

No surprise there, as Kay Sievers, who developed and maintains systemd, 
is a RedHat employee, and RedHat fully supports and endorses systemd.

Many of the newer releases of other distributions have already switched 
to systemd by now, e.g. Mandriva, Mageia, openSUSE, possibly PCLinuxOS, 
et al.  openSUSE 12.1 is the only still very new distro release that 
actually still supports - and documents via their website - removing 
systemd and installing the "old" (but improved) System V init scripts.

> So, I'd think it's not only that -F on shutdown was removed from RH
> but that RH is now removed from distros list and should shutdown ;-)
> 
> (hey, we're in colmisc after all ;>)

This isn't RedHat's first sin, and it won't be their last either.  They 
see themselves as an important component of the upstream GNU/Linux 
development and as wayshowers/enforcers.

One of the reasons why I didn't like RedHat was that their Anaconda 
installer refused to install any component of the system on any other 
filesystem than ext2/3 - this was still before the advent of ext4 - 
while XFS, JFS and reiserfs are all supported in the upstream vanilla 
Linux kernel, and have been industry-standard filesystems for many 
years, and all offered better performance than ext3.  

ext4 is cool - I've given it a test run and I can't say that there's 
anything wrong with it insofar as I could see - but I still prefer XFS, 
because I'm used to that and I know it better.  RedHat/CentOS and Fedora 
didn't let me select it, nor would they allow installation of any 
component of the system on already existing reiserfs partitions.

-- 
= Aragorn =
(registered GNU/Linux user #223157)

On 2012-01-28, Aragorn <stryder@telenet.be.invalid> wrote:
>
> One of the reasons why I didn't like RedHat was that their Anaconda 
> installer refused to install any component of the system on any other 
> filesystem than ext2/3 - this was still before the advent of ext4 - 
> while XFS, JFS and reiserfs are all supported in the upstream vanilla 
> Linux kernel, and have been industry-standard filesystems for many 
> years, and all offered better performance than ext3.  

Back when they were doing this, CentOS provided an XFS kernel in their
-plus repo.  (I think they also provided a reiserfs kernel; not sure
about JFS.)  It was possible (though hard) to actually get Anaconda to
see and install to an XFS filesystem, but it was straightforward to
update to an xfs kernel and put (say) home directories there.

> ext4 is cool - I've given it a test run and I can't say that there's 
> anything wrong with it insofar as I could see - but I still prefer XFS, 
> because I'm used to that and I know it better.  RedHat/CentOS and Fedora 
> didn't let me select it, nor would they allow installation of any 
> component of the system on already existing reiserfs partitions.

No, but I didn't really care if /usr was on XFS, as long as my large
shared drives could be.  The thinking was, on a small fs like /usr the
advantages of XFS over ext3 would be negligible.

--keith

-- 
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information

On 01/28/2012 04:07 AM, Robert Heller wrote:
> It sounds like you need UPSes (and no, I don't mean the people with the
> brown trucks).  APC makes a line of linux friendly UPSes and apcupsd is
> available in the EPel repository.

I put APC Smart UPS on all my servers.  I install apcupsd to
monitor them.  Problem is that they run down eventually
when the power goes out.  Everything restarts beautifully when
the power comes back on.  Although the guys in the brown
short pants with the brown trucks get a little annoyed  having
to wait around.  They protest that they are delivery guys and not
power guys.  :-)

-T

At Sat, 28 Jan 2012 13:32:38 -0800 Todd <Todd@invalid.invalid> wrote:

> 
> On 01/28/2012 04:07 AM, Robert Heller wrote:
> > It sounds like you need UPSes (and no, I don't mean the people with the
> > brown trucks).  APC makes a line of linux friendly UPSes and apcupsd is
> > available in the EPel repository.
> 
> I put APC Smart UPS on all my servers.  I install apcupsd to
> monitor them.  Problem is that they run down eventually
> when the power goes out.  Everything restarts beautifully when
> the power comes back on.  Although the guys in the brown

If you have UPSes and are using apcupsd, it should be performing clean
shutdowns with there is a power failure.  This should avoid the need for
fscks on boot up.

> short pants with the brown trucks get a little annoyed  having
> to wait around.  They protest that they are delivery guys and not
> power guys.  :-)
> 
> -T
>                                                    

-- 
Robert Heller             -- 978-544-6933 / heller@deepsoft.com
Deepwoods Software        -- http://www.deepsoft.com/
()  ascii ribbon campaign -- against html e-mail
/\  www.asciiribbon.org   -- against proprietary attachments


                                                                   

On 01/28/2012 08:28 PM, Robert Heller wrote:
> If you have UPSes and are using apcupsd, it should be performing clean
> shutdowns with there is a power failure.  This should avoid the need for
> fscks on boot up.

With RH, you get an fsck every 25 or so reboots.  The reason I do it
on a targeted reboot is to restart the counter so the customer does
not get an fsck in the middle of his work day.  (They have been know
to practice their swearing skills with my name prominently inserted.
Worse case they have been known to flip the power off and back on.)

On 2012-01-29, Todd <Todd@invalid.invalid> wrote:
>
> With RH, you get an fsck every 25 or so reboots.

This is changeable or disablable using tune2fs.

> The reason I do it
> on a targeted reboot is to restart the counter so the customer does
> not get an fsck in the middle of his work day.

How often do they reboot?!?  My desktop users (me included) reboot every
few months, so the time-forced fsck generally occurs before the mount
count-forced fsck.  But if they do reboot frequently, you can probably
safely disable the mount-count-forced fsck and rely on the time-forced
one.  You can use a cron job (see, cron's useful!) to touch /forcefsck
and reboot monthly so that your users never hit the time-forced fsck
during their work day.  (If you're on RH you can stick a script into
/etc/cron.monthly/ .)

--keith



-- 
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information

At Sat, 28 Jan 2012 22:50:31 -0800 Todd <Todd@invalid.invalid> wrote:

> 
> On 01/28/2012 08:28 PM, Robert Heller wrote:
> > If you have UPSes and are using apcupsd, it should be performing clean
> > shutdowns with there is a power failure.  This should avoid the need for
> > fscks on boot up.
> 
> With RH, you get an fsck every 25 or so reboots.  The reason I do it
> on a targeted reboot is to restart the counter so the customer does
> not get an fsck in the middle of his work day.  (They have been know
> to practice their swearing skills with my name prominently inserted.
> Worse case they have been known to flip the power off and back on.)

man tunes2fs

>                                 

-- 
Robert Heller             -- 978-544-6933 / heller@deepsoft.com
Deepwoods Software        -- http://www.deepsoft.com/
()  ascii ribbon campaign -- against html e-mail
/\  www.asciiribbon.org   -- against proprietary attachments


                                                                                     

On 2012-01-29, Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> wrote:
> On 2012-01-29, Todd <Todd@invalid.invalid> wrote:
>>
>> With RH, you get an fsck every 25 or so reboots.
>
> This is changeable or disablable using tune2fs.
>
>> The reason I do it
>> on a targeted reboot is to restart the counter so the customer does
>> not get an fsck in the middle of his work day.
>
> How often do they reboot?!?  My desktop users (me included) reboot every
> few months, so the time-forced fsck generally occurs before the mount
> count-forced fsck.  But if they do reboot frequently, you can probably
> safely disable the mount-count-forced fsck and rely on the time-forced
> one.  You can use a cron job (see, cron's useful!) to touch /forcefsck
> and reboot monthly so that your users never hit the time-forced fsck
> during their work day.  (If you're on RH you can stick a script into
> /etc/cron.monthly/ .)

In order to save power, many businesses request that you shut down every
day when you go home. 50 machines in an office all drawing 100 watts of
power every night equals .1 MWhr of power useage. That is not
negligible, in terms of energy savings, even if not money savings.


>
> --keith
>
>
>

On Sunday 29 January 2012 14:35, Robert Heller conveyed the following to 
comp.os.linux.misc...

> At Sat, 28 Jan 2012 22:50:31 -0800 Todd <Todd@invalid.invalid> wrote:
> 
>> On 01/28/2012 08:28 PM, Robert Heller wrote:
>>
>> > If you have UPSes and are using apcupsd, it should be performing
>> > clean shutdowns with there is a power failure.  This should avoid
>> > the need for fscks on boot up.
>> 
>> With RH, you get an fsck every 25 or so reboots.  The reason I do it
>> on a targeted reboot is to restart the counter so the customer does
>> not get an fsck in the middle of his work day.  (They have been know
>> to practice their swearing skills with my name prominently inserted.
>> Worse case they have been known to flip the power off and back on.)
> 
> man tunes2fs

Or even more correctly...

    man tune2fs

;-)

-- 
= Aragorn =
(registered GNU/Linux user #223157)

On 01/28/2012 11:35 PM, Keith Keller wrote:
> On 2012-01-29, Todd<Todd@invalid.invalid>  wrote:
>>
>> With RH, you get an fsck every 25 or so reboots.
>
> This is changeable or disablable using tune2fs.
>
>> The reason I do it
>> on a targeted reboot is to restart the counter so the customer does
>> not get an fsck in the middle of his work day.
>
> How often do they reboot?!?  My desktop users (me included) reboot every
> few months, so the time-forced fsck generally occurs before the mount
> count-forced fsck.  But if they do reboot frequently, you can probably
> safely disable the mount-count-forced fsck and rely on the time-forced
> one.  You can use a cron job (see, cron's useful!) to touch /forcefsck
> and reboot monthly so that your users never hit the time-forced fsck
> during their work day.  (If you're on RH you can stick a script into
> /etc/cron.monthly/ .)
>
> --keith

Hi Keith,

One of my former customer, I had to set off a times reboot every
week or so, due to his removable AHCI backup hard drives not
mounting correctly when he changed them out.  I am suspicious
of how he did it, but ...  He also rebooted for the stupidest
reasons.  And, when he caught an fsck at boot, he swore and flipped
the power off and back on.  (I am glad I do not work for him anymore.)

I am just going though withdraw pains that RH removed the "-F"
from shutdown and was looking for an alternative that was easy to
remember.

Thank you for the tips!

-T

On 01/29/2012 10:46 AM, unruh wrote:
> n order to save power, many businesses request that you shut down every
> day when you go home. 50 machines in an office all drawing 100 watts of
> power every night equals .1 MWhr of power useage. That is not
> negligible, in terms of energy savings, even if not money savings.

I tell my customers to figure about $300.00 per year in extra
electricity to leave their computers on 24/7.  You also wear
out your computers sooner leaving them on all the time.

One of my good customers turns his server off over the weekend.
He does not get upset over a fsck either.  Come to think of
it, his AHCI removable hard drives always mount correctly
as well, when he changes them out.

-T

At Sun, 29 Jan 2012 12:03:50 -0800 Todd <Todd@invalid.invalid> wrote:

> 
> On 01/29/2012 10:46 AM, unruh wrote:
> > n order to save power, many businesses request that you shut down every
> > day when you go home. 50 machines in an office all drawing 100 watts of
> > power every night equals .1 MWhr of power useage. That is not
> > negligible, in terms of energy savings, even if not money savings.
> 
> I tell my customers to figure about $300.00 per year in extra
> electricity to leave their computers on 24/7.  You also wear
> out your computers sooner leaving them on all the time.
> 
> One of my good customers turns his server off over the weekend.

Not necessarily a good thing, depending on the use cases.

> He does not get upset over a fsck either.  Come to think of
> it, his AHCI removable hard drives always mount correctly
> as well, when he changes them out.

I bet he properly does an 'umount' before removing them...

It might also be the make, model, and vintage of the SATA controllers
in question.  Some of the early model SATA controllers did not handle
AHCI hot-swapping right.

> 
> -T
>                                                   

-- 
Robert Heller             -- 978-544-6933 / heller@deepsoft.com
Deepwoods Software        -- http://www.deepsoft.com/
()  ascii ribbon campaign -- against html e-mail
/\  www.asciiribbon.org   -- against proprietary attachments


        

On 01/29/2012 01:38 PM, Robert Heller wrote:
> It might also be the make, model, and vintage of the SATA controllers
> in question.  Some of the early model SATA controllers did not handle
> AHCI hot-swapping right.

I think bios revisions may have something to do with it too.

On 2012-01-29, Todd <Todd@invalid.invalid> wrote:
> On 01/29/2012 10:46 AM, unruh wrote:
>> n order to save power, many businesses request that you shut down every
>> day when you go home. 50 machines in an office all drawing 100 watts of
>> power every night equals .1 MWhr of power useage. That is not
>> negligible, in terms of energy savings, even if not money savings.
>
> I tell my customers to figure about $300.00 per year in extra
> electricity to leave their computers on 24/7.  You also wear
> out your computers sooner leaving them on all the time.

Say the computer uses 100W overnight (14hr) that is 1.4kWh/night, 8
nights/week (Sat and Sun is 3 nights) 50 weeks a year, that is abpout
600kWh. What is electricity in your neck of the woods? $.1/kWh-- I
suspect it is less than $.50-- , that
would be $60/year. But they would wear out faster not slower, since the
current surges on bootup, the hard disks spinning up, the temperature
cycling etc, I suspect decreases lifetime not increases it. 


>
> One of my good customers turns his server off over the weekend.
> He does not get upset over a fsck either.  Come to think of
> it, his AHCI removable hard drives always mount correctly
> as well, when he changes them out.
>
> -T

On Monday 30 January 2012 02:36, unruh conveyed the following to 
comp.os.linux.misc...

> On 2012-01-29, Todd <Todd@invalid.invalid> wrote:
>
>> On 01/29/2012 10:46 AM, unruh wrote:
>>
>>> [...] to save power, many businesses request that you shut down
>>> every day when you go home. 50 machines in an office all drawing 100
>>> watts of power every night equals .1 MWhr of power useage. That is
>>> not negligible, in terms of energy savings, even if not money
>>> savings.
>>
>> I tell my customers to figure about $300.00 per year in extra
>> electricity to leave their computers on 24/7.  You also wear
>> out your computers sooner leaving them on all the time.
> 
> Say the computer uses 100W overnight (14hr) that is 1.4kWh/night, 8
> nights/week (Sat and Sun is 3 nights) 50 weeks a year, that is abpout
> 600kWh. What is electricity in your neck of the woods? $.1/kWh-- I
> suspect it is less than $.50-- , that would be $60/year. But they
> would wear out faster not slower, since the current surges on bootup,
> the hard disks spinning up, the temperature cycling etc, I suspect
> decreases lifetime not increases it.

That is absolutely correct.  There is however a caveat, namely that 
consumer-grade hard disks - and most businesses will indeed use regular 
PCs with consumer-grade hardware for their office jobs, instead of 
professional enterprise-grade workstations - are only rated for an 8-
hour uptime per 24 hours, of which only some 20% under maximum load.

In other words, the manufacturers have created a chicken-and-egg 
situation.  The hard disk will wear prematurely if you keep it spun up 
all the time, but if you don't, then it'll wear prematurely from all the 
powerups and the thermal load and voltage surges associated with the 
hardware boot sequence and the loading of the operating system.

I must however add that there's a good chance that the manufacturer's 
advice about the 8-hour per day thing is bogus and just scaremongering 
to manipulate consumer behavior into actually wearing out the equipment 
more rapidly through the "recommended" shutdown/bootup cycles, because 
although some consumer-grade hard disks do break down prematurely - and 
I've had that happen to a brand new SATA disk in this machine here - the 
PATA hard disk that I have transfered to this machine here has served me 
well for many years in another machine, spinning 24/7, and I am still 
using it as such now.  

Given that I have two distros installed on this machine, each distro on 
its own hard disk, I used the GNU/Linux installation on the PATA disk 
24/7 for a while still after the SATA disk broke down, but at present I 
am running Mageia 1 x86-64 off of the replaced SATA disk, and none of 
the partitions on the PATA disk are currently mounted, but it is 
nevertheless still spinning.

-- 
= Aragorn =
(registered GNU/Linux user #223157)

On 01/29/2012 05:36 PM, unruh wrote:
>> I tell my customers to figure about $300.00 per year in extra
>> >  electricity to leave their computers on 24/7.  You also wear
>> >  out your computers sooner leaving them on all the time.

> Say the computer uses 100W overnight (14hr) that is 1.4kWh/night, 8
> nights/week (Sat and Sun is 3 nights) 50 weeks a year, that is abpout
> 600kWh. What is electricity in your neck of the woods? $.1/kWh-- I
> suspect it is less than $.50-- , that
> would be $60/year.

My estimate was on about 300 watts (including monitors, speakers, 
printers, etc.) at 12 hrs a day for 50 weeks (2 weeks for vacation).
The electricity rate I took at their highest of the three tiers.
It came out about $280.00/yr.  So I just tell them $300 / year


> But they would wear out faster not slower, since the
> current surges on bootup, the hard disks spinning up, the temperature
> cycling etc, I suspect decreases lifetime not increases it.
about 30 years ago the power supplies would surge and burn a bunch
of stuff up (I got to repair it).  So, you left everything on.

I have not seen this problem for a lot of years.  My current experience
is that the computers that are used the least (left off) are the
longest lasting.

Have you ever calculated MBTF (mean time between failure) on
electronic parts?  The longer things are left hot, the sooner
the fail -- on an exponential scale too (I mean that literally,
I am not kidding).  This matches my experience.  Especially
el-cheap-o power supplies.  (I use PC Power and cooling with a
12 year MBTF.)

Funny you mention this.  The customers I can not get to turn things
off are the Windows users that are so virused up that the can not
get their computers to easily boot back up and they are too cheap
to call me in to fix it.  :-P

-T

On 01/29/2012 06:07 PM, Aragorn wrote:
> On Monday 30 January 2012 02:36, unruh conveyed the following to
> comp.os.linux.misc...
>
>> On 2012-01-29, Todd<Todd@invalid.invalid>  wrote:
>>
>>> On 01/29/2012 10:46 AM, unruh wrote:
>>>
>>>> [...] to save power, many businesses request that you shut down
>>>> every day when you go home. 50 machines in an office all drawing 100
>>>> watts of power every night equals .1 MWhr of power useage. That is
>>>> not negligible, in terms of energy savings, even if not money
>>>> savings.
>>>
>>> I tell my customers to figure about $300.00 per year in extra
>>> electricity to leave their computers on 24/7.  You also wear
>>> out your computers sooner leaving them on all the time.
>>
>> Say the computer uses 100W overnight (14hr) that is 1.4kWh/night, 8
>> nights/week (Sat and Sun is 3 nights) 50 weeks a year, that is abpout
>> 600kWh. What is electricity in your neck of the woods? $.1/kWh-- I
>> suspect it is less than $.50-- , that would be $60/year. But they
>> would wear out faster not slower, since the current surges on bootup,
>> the hard disks spinning up, the temperature cycling etc, I suspect
>> decreases lifetime not increases it.
>
> That is absolutely correct.  There is however a caveat, namely that
> consumer-grade hard disks - and most businesses will indeed use regular
> PCs with consumer-grade hardware for their office jobs, instead of
> professional enterprise-grade workstations - are only rated for an 8-
> hour uptime per 24 hours, of which only some 20% under maximum load.
>
> In other words, the manufacturers have created a chicken-and-egg
> situation.  The hard disk will wear prematurely if you keep it spun up
> all the time, but if you don't, then it'll wear prematurely from all the
> powerups and the thermal load and voltage surges associated with the
> hardware boot sequence and the loading of the operating system.
>
> I must however add that there's a good chance that the manufacturer's
> advice about the 8-hour per day thing is bogus and just scaremongering
> to manipulate consumer behavior into actually wearing out the equipment
> more rapidly through the "recommended" shutdown/bootup cycles, because
> although some consumer-grade hard disks do break down prematurely - and
> I've had that happen to a brand new SATA disk in this machine here - the
> PATA hard disk that I have transfered to this machine here has served me
> well for many years in another machine, spinning 24/7, and I am still
> using it as such now.
>
> Given that I have two distros installed on this machine, each distro on
> its own hard disk, I used the GNU/Linux installation on the PATA disk
> 24/7 for a while still after the SATA disk broke down, but at present I
> am running Mageia 1 x86-64 off of the replaced SATA disk, and none of
> the partitions on the PATA disk are currently mounted, but it is
> nevertheless still spinning.
>

I use Seagate's enterprise level 24/7 hard drives.  So far one dead
out of the box.  Two failed in the field after about 4 years use.
Probably sold about 50 so far.

What kind of crap must HP be using/buying.  Have had a rash of
customer had their hard drive go out in about 13 months (warranty
+ 1 month).

I think I am just prattling on with friends.  So I will shut up now.

-T

Sat, 28 Jan 2012 19:05:46 +0100, Aragorn did cat :

> On Saturday 28 January 2012 11:27, Loki Harfagr conveyed the following
> to comp.os.linux.misc...
> 
>> Fri, 27 Jan 2012 22:41:37 -0800, Todd did cat :
>> 
>>> On 01/27/2012 01:34 PM, Robert Heller wrote:
>>>> # Shutdown in 5 minutes and force a fsck on boot. sudo /sbin/shutdown
>>>> -F +5
>>>>
>>>> # Shutdown at 11pm and force a fsck on boot. sudo /sbin/shutdown -F
>>>> 23:00
>>> 
>>> "-f" got removed from Red Hat:
>>> 
>>> https://bugzilla.redhat.com/show_bug.cgi?id=784960
>>> https://bugzilla.redhat.com/show_bug.cgi?id=733874
>>> 
>>> :'(
>> 
>> bad distro, change distro. More I'd say that RH seems to go out of the
>> Linux/GNU path, for instance I have had the impression they're going to
>> "use" (excuse the mind stretch here) systemd.
> 
> No surprise there, as Kay Sievers, who developed and maintains systemd,
> is a RedHat employee, and RedHat fully supports and endorses systemd.

Er, I thought it was some Lennart toy (and that Kay was the guy from U.D.E.V.)

> Many of the newer releases of other distributions have already switched
> to systemd by now, e.g. Mandriva, Mageia, openSUSE, possibly PCLinuxOS,
> et al.  openSUSE 12.1 is the only still very new distro release that
> actually still supports - and documents via their website - removing
> systemd and installing the "old" (but improved) System V init scripts.

well, long live Slackware then, good news :-)


>> So, I'd think it's not only that -F on shutdown was removed from RH but
>> that RH is now removed from distros list and should shutdown ;-)
>> 
>> (hey, we're in colmisc after all ;>)
> 
> This isn't RedHat's first sin, and it won't be their last either.  They
> see themselves as an important component of the upstream GNU/Linux
> development and as wayshowers/enforcers.

so why is it that they sound so much like showstoppers and puncturers?

....
> ext4 is cool - I've given it a test run and I can't say that there's
> anything wrong with it insofar as I could see - but I still prefer XFS,

yup, I usually prefer JFS and XFS to ext4, though I like some easygoers
in ext4 like resizing both ways or self supported undeletes.

> because I'm used to that and I know it better.  RedHat/CentOS and Fedora
> didn't let me select it, nor would they allow installation of any
> component of the system on already existing reiserfs partitions.

well, I'll agree on that but I'll also admit that my experience on RH is
quite old as I gave up trying to run them correctly on desktops circa 2K
and my last attempts to use them on servers were 2K7 but as it seems they're
still on their piling up toys to test their devs ability at understanding
parallelism and mimicking a feline names oriented desktop products line,
I guess there are few chances they have it repaired since ;->

On Monday 30 January 2012 09:51, Loki Harfagr conveyed the following to 
comp.os.linux.misc...

> Sat, 28 Jan 2012 19:05:46 +0100, Aragorn did cat :
> 
>> On Saturday 28 January 2012 11:27, Loki Harfagr conveyed the
>> following to comp.os.linux.misc...
>> 
>>> Fri, 27 Jan 2012 22:41:37 -0800, Todd did cat :
>>> 
>>>> On 01/27/2012 01:34 PM, Robert Heller wrote:
>>>>> # Shutdown in 5 minutes and force a fsck on boot. sudo
>>>>> # /sbin/shutdown
>>>>> -F +5
>>>>>
>>>>> # Shutdown at 11pm and force a fsck on boot. sudo /sbin/shutdown
>>>>> # -F
>>>>> 23:00
>>>> 
>>>> "-f" got removed from Red Hat:
>>>> 
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=784960
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=733874
>>>> 
>>>> :'(
>>> 
>>> bad distro, change distro. More I'd say that RH seems to go out of
>>> the Linux/GNU path, for instance I have had the impression they're
>>> going to "use" (excuse the mind stretch here) systemd.
>> 
>> No surprise there, as Kay Sievers, who developed and maintains
>> systemd, is a RedHat employee, and RedHat fully supports and endorses
>> systemd.
> 
> Er, I thought it was some Lennart toy (and that Kay was the guy from
> U.D.E.V.)

It is possible that Kay Sievers is now also the maintainer for (the 
userspace portion of) udev, but as far as I know, udev is still the 
brainchild of Greg Kroah-Hartman, and Sievers and that Lennert guy - 
Lennert is his firstname actually - are the ones behind systemd.

>> Many of the newer releases of other distributions have already
>> switched to systemd by now, e.g. Mandriva, Mageia, openSUSE, possibly
>> PCLinuxOS, et al.  openSUSE 12.1 is the only still very new distro
>> release that actually still supports - and documents via their
>> website - removing systemd and installing the "old" (but improved)
>> System V init scripts.
> 
> well, long live Slackware then, good news :-)

Yes, I don't expect Slack to be switching to systemd any time soon.  
However, since the new udevd release now installs itself under "/usr", 
the breakage is already introduced, and so sooner or later even 
Slackware will have to adopt the new udev, and will no longer be able to 
boot without an initramfs or initrd if you happen to have "/usr" on a 
separate partition.

Well...  That is to say...  There is a workaround, but this will still 
require that "/usr" be mounted even when booting up in single-user mode.  
The workaround is to, instead of using an initrd/initrams - for instance 
if you roll your own kernels - use a pre-init script which mounts "/usr" 
(and whatever else you would like it to mount) and then calls the actual 
init via exec, like so...  (Note: location of GNU Bash and init adapted 
to the future scenario and using ext4.)

   #!/usr/bin/bash
   mount -t -ro ext4 /dev/sda2 /usr
   exec /usr/bin/init

You then store this script in, say, "/sbin", and then you invoke it via 
the kernel's parameter line in the bootloader - for LILO, that's on the 
"append=" line - like so...

   append="init=/sbin/pre-init.sh"

But of course, that too will break if "/sbin" is going to be a symbolic 
link to "/usr/sbin".  So they are really pushing the initramfs route.  

(I hate those things. :p)

>>> So, I'd think it's not only that -F on shutdown was removed from RH
>>> but that RH is now removed from distros list and should shutdown ;-)
>>> 
>>> (hey, we're in colmisc after all ;>)
>> 
>> This isn't RedHat's first sin, and it won't be their last either. 
>> They see themselves as an important component of the upstream
>> GNU/Linux development and as wayshowers/enforcers.
> 
> so why is it that they sound so much like showstoppers and puncturers?

Because they are pushing their agenda.  RedHat is in rather close 
cooperation with Oracle, which has acquired Sun Microsystems and has 
thus since become the "intellectual property" owner of Solaris.  And 
Solaris does it that way too.

>> ...
>> ext4 is cool - I've given it a test run and I can't say that there's
>> anything wrong with it insofar as I could see - but I still prefer
>> XFS,
> 
> yup, I usually prefer JFS and XFS to ext4, though I like some
> easygoers in ext4 like resizing both ways or self supported undeletes.

Like I meant to imply, I haven't played around with that yet.  I've only 
given it a quick test run so as to check its performance - not by way of 
benchmarks but simply while using it - and it seemed like a very usable 
and fast filesystem to me.

But either way, I expect that ext4 too is soon going to be deprecated in 
favor of btrfs, which some distributions are already beginning to offer 
and push.  btrfs is quite advanced and offers many of the possibilities 
of Solaris's ZFS, but it's still "not quite there yet".  Too soon for 
prime time right now.

>> because I'm used to that and I know it better.  RedHat/CentOS and
>> Fedora didn't let me select it, nor would they allow installation of
>> any component of the system on already existing reiserfs partitions.
> 
> well, I'll agree on that but I'll also admit that my experience on RH
> is quite old as I gave up trying to run them correctly on desktops
> circa 2K and my last attempts to use them on servers were 2K7 but as
> it seems they're still on their piling up toys to test their devs
> ability at understanding parallelism and mimicking a feline names
> oriented desktop products line, I guess there are few chances they
> have it repaired since ;->

I haven't actually used RedHat proper yet myself, but I do have 
extensive experience with CentOS - which is essentially the same thing - 
on our organization's servers.  However, our organization is also 
already defunct for a few years, so my experience with CentOS is a bit 
rusty too.  I think that the last version I installed - on a server 
which I own myself but which has in the meantime been reformatted and is 
currently non-operational - was CentOS 5.3.

As for Fedora, never liked it and never will be using it.  Completely 
unreliable, and you still get RedHat's not-so-benevolent dictatorship on 
top. ;-)

-- 
= Aragorn =
(registered GNU/Linux user #223157)

Following up on my own post because I realized I've made a logical 
error... ;-)

On Tuesday 31 January 2012 03:16, Aragorn conveyed the following to 
comp.os.linux.misc...

> On Monday 30 January 2012 09:51, Loki Harfagr conveyed the following
> to comp.os.linux.misc...
> 
>> well, long live Slackware then, good news :-)
> 
> Yes, I don't expect Slack to be switching to systemd any time soon.
> However, since the new udevd release now installs itself under "/usr",
> the breakage is already introduced, and so sooner or later even
> Slackware will have to adopt the new udev, and will no longer be able
> to boot without an initramfs or initrd if you happen to have "/usr" on
> a separate partition.
> 
> Well...  That is to say...  There is a workaround, but this will still
> require that "/usr" be mounted even when booting up in single-user
> mode. The workaround is to, instead of using an initrd/initrams - for
> instance if you roll your own kernels - use a pre-init script which
> mounts "/usr" (and whatever else you would like it to mount) and then
> calls the actual init via exec, like so...  (Note: location of GNU
> Bash and init adapted to the future scenario and using ext4.)
> 
>    #!/usr/bin/bash
>    mount -t -ro ext4 /dev/sda2 /usr
>    exec /usr/bin/init
> 
> You then store this script in, say, "/sbin", and then you invoke it
> via the kernel's parameter line in the bootloader - for LILO, that's
> on the "append=" line - like so...
> 
>    append="init=/sbin/pre-init.sh"
> 
> But of course, that too will break if "/sbin" is going to be a
> symbolic link to "/usr/sbin".  So they are really pushing the
> initramfs route.

There's my logical error, in the contents of the pre-init.sh script.  
There's no way to invoke "/usr/bin/bash" when "/usr" hasn't been mounted 
yet, and "mount" itself will then also reside in "/usr/bin".

So they really _did_ break it in all ways...  One now _must_ use an 
initramfs or initrd.  I suspect that the initramfs will probably be 
carrying busybox or something similar to provide for the "mount" and 
"fsck" commands.

-- 
= Aragorn =
(registered GNU/Linux user #223157)

I demand that Aragorn may or may not have written...

> On Monday 30 January 2012 09:51, Loki Harfagr conveyed the following to 
> comp.os.linux.misc...
>> Sat, 28 Jan 2012 19:05:46 +0100, Aragorn did cat :
[snip]
>>> Many of the newer releases of other distributions have already switched
>>> to systemd by now, e.g. Mandriva, Mageia, openSUSE, possibly PCLinuxOS,
>>> et al.  openSUSE 12.1 is the only still very new distro release that
>>> actually still supports - and documents via their website - removing
>>> systemd and installing the "old" (but improved) System V init scripts.

>> well, long live Slackware then, good news :-)

> Yes, I don't expect Slack to be switching to systemd any time soon.
> However, since the new udevd release now i`nstalls itself under "/usr", the
> breakage is already introduced, and so sooner or later even Slackware will
> have to adopt the new udev, and will no longer be able to boot without an
> initramfs or initrd if you happen to have "/usr" on a separate partition.

systemd is available but not installed here; udev 175 is installed, and no
newer is available in Debian.

> Well...  That is to say...  There is a workaround, but this will still
> require that "/usr" be mounted even when booting up in single-user mode.

By the time that the login prompt appears, /usr will be mounted anyway.

> The workaround is to, instead of using an initrd/initrams - for instance if
> you roll your own kernels - use a pre-init script which mounts "/usr" (and
> whatever else you would like it to mount) and then calls the actual init
> via exec, like so...  (Note: location of GNU Bash and init adapted to the
> future scenario and using ext4.)

>    #!/usr/bin/bash
     mount -r -t ext4 /dev/sda2 /usr
>    exec /usr/bin/init

Slight issue: you need to have bash (or, better, dash) in /usr with the real
/usr not mounted. I'd be more likely to dpkg-divert some files and add
symlinks so that what's necessary to allow /usr to be mounted is available
and will be updated when packages are updated.

Also, assuming that /etc/fstab isn't going to be moved, you can omit the type
and partition name.

devtmpfs ensures presence of the device nodes, so no problem there.

Of course, it's better to have udev work without needing this or not to
bother with separate /usr – but then you lose fast fsck of your nice small
root partition. (Not a big loss, but still...)

> You then store this script in, say, "/sbin", and then you invoke it via 
> the kernel's parameter line in the bootloader - for LILO, that's on the 
> "append=" line - like so...
>    append="init=/sbin/pre-init.sh"

Would work, subject to binaries actually being available.

> But of course, that too will break if "/sbin" is going to be a symbolic 
> link to "/usr/sbin".  So they are really pushing the initramfs route.  

Or at least no separate /usr. udev needs to be fixed... :-|

> (I hate those things. :p)

Me too. (Except on installation media.)

[snip]
> But either way, I expect that ext4 too is soon going to be deprecated in 
> favor of btrfs,

I doubt very much that ext4 will disappear. I do expect ext2 and ext3 to
disappear completely (in the kernel) into ext4, though.

[snip]
-- 
|  _  | Darren Salt, using Debian GNU/Linux (and Android)
| ( ) |
|  X  | ASCII Ribbon campaign against HTML e-mail
| / \ | http://www.asciiribbon.org/

The larger the empire, the smaller the minds behind it.

At Wed, 01 Feb 2012 00:24:18 +0100 Aragorn <stryder@telenet.be.invalid> wrote:

> 
> Following up on my own post because I realized I've made a logical 
> error... ;-)
> 
> On Tuesday 31 January 2012 03:16, Aragorn conveyed the following to 
> comp.os.linux.misc...
> 
> > On Monday 30 January 2012 09:51, Loki Harfagr conveyed the following
> > to comp.os.linux.misc...
> > 
> >> well, long live Slackware then, good news :-)
> > 
> > Yes, I don't expect Slack to be switching to systemd any time soon.
> > However, since the new udevd release now installs itself under "/usr",
> > the breakage is already introduced, and so sooner or later even
> > Slackware will have to adopt the new udev, and will no longer be able
> > to boot without an initramfs or initrd if you happen to have "/usr" on
> > a separate partition.
> > 
> > Well...  That is to say...  There is a workaround, but this will still
> > require that "/usr" be mounted even when booting up in single-user
> > mode. The workaround is to, instead of using an initrd/initrams - for
> > instance if you roll your own kernels - use a pre-init script which
> > mounts "/usr" (and whatever else you would like it to mount) and then
> > calls the actual init via exec, like so...  (Note: location of GNU
> > Bash and init adapted to the future scenario and using ext4.)
> > 
> >    #!/usr/bin/bash
> >    mount -t -ro ext4 /dev/sda2 /usr
> >    exec /usr/bin/init
> > 
> > You then store this script in, say, "/sbin", and then you invoke it
> > via the kernel's parameter line in the bootloader - for LILO, that's
> > on the "append=" line - like so...
> > 
> >    append="init=/sbin/pre-init.sh"
> > 
> > But of course, that too will break if "/sbin" is going to be a
> > symbolic link to "/usr/sbin".  So they are really pushing the
> > initramfs route.
> 
> There's my logical error, in the contents of the pre-init.sh script.  
> There's no way to invoke "/usr/bin/bash" when "/usr" hasn't been mounted 
> yet, and "mount" itself will then also reside in "/usr/bin".
> 
> So they really _did_ break it in all ways...  One now _must_ use an 
> initramfs or initrd.  I suspect that the initramfs will probably be 
> carrying busybox or something similar to provide for the "mount" and 
> "fsck" commands.

With RHEL 6 / CentOS 6 and recent Fedoras, it is no longer possible to
have /usr on a separate partition from the root file system -- various
bits and pieces on /usr are needed early in the boot process.

Unless you build custom (monolithic) kernels, an initrd is pretty much
needed for modern systems -- SATA disks are in the same boat as SCSI
disks were -- different controllers needing different drivers, plus the
SCSI disk abstraction layer module (sd.ko) is needed.  And with
advanced IDE controllers (what few remain), the same is true.  Only
old-school low-end IDE controllers are supported by the compiled-in IDE
driver. When you add in LVM and/or RAID, you have another module or
three to load, so you need an initrd for that too.  It is pretty much a
given that a modern distro on a modern machine needs to boot with a
initrd or initramfs. 

> 

-- 
Robert Heller             -- 978-544-6933 / heller@deepsoft.com
Deepwoods Software        -- http://www.deepsoft.com/
()  ascii ribbon campaign -- against html e-mail
/\  www.asciiribbon.org   -- against proprietary attachments


                                                                                                                  

On Wednesday 01 February 2012 00:55, Robert Heller conveyed the 
following to comp.os.linux.misc...

> At Wed, 01 Feb 2012 00:24:18 +0100 Aragorn
> <stryder@telenet.be.invalid> wrote:
> 
>> 
>> Following up on my own post because I realized I've made a logical
>> error... ;-)
>> 
>> On Tuesday 31 January 2012 03:16, Aragorn conveyed the following to
>> comp.os.linux.misc...
>> 
>> > On Monday 30 January 2012 09:51, Loki Harfagr conveyed the
>> > following to comp.os.linux.misc...
>> > 
>> >> well, long live Slackware then, good news :-)
>> > 
>> > Yes, I don't expect Slack to be switching to systemd any time soon.
>> > However, since the new udevd release now installs itself under
>> > "/usr", the breakage is already introduced, and so sooner or later
>> > even Slackware will have to adopt the new udev, and will no longer
>> > be able to boot without an initramfs or initrd if you happen to
>> > have "/usr" on a separate partition.
>> > 
>> > Well...  That is to say...  There is a workaround, but this will
>> > still require that "/usr" be mounted even when booting up in
>> > single-user mode. The workaround is to, instead of using an
>> > initrd/initrams - for instance if you roll your own kernels - use a
>> > pre-init script which mounts "/usr" (and whatever else you would
>> > like it to mount) and then
>> > calls the actual init via exec, like so...  (Note: location of GNU
>> > Bash and init adapted to the future scenario and using ext4.)
>> > 
>> >    #!/usr/bin/bash
>> >    mount -t -ro ext4 /dev/sda2 /usr
>> >    exec /usr/bin/init
>> > 
>> > You then store this script in, say, "/sbin", and then you invoke it
>> > via the kernel's parameter line in the bootloader - for LILO,
>> > that's on the "append=" line - like so...
>> > 
>> >    append="init=/sbin/pre-init.sh"
>> > 
>> > But of course, that too will break if "/sbin" is going to be a
>> > symbolic link to "/usr/sbin".  So they are really pushing the
>> > initramfs route.
>> 
>> There's my logical error, in the contents of the pre-init.sh script.
>> There's no way to invoke "/usr/bin/bash" when "/usr" hasn't been
>> mounted yet, and "mount" itself will then also reside in "/usr/bin".
>> 
>> So they really _did_ break it in all ways...  One now _must_ use an
>> initramfs or initrd.  I suspect that the initramfs will probably be
>> carrying busybox or something similar to provide for the "mount" and
>> "fsck" commands.
> 
> With RHEL 6 / CentOS 6 and recent Fedoras, it is no longer possible to
> have /usr on a separate partition from the root file system -- various
> bits and pieces on /usr are needed early in the boot process.

Well, they are contradicting that.  As it just so happens to be, I've 
been discussing this only yesterday in another newsgroup, where someone 
provided the links.  Let me see whether I can dig it up...

Ah, here it is...

 <http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge>

Scroll down to where it says "Myths and Facts".  Note however that a lot 
of those "myths and facts" are just propaganda, as they are using self-
referential logic to make their case.

But that said, it should still be possible to have a separate (and read-
only) "/usr" filesystem, as long as it is mounted from within the initrd 
or initramfs, presumably by having busybox in an initramfs.

Still, it's a kludge that only arose from some stupid agenda that 
they're pushing to be more compatible with Oracle, who since the 
acquisition of Sun Microsystems now own the patents to Solaris, and with 
whom RedHat is in close cooperation on a number of projects.

> Unless you build custom (monolithic) kernels, an initrd is pretty much
> needed for modern systems -- SATA disks are in the same boat as SCSI
> disks were -- different controllers needing different drivers, plus
> the SCSI disk abstraction layer module (sd.ko) is needed.

Yes, but you can build that straight into the kernel, and given the 
popularity of SATA drives these days, I would really be surprised if the 
SCSI midlayer and at least the libata2 code wasn't directly linked into 
the stock distribution kernels yet, since just about everyone needs that 
these days.  

But then still, that's not the issue.  The issue is that you will be 
needing an initrd or an initramfs - and most probably the latter - 
_even_ _when_ you build your own kernel from sources.

> And with advanced IDE controllers (what few remain), the same is true. 
> Only old-school low-end IDE controllers are supported by the compiled-
> in IDE driver. When you add in LVM and/or RAID, you have another
> module or three to load, so you need an initrd for that too.

In a stock distribution-supplied kernel, yes.  But when I build a kernel 
myself, then I know exactly what hardware I have in my system, and I 
build all the free software drivers for that hardware straight into the 
kernel.  Of course, you can't do that with a proprietary nVidia driver, 
but before this "/usr" merge folly came along, having the required 
drivers for accessing the boot disk in your kernel was sufficient and 
did not require an initrd or initramfs.

> It is pretty much a given that a modern distro on a modern machine
> needs to boot with a initrd or initramfs.

Yes, and it is this requirement that has been artificially introduced by 
(mainly) Kay Sievers, this Lennert something guy and Greg Kroah-Hartman, 
and which did not exist in the past for those of us who build their own 
kernels.

In a distribution like Gentoo for instance, compiling one's kernel is 
part of the installation process, and given that the tools for creating 
an initramfs do not automatically take care of mounting "/usr" at boot 
time, this move by RedHat's developers is a pain in the butt for Gentoo 
users, who have always been used to booting up without an initramfs or 
initrd.

I can see their point about now making it more easy to have the system 
binaries all on a read-only filesystem, but it makes things much harder 
on people who do not use distribution-supplied binary kernel images, and 
- what I consider quite an important thing to consider here - it goes 
against their earlier statements of about a four to six weeks ago, when 
they said that there was no reason whatsoever to have "/usr" on a 
separate filesystem, while they are now advocating that very same model 
under the claim that it makes snapshotting of the whole system easier.  

So that tells me that they're winging it, and that there is obviously 
another reason as to why they are putting their stuff - i.e. systemd and 
udevd - under "/usr".  And that reason may just be an initial stupidity 
which their egos are too big to admit to now and which they are as such 
now trying to justify by way of having a separate and read-only mounted 
"/usr".

P.S.: I do not oppose to having a read-only "/usr".  I've been setting
      up all my systems like that for over a decade already.  I also
      have a read-only "/opt", a read-only "/boot" and a read-only
      "/usr/local".

-- 
= Aragorn =
(registered GNU/Linux user #223157)

On Wednesday 01 February 2012 00:46, Darren Salt conveyed the following 
to comp.os.linux.misc...

> I demand that Aragorn may or may not have written...
> 
>> The workaround is to, instead of using an initrd/initrams - for
>> instance if you roll your own kernels - use a pre-init script which
>> mounts "/usr" (and whatever else you would like it to mount) and then
>> calls the actual init
>> via exec, like so...  (Note: location of GNU Bash and init adapted to
>> the future scenario and using ext4.)
> 
>>    #!/usr/bin/bash
>>    mount -r -t ext4 /dev/sda2 /usr
>>    exec /usr/bin/init
> 
> Slight issue: you need to have bash (or, better, dash) in /usr with
> the real /usr not mounted. I'd be more likely to dpkg-divert some
> files and add symlinks so that what's necessary to allow /usr to be
> mounted is available and will be updated when packages are updated.

Yes, I realized my mistake, which is why I posted a follow-up to my own 
post. ;-)

> Also, assuming that /etc/fstab isn't going to be moved, you can omit
> the type and partition name.

True.  But the commands would have to be issued like that if they were 
being issued from within the initramfs.  I guess I just typed them up 
here as such. ;-)

> devtmpfs ensures presence of the device nodes, so no problem there.
> 
> Of course, it's better to have udev work without needing this or not
> to bother with separate /usr – but then you lose fast fsck of your
> nice small root partition. (Not a big loss, but still...)

I prefer having a separate and read-only mounted "/usr" myself.

>> You then store this script in, say, "/sbin", and then you invoke it
>> via the kernel's parameter line in the bootloader - for LILO, that's
>> on the "append=" line - like so...
>>    append="init=/sbin/pre-init.sh"
> 
> Would work, subject to binaries actually being available.

Yes, and that appears to be the problem.  As I have stated in my 
correcting follow-up, it would indeed appear that the binaries are no 
longer available without that "/usr" is already mounted, barring the 
scenario where you have an initramfs with busybox or a similar small 
toolbox.

>> But of course, that too will break if "/sbin" is going to be a
>> symbolic link to "/usr/sbin".  So they are really pushing the
>> initramfs route.
> 
> Or at least no separate /usr. udev needs to be fixed... :-|

According to their statements on opendesktop.org - see my reply to 
Robert Heller - they are definitely not planning on that, and they are 
instead advocating having everything under "/usr".

>> (I hate those things. :p)
> 
> Me too. (Except on installation media.)

Well, of course.  Installation media and live CDs/DVDs are a totally 
different beast altogether.

> [snip]
>> But either way, I expect that ext4 too is soon going to be deprecated
>> in favor of btrfs,
> 
> I doubt very much that ext4 will disappear. I do expect ext2 and ext3
> to disappear completely (in the kernel) into ext4, though.

I didn't mean to say that it would disappear, but rather that 
distributions will be pushing btrfs - some already are doing just that - 
as the "default", and given how many people simply accept the defaults 
upon installation, the percentage of ext4 systems is most likely about 
to thin out in the near future.

-- 
= Aragorn =
(registered GNU/Linux user #223157)

On Tue, 31 Jan 2012 18:24:18 -0500, Aragorn <stryder@telenet.be.invalid> wrote:

> initramfs or initrd.  I suspect that the initramfs will probably be
> carrying busybox or something similar to provide for the "mount" and
> "fsck" commands.

The dracut generated initramfs uses bash.

Regards, Dave Hodgins

-- 
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

On Tue, 31 Jan 2012 20:01:51 -0500, Aragorn <stryder@telenet.be.invalid> wrote:

> Scroll down to where it says "Myths and Facts".  Note however that a lot
> of those "myths and facts" are just propaganda, as they are using self-
> referential logic to make their case.
>
> But that said, it should still be possible to have a separate (and read-
> only) "/usr" filesystem, as long as it is mounted from within the initrd
> or initramfs, presumably by having busybox in an initramfs.

Systemd didn't create the problem.  The problem is that udev has to
be started before the root filesystem is mounted, in order to work
properly, and a lot of udev scripts use stuff in /usr.

Systemd needs udev to work properly, which identified the problem.

The solution being used is to start udev with a very limited number
of rules, mount the root filesystem and /usr, and then reload the
rules in udev.

Regards, Dave Hodgins

-- 
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

On Wednesday 01 February 2012 03:25, David W. Hodgins conveyed the 
following to comp.os.linux.misc...

> On Tue, 31 Jan 2012 18:24:18 -0500, Aragorn
> <stryder@telenet.be.invalid> wrote:
> 
>> initramfs or initrd.  I suspect that the initramfs will probably be
>> carrying busybox or something similar to provide for the "mount" and
>> "fsck" commands.
> 
> The dracut generated initramfs uses bash.

Okay, but "fsck" and "mount" are not internal to bash, so they would 
have to be provided for as well then.  There's probably a set of other 
utilities that could be necessary to repair or diagnose a system for in 
the event that "/usr" is not available - e.g. if "/usr" happens to be on 
a disk that has crashed.

-- 
= Aragorn =
(registered GNU/Linux user #223157)

On 01/27/2012 10:49 PM, Todd wrote:
> On 01/27/2012 05:22 PM, Keith Keller wrote:
>> The OP did not specify, but I inferred that he wanted to reboot every so
>> often, in order to force an fsck. If that's not correct he needs to
>> clarify.
>
> It is for targeted reboots with fsck to get fsck out of the way so
> the customer does not have wait around practice his swearing
> technique (my name prominently inserted) while he waits for a
> long fsck on reboot.
>
> We have a lot of power problems are these parts. And, some of my
> customers turn their servers off over the weekend.
>
> I mainly use the targeted reboots to clear AHCI failure to mount
> issued with removable backup disks.
>
> -T


And yesterday, another reason to target a reboot.  I was
at a customer site that had not done his updates (leaves it
for me whenever I visit).  The kernel updates wanted a
reboot, which could not be done during the workday.  So,
after the updates installed and wanted a reboot, I said no
and let loose a reboot and fsck at 22:00.