Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #3921 > unrolled thread

How do you use the "at" command?

Back to article view | Back to comp.os.linux.misc

Contents

  How do you use the "at" command? Todd <Todd@invalid.invalid> - 2012-01-27 10:16 -0800
    Re: How do you use the "at" command? Lew Pitcher <lpitcher@teksavvy.com> - 2012-01-27 13:43 -0500
      Re: How do you use the "at" command? Lew Pitcher <lpitcher@teksavvy.com> - 2012-01-27 13:45 -0500
        Re: How do you use the "at" command? Robert Heller <heller@deepsoft.com> - 2012-01-27 15:34 -0600
          Re: How do you use the "at" command? Todd <Todd@invalid.invalid> - 2012-01-27 22:41 -0800
            Re: How do you use the "at" command? Loki Harfagr <l0k1@thedarkdesign.free.fr.INVALID> - 2012-01-28 10:27 +0000
              Re: How do you use the "at" command? Aragorn <stryder@telenet.be.invalid> - 2012-01-28 19:05 +0100
                Re: How do you use the "at" command? Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> - 2012-01-28 10:26 -0800
                Re: How do you use the "at" command? Loki Harfagr <l0k1@thedarkdesign.free.fr.INVALID> - 2012-01-30 08:51 +0000
                  Re: How do you use the "at" command? Aragorn <stryder@telenet.be.invalid> - 2012-01-31 03:16 +0100
                    Re: How do you use the "at" command? Aragorn <stryder@telenet.be.invalid> - 2012-02-01 00:24 +0100
                      Re: How do you use the "at" command? Robert Heller <heller@deepsoft.com> - 2012-01-31 17:55 -0600
                        Re: How do you use the "at" command? Aragorn <stryder@telenet.be.invalid> - 2012-02-01 02:01 +0100
                          Re: How do you use the "at" command? "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2012-01-31 21:36 -0500
                      Re: How do you use the "at" command? "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2012-01-31 21:25 -0500
                        Re: How do you use the "at" command? Aragorn <stryder@telenet.be.invalid> - 2012-02-01 04:57 +0100
                    Re: How do you use the "at" command? Darren Salt <news@youmustbejoking.demon.cu.invalid> - 2012-01-31 23:46 +0000
                      Re: How do you use the "at" command? Aragorn <stryder@telenet.be.invalid> - 2012-02-01 02:12 +0100
    Re: How do you use the "at" command? Richard Kettlewell <rjk@greenend.org.uk> - 2012-01-27 19:10 +0000
      Re: How do you use the "at" command? Todd <Todd@invalid.invalid> - 2012-01-27 11:17 -0800
        Re: How do you use the "at" command? Robert Heller <heller@deepsoft.com> - 2012-01-27 15:34 -0600
    Re: How do you use the "at" command? unruh <unruh@invalid.ca> - 2012-01-27 20:26 +0000
      Re: How do you use the "at" command? Todd <Todd@invalid.invalid> - 2012-01-27 22:51 -0800
    Re: How do you use the "at" command? Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> - 2012-01-27 12:23 -0800
      Re: How do you use the "at" command? Robert Heller <heller@deepsoft.com> - 2012-01-27 15:35 -0600
        Re: How do you use the "at" command? Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> - 2012-01-27 17:22 -0800
          Re: How do you use the "at" command? Robert Heller <heller@deepsoft.com> - 2012-01-27 20:25 -0600
            Re: How do you use the "at" command? Todd <Todd@invalid.invalid> - 2012-01-27 22:49 -0800
              Re: How do you use the "at" command? Bit Twister <BitTwister@mouse-potato.com> - 2012-01-28 07:16 +0000
                Re: How do you use the "at" command? Todd <Todd@invalid.invalid> - 2012-01-27 23:57 -0800
          Re: How do you use the "at" command? Todd <Todd@invalid.invalid> - 2012-01-27 22:49 -0800
            Re: How do you use the "at" command? Robert Heller <heller@deepsoft.com> - 2012-01-28 06:07 -0600
              Re: How do you use the "at" command? Todd <Todd@invalid.invalid> - 2012-01-28 13:32 -0800
                Re: How do you use the "at" command? Robert Heller <heller@deepsoft.com> - 2012-01-28 22:28 -0600
                  Re: How do you use the "at" command? Todd <Todd@invalid.invalid> - 2012-01-28 22:50 -0800
                    Re: How do you use the "at" command? Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> - 2012-01-28 23:35 -0800
                      Re: How do you use the "at" command? unruh <unruh@invalid.ca> - 2012-01-29 18:46 +0000
                        Re: How do you use the "at" command? Todd <Todd@invalid.invalid> - 2012-01-29 12:03 -0800
                          Re: How do you use the "at" command? Robert Heller <heller@deepsoft.com> - 2012-01-29 15:38 -0600
                            Re: How do you use the "at" command? Todd <Todd@invalid.invalid> - 2012-01-29 16:58 -0800
                          Re: How do you use the "at" command? unruh <unruh@invalid.ca> - 2012-01-30 01:36 +0000
                            Re: How do you use the "at" command? Aragorn <stryder@telenet.be.invalid> - 2012-01-30 03:07 +0100
                              Re: How do you use the "at" command? Todd <Todd@invalid.invalid> - 2012-01-29 19:21 -0800
                            Re: How do you use the "at" command? Todd <Todd@invalid.invalid> - 2012-01-29 19:17 -0800
                      Re: How do you use the "at" command? Todd <Todd@invalid.invalid> - 2012-01-29 11:48 -0800
                    Re: How do you use the "at" command? Robert Heller <heller@deepsoft.com> - 2012-01-29 07:35 -0600
                      Re: How do you use the "at" command? Aragorn <stryder@telenet.be.invalid> - 2012-01-29 20:40 +0100
            Re: How do you use the "at" command? Todd <Todd@invalid.invalid> - 2012-02-03 13:25 -0800
        Re: How do you use the "at" command? Todd <Todd@invalid.invalid> - 2012-01-27 22:45 -0800
      Re: How do you use the "at" command? Todd <Todd@invalid.invalid> - 2012-01-27 22:42 -0800

Page 1 of 3  [1] 2 3  Next page →

#3921 — How do you use the "at" command?

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

[toc] | [next] | [standalone]

#3922

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

[toc] | [prev] | [next] | [standalone]

#3923

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

[toc] | [prev] | [next] | [standalone]

#3934

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


                                                                                 

[toc] | [prev] | [next] | [standalone]

#3956

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

[toc] | [prev] | [next] | [standalone]

#3965

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 ;>)

[toc] | [prev] | [next] | [standalone]

#3976

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)

[toc] | [prev] | [next] | [standalone]

#3978

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

[toc] | [prev] | [next] | [standalone]

#4016

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 ;->

[toc] | [prev] | [next] | [standalone]

#4033

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)

[toc] | [prev] | [next] | [standalone]

#4045

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)

[toc] | [prev] | [next] | [standalone]

#4047

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


                                                                                                                  

[toc] | [prev] | [next] | [standalone]

#4049

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)

[toc] | [prev] | [next] | [standalone]

#4052

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.)

[toc] | [prev] | [next] | [standalone]

#4051

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.)

[toc] | [prev] | [next] | [standalone]

#4054

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)

[toc] | [prev] | [next] | [standalone]

#4048

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.

[toc] | [prev] | [next] | [standalone]

#4050

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)

[toc] | [prev] | [next] | [standalone]

#3924

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/

[toc] | [prev] | [next] | [standalone]

#3925

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?

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.os.linux.misc

csiph-web