Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
How do you use the "at" command?
7 views
Skip to first unread message
Todd
Jan 27, 2012, 1:16:30 PM1/27/12
to
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
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
Lew Pitcher
Jan 27, 2012, 1:43:15 PM1/27/12
to
On Friday 27 January 2012 13:16, in comp.os.linux.misc, To...@invalid.invalid
wrote:
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
wrote:
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
Lew Pitcher
Jan 27, 2012, 1:45:34 PM1/27/12
to
On Friday 27 January 2012 13:43, in comp.os.linux.misc,
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
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
Richard Kettlewell
Jan 27, 2012, 2:10:55 PM1/27/12
to
Todd
Jan 27, 2012, 2:17:43 PM1/27/12
to
unruh
Jan 27, 2012, 3:26:06 PM1/27/12
to
On 2012-01-27, Todd <To...@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
> 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"
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)
Keith Keller
Jan 27, 2012, 3:23:54 PM1/27/12
to
On 2012-01-27, Todd <To...@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
> as root at a specific time:
>
> su root -c "touch /forcefsck; reboot"
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...@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
Robert Heller
Jan 27, 2012, 4:34:59 PM1/27/12
to
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 / hel...@deepsoft.com
Deepwoods Software -- http://www.deepsoft.com/
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments
Robert Heller
Jan 27, 2012, 4:35:00 PM1/27/12
to
At Fri, 27 Jan 2012 12:23:54 -0800 Keith Keller <kkeller...@wombat.san-francisco.ca.us> wrote:
>
> On 2012-01-27, Todd <To...@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.
>
> On 2012-01-27, Todd <To...@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".
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
Jan 27, 2012, 4:34:59 PM1/27/12
to
# at ...
#^D
See my other message for more possibities.
Keith Keller
Jan 27, 2012, 8:22:41 PM1/27/12
to
On 2012-01-27, Robert Heller <hel...@deepsoft.com> wrote:
> At Fri, 27 Jan 2012 12:23:54 -0800 Keith Keller <kkeller...@wombat.san-francisco.ca.us> wrote:
>
>>
>> On 2012-01-27, Todd <To...@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
> At Fri, 27 Jan 2012 12:23:54 -0800 Keith Keller <kkeller...@wombat.san-francisco.ca.us> wrote:
>
>>
>> On 2012-01-27, Todd <To...@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.
often, in order to force an fsck. If that's not correct he needs to
clarify.
Robert Heller
Jan 27, 2012, 9:25:10 PM1/27/12
to
At Fri, 27 Jan 2012 17:22:41 -0800 Keith Keller <kkeller...@wombat.san-francisco.ca.us> wrote:
>
> On 2012-01-27, Robert Heller <hel...@deepsoft.com> wrote:
> > At Fri, 27 Jan 2012 12:23:54 -0800 Keith Keller <kkeller...@wombat.san-francisco.ca.us> wrote:
> >
> >>
> >> On 2012-01-27, Todd <To...@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
>
> On 2012-01-27, Robert Heller <hel...@deepsoft.com> wrote:
> > At Fri, 27 Jan 2012 12:23:54 -0800 Keith Keller <kkeller...@wombat.san-francisco.ca.us> wrote:
> >
> >>
> >> On 2012-01-27, Todd <To...@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.
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.
Todd
Jan 28, 2012, 1:41:37 AM1/28/12
to
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:
> # 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
https://bugzilla.redhat.com/show_bug.cgi?id=784960
https://bugzilla.redhat.com/show_bug.cgi?id=733874
:'(
-T
Todd
Jan 28, 2012, 1:42:46 AM1/28/12
to
On 01/27/2012 12:23 PM, Keith Keller wrote:
> On 2012-01-27, Todd<To...@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
> On 2012-01-27, Todd<To...@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
>
>
a pain in the ...
Todd
Jan 28, 2012, 1:45:08 AM1/28/12
to
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:
> 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.
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.
Todd
Jan 28, 2012, 1:49:02 AM1/28/12
to
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 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.
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
Todd
Jan 28, 2012, 1:49:38 AM1/28/12
to
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"?
> *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.
Todd
Jan 28, 2012, 1:51:07 AM1/28/12
to
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.
> at 9:45 Jun 14
> at> touch /forcefsck; reboot
> at>^D
Thank you!
Bit Twister
Jan 28, 2012, 2:16:36 AM1/28/12
to
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:
>
> Yep. Anyone have an example of how to use "at"?
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
Todd
Jan 28, 2012, 2:57:46 AM1/28/12
to
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.
> For extra points, do a
> man at
That is why I asked.
-T
"Just Google it!". The new "RTFM". :'(
Loki Harfagr
Jan 28, 2012, 5:27:21 AM1/28/12
to
Fri, 27 Jan 2012 22:41:37 -0800, Todd did cat :
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 ;>)
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 ;>)
Robert Heller
Jan 28, 2012, 7:07:53 AM1/28/12
to
At Fri, 27 Jan 2012 22:49:02 -0800 Todd <To...@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
>
> 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.
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
>
Aragorn
Jan 28, 2012, 1:05:46 PM1/28/12
to
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)
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.
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 ;>)
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)
Keith Keller
Jan 28, 2012, 1:26:17 PM1/28/12
to
On 2012-01-28, Aragorn <str...@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
>
> 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.
-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.
shared drives could be. The thinking was, on a small fs like /usr the
advantages of XFS over ext3 would be negligible.
Todd
Jan 28, 2012, 4:32:38 PM1/28/12
to
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
> 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.
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
Robert Heller
Jan 28, 2012, 11:28:14 PM1/28/12
to
At Sat, 28 Jan 2012 13:32:38 -0800 Todd <To...@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
>
> 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
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
>
Todd
Jan 29, 2012, 1:50:31 AM1/29/12
to
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
> 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.
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.)
Keith Keller
Jan 29, 2012, 2:35:26 AM1/29/12
to
On 2012-01-29, Todd <To...@invalid.invalid> wrote:
>
> With RH, you get an fsck every 25 or so reboots.
This is changeable or disablable using tune2fs.
>
> 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.
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/ .)
Robert Heller
Jan 29, 2012, 8:35:24 AM1/29/12
to
unruh
Jan 29, 2012, 1:46:09 PM1/29/12
to
On 2012-01-29, Keith Keller <kkeller...@wombat.san-francisco.ca.us> wrote:
> On 2012-01-29, Todd <To...@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
> On 2012-01-29, Todd <To...@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/ .)
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
>
>
>
Aragorn
Jan 29, 2012, 2:40:04 PM1/29/12
to
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 <To...@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
;-)
comp.os.linux.misc...
> At Sat, 28 Jan 2012 22:50:31 -0800 Todd <To...@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
man tune2fs
;-)
Todd
Jan 29, 2012, 2:48:44 PM1/29/12
to
On 01/28/2012 11:35 PM, Keith Keller wrote:
> On 2012-01-29, Todd<To...@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,
> On 2012-01-29, Todd<To...@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
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
Todd
Jan 29, 2012, 3:03:50 PM1/29/12
to
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
> 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.
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
Robert Heller
Jan 29, 2012, 4:38:47 PM1/29/12
to
At Sun, 29 Jan 2012 12:03:50 -0800 Todd <To...@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.
>
> 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.
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.
Todd
Jan 29, 2012, 7:58:40 PM1/29/12
to
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.
> 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.
unruh
Jan 29, 2012, 8:36:16 PM1/29/12
to
On 2012-01-29, Todd <To...@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
>> 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.
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.
Aragorn
Jan 29, 2012, 9:07:00 PM1/29/12
to
On Monday 30 January 2012 02:36, unruh conveyed the following to
comp.os.linux.misc...
> On 2012-01-29, Todd <To...@invalid.invalid> wrote:
>
>> On 01/29/2012 10:46 AM, unruh wrote:
>>
>>> [...] to save power, many businesses request that you shut down
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.
comp.os.linux.misc...
> On 2012-01-29, Todd <To...@invalid.invalid> wrote:
>
>> On 01/29/2012 10:46 AM, unruh wrote:
>>
>>> 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
>>> 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.
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.
Todd
Jan 29, 2012, 10:17:01 PM1/29/12
to
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,
>> 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.
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.
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
Todd
Jan 29, 2012, 10:21:14 PM1/29/12
to
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
Loki Harfagr
Jan 30, 2012, 3:51:07 AM1/30/12
to
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?
...
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 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.
...
> 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
> anything wrong with it insofar as I could see - but I still prefer XFS,
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.
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 ;->
Aragorn
Jan 30, 2012, 9:16:02 PM1/30/12
to
On Monday 30 January 2012 09:51, Loki Harfagr conveyed the following to
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. ;-)
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
> 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
>>>>> -F +5
>>>>>
>>>>> # Shutdown at 11pm and force a fsck on boot. sudo /sbin/shutdown
>>>>> # -F
>>>>>
>>>>> # Shutdown at 11pm and force a fsck on boot. sudo /sbin/shutdown
>>>>> 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
>>>>
>>>> "-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.)
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 :-)
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?
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.
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 ;->
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
Jan 31, 2012, 6:24:18 PM1/31/12
to
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
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.
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...
>
> 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.
>
> 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 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.
Robert Heller
Jan 31, 2012, 6:55:43 PM1/31/12
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.
Message has been deleted
Aragorn
Jan 31, 2012, 8:01:51 PM1/31/12
to
On Wednesday 01 February 2012 00:55, Robert Heller conveyed the
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".
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.
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.
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.
(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
Jan 31, 2012, 8:12:48 PM1/31/12
to
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...
>> 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]
> 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.
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
>> 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
>> 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"
>
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.
>
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)
>
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
>> in favor of btrfs,
>
> 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.
David W. Hodgins
Jan 31, 2012, 9:25:43 PM1/31/12
to
On Tue, 31 Jan 2012 18:24:18 -0500, Aragorn <str...@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.
> initramfs or initrd. I suspect that the initramfs will probably be
> carrying busybox or something similar to provide for the "mount" and
> "fsck" commands.
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.)
David W. Hodgins
Jan 31, 2012, 9:36:45 PM1/31/12
to
On Tue, 31 Jan 2012 20:01:51 -0500, Aragorn <str...@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
> 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.
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.
Aragorn
Jan 31, 2012, 10:57:50 PM1/31/12
to
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
> <str...@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.
following to comp.os.linux.misc...
> On Tue, 31 Jan 2012 18:24:18 -0500, Aragorn
> <str...@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.
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.
Todd
Feb 3, 2012, 4:25:22 PM2/3/12
to
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.
> 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.
0 new messages