[gentoo-user] Pre OpenRC update question...

[gentoo-user] Pre OpenRC update question...

[Tanstaafl]

Probably a dumb one, but...

I have /home, /usr and /var on separate partitions...

If I want to image my system prior to the update 'just in case'
something goes south, am I correct that all I need to worry about is /,
since /etc is located there?

In other words, is anything on /usr or /var touched during this update?

Re: [gentoo-user] Pre OpenRC update question...

[Alan McKinnon]

Apparently, though unproven, at 23:00 on Thursday 12 May 2011, Tanstaafl did 
opine thusly:

> Probably a dumb one, but...
> 
> I have /home, /usr and /var on separate partitions...
> 
> If I want to image my system prior to the update 'just in case'
> something goes south, am I correct that all I need to worry about is /,
> since /etc is located there?
> 
> In other words, is anything on /usr or /var touched during this update?

No.

$ equery files openrc | grep '/usr/|\/var/'
$ equery files baselayout | grep '/usr/|\/var/'
$

All the affected configs are in /etc/

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] Pre OpenRC update question...

[Dale]

Alan McKinnon wrote:
> Apparently, though unproven, at 23:00 on Thursday 12 May 2011, Tanstaafl did
> opine thusly:
>
>    
>> Probably a dumb one, but...
>>
>> I have /home, /usr and /var on separate partitions...
>>
>> If I want to image my system prior to the update 'just in case'
>> something goes south, am I correct that all I need to worry about is /,
>> since /etc is located there?
>>
>> In other words, is anything on /usr or /var touched during this update?
>>      
> No.
>
> $ equery files openrc | grep '/usr/|\/var/'
> $ equery files baselayout | grep '/usr/|\/var/'
> $
>
> All the affected configs are in /etc/
>
>    

That was all I backed up when I did mine to.  If it does go south, just 
re-emerge the old packages and restore /etc from your backups.  Should 
be back to normal.

That said, follow the guide and you should be fine.  It went smoothly 
for me.

Dale

:-)  :-)

Re: [gentoo-user] Pre OpenRC update question...

[Andrew Lowe]

On 13/05/2011 5:00 AM, Tanstaafl wrote:
> Probably a dumb one, but...
>
> I have /home, /usr and /var on separate partitions...
>
> If I want to image my system prior to the update 'just in case'
> something goes south, am I correct that all I need to worry about is /,
> since /etc is located there?
>
> In other words, is anything on /usr or /var touched during this update?
>
>
	If you want to be reeaallyyy safe, and want an image and not a backup, 
grab the latest copy of SystemRescueCd, a couple of TB of usb external 
drive space, which is very cheap these days, and use partImage to grab a 
true image of your whole system. I started doing this recently and it's 
saved me once so far. Things "flew apart big time" for me recently, a 
disk failure, I rebooted into the rescue cd and hey presto, 30 minutes 
later, everything was good.

	Andrew

Re: [gentoo-user] Pre OpenRC update question...

[James Wall]

On Thu, May 12, 2011 at 7:09 PM, Andrew Lowe <agl@wht.com.au> wrote:
> On 13/05/2011 5:00 AM, Tanstaafl wrote:
>>
>> Probably a dumb one, but...
>>
>> I have /home, /usr and /var on separate partitions...
>>
>> If I want to image my system prior to the update 'just in case'
>> something goes south, am I correct that all I need to worry about is /,
>> since /etc is located there?
>>
>> In other words, is anything on /usr or /var touched during this update?
>>
>>
>        If you want to be reeaallyyy safe, and want an image and not a
> backup, grab the latest copy of SystemRescueCd, a couple of TB of usb
> external drive space, which is very cheap these days, and use partImage to
> grab a true image of your whole system. I started doing this recently and
> it's saved me once so far. Things "flew apart big time" for me recently, a
> disk failure, I rebooted into the rescue cd and hey presto, 30 minutes
> later, everything was good.
>
>        Andrew
>
>
Another tool which will work well is dd.
as an example to back up my laptop before experimenting with new
distros, I do dd if=/dev/sda of=/mnt/backup/jalopy.img bs=2M to back
up the drive for a bare metal restore of the 40 GB hard drive.

James Wall

Re: [gentoo-user] Pre OpenRC update question...

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1437 bytes --]

On Friday 13 May 2011 20:11:01 James Wall wrote:
> On Thu, May 12, 2011 at 7:09 PM, Andrew Lowe <agl@wht.com.au> wrote:
> > On 13/05/2011 5:00 AM, Tanstaafl wrote:
> >> Probably a dumb one, but...
> >> 
> >> I have /home, /usr and /var on separate partitions...
> >> 
> >> If I want to image my system prior to the update 'just in case'
> >> something goes south, am I correct that all I need to worry about is /,
> >> since /etc is located there?
> >> 
> >> In other words, is anything on /usr or /var touched during this update?
> > 
> >        If you want to be reeaallyyy safe, and want an image and not a
> > backup, grab the latest copy of SystemRescueCd, a couple of TB of usb
> > external drive space, which is very cheap these days, and use partImage
> > to grab a true image of your whole system. I started doing this recently
> > and it's saved me once so far. Things "flew apart big time" for me
> > recently, a disk failure, I rebooted into the rescue cd and hey presto,
> > 30 minutes later, everything was good.
> > 
> >        Andrew
> 
> Another tool which will work well is dd.
> as an example to back up my laptop before experimenting with new
> distros, I do dd if=/dev/sda of=/mnt/backup/jalopy.img bs=2M to back
> up the drive for a bare metal restore of the 40 GB hard drive.
> 
> James Wall

Is the bs=2M important?  Should one use the block size of the drive?
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Pre OpenRC update question...

[Andrey Moshbear]

On Fri, May 13, 2011 at 18:35, Mick <michaelkintzios@gmail.com> wrote:
> On Friday 13 May 2011 20:11:01 James Wall wrote:
>>
>> Another tool which will work well is dd.
>> as an example to back up my laptop before experimenting with new
>> distros, I do dd if=/dev/sda of=/mnt/backup/jalopy.img bs=2M to back
>> up the drive for a bare metal restore of the 40 GB hard drive.
>>
>
> Is the bs=2M important?  Should one use the block size of the drive?
Speed improvement.
If you're doing a backup of a rather large disk, I duggest piping to
bzip2 or gzip. Unless the free space is random padding, even the
slightest
compression will be more efficient, space-wise, than the raw file. The
big problem is bzip2 -9, because you only get ~2.5 MB/s compression
speed.

Re: [gentoo-user] Pre OpenRC update question...

[James Wall]

On Fri, May 13, 2011 at 9:47 PM, Andrey Moshbear <andrey.vul@gmail.com> wrote:
> On Fri, May 13, 2011 at 18:35, Mick <michaelkintzios@gmail.com> wrote:
>> On Friday 13 May 2011 20:11:01 James Wall wrote:
>>>
>>> Another tool which will work well is dd.
>>> as an example to back up my laptop before experimenting with new
>>> distros, I do dd if=/dev/sda of=/mnt/backup/jalopy.img bs=2M to back
>>> up the drive for a bare metal restore of the 40 GB hard drive.
>>>
>>
>> Is the bs=2M important?  Should one use the block size of the drive?
> Speed improvement.
> If you're doing a backup of a rather large disk, I duggest piping to
> bzip2 or gzip. Unless the free space is random padding, even the
> slightest
> compression will be more efficient, space-wise, than the raw file. The
> big problem is bzip2 -9, because you only get ~2.5 MB/s compression
> speed.
>
>

I set the bs=2M to the size of the hdd cache to push it to the limit
of speed. YMMV, the best thing to do is experiment. You may find a
different number works better.

James Wall

Re: [gentoo-user] Pre OpenRC update question...

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 643 bytes --]

On Fri, 13 May 2011 22:47:43 -0400, Andrey Moshbear wrote:

> > Is the bs=2M important?  Should one use the block size of the drive?  
> Speed improvement.
> If you're doing a backup of a rather large disk, I duggest piping to
> bzip2 or gzip. Unless the free space is random padding, even the
> slightest
> compression will be more efficient, space-wise, than the raw file.

You could also do

dd if=/dev/zero of=somefile bs=1G
rm somefile

to zero the unused blocks, which should both speed up and increase
compression of those areas.

-- 
Neil Bothwick

Copper wire was invented by two Scotsmen fighting over a penny!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Pre OpenRC update question...

[Tanstaafl]

On 2011-05-12 5:46 PM, Dale wrote:
> Alan McKinnon wrote:
>> Apparently, though unproven, at 23:00 on Thursday 12 May 2011,
>> Tanstaafl did opine thusly: 
>>> If I want to image my system prior to the update 'just in case'
>>> something goes south, am I correct that all I need to worry about is /,
>>> since /etc is located there?
>>>
>>> In other words, is anything on /usr or /var touched during this update?

>> All the affected configs are in /etc/

> That was all I backed up when I did mine to.  If it does go south, just
> re-emerge the old packages and restore /etc from your backups.  Should
> be back to normal.
> 
> That said, follow the guide and you should be fine.  It went smoothly
> for me.

Thanks Alan and Dale... but since this is a production server, guess
I'll wait till this weekend to do the deed.

On last question/confirmation -

There are a few updates other than just the baselayout/OpenRC updates
pending... can I still emerge those now, prior to the baselayout update,
like normal?

On that note - I think I asked this a few months ago - I'm assuming I
could continue using the old baselayout for a while, if I wanted,
emerging updates (skipping the baselayout/OpenRC updates) for a while,
without any problems, right?

Thanks again guys... probably fretting over nothing, like the rest of you...

Re: [gentoo-user] Pre OpenRC update question...

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 836 bytes --]

On Mon, May 16, 2011 at 06:47:59AM -0400, Tanstaafl wrote:
> On last question/confirmation -
> 
> There are a few updates other than just the baselayout/OpenRC updates
> pending... can I still emerge those now, prior to the baselayout update,
> like normal?

Yes, as long as they do not have a dependency on the newer baselayout or
openrc.

> On that note - I think I asked this a few months ago - I'm assuming I
> could continue using the old baselayout for a while, if I wanted,
> emerging updates (skipping the baselayout/OpenRC updates) for a while,
> without any problems, right?

I would not recommend doing this. The plan is to support
openrc/baselayout-2 as gentoo's default init system and deprecate
baselayout-1, which will eventually lead to things breaking if you are
still using baselayout-1.

William

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Pre OpenRC update question...

[Tanstaafl]

On 2011-05-16 7:38 AM, William Hubbs wrote:
> On Mon, May 16, 2011 at 06:47:59AM -0400, Tanstaafl wrote:
>> On that note - I think I asked this a few months ago - I'm assuming I
>> could continue using the old baselayout for a while, if I wanted,
>> emerging updates (skipping the baselayout/OpenRC updates) for a while,
>> without any problems, right?

> I would not recommend doing this. The plan is to support
> openrc/baselayout-2 as gentoo's default init system and deprecate
> baselayout-1, which will eventually lead to things breaking if you are
> still using baselayout-1.

Well, sure, I'm not talking about delaying the update for very long,
weeks, maybe, but no more than a month or two at the most.

Re: [gentoo-user] Pre OpenRC update question...

[Dale]

Tanstaafl wrote:
> On 2011-05-16 7:38 AM, William Hubbs wrote:
>    
>> On Mon, May 16, 2011 at 06:47:59AM -0400, Tanstaafl wrote:
>>      
>>> On that note - I think I asked this a few months ago - I'm assuming I
>>> could continue using the old baselayout for a while, if I wanted,
>>> emerging updates (skipping the baselayout/OpenRC updates) for a while,
>>> without any problems, right?
>>>        
>    
>> I would not recommend doing this. The plan is to support
>> openrc/baselayout-2 as gentoo's default init system and deprecate
>> baselayout-1, which will eventually lead to things breaking if you are
>> still using baselayout-1.
>>      
> Well, sure, I'm not talking about delaying the update for very long,
> weeks, maybe, but no more than a month or two at the most.
>
>    

On my old rig, I updated it last night.  On it, nothing else depended on 
openrc and baselayout.  It had other updates and I wanted to do the 
openrc alone so I did emerge -1av openrc and that updated baselayout and 
installed openrc.  I might add, the machine is remotely ran over ssh.  
The only time I touch it is to push the power switch to turn it on.  The 
upgrade was easy enough.  Most of the things in the guide are done 
during the install and can be skipped.  It would be safer to check them 
all tho.  When I finished, I just typed in reboot & exit and a couple 
minutes later, I logged back in.  No problems at all.

If you want to hold off on the updates, just add the packages to 
package.mask and it will skip them so that you can still use world and 
system without pulling them in.

As was already stated, I wouldn't wait to long.  It will most likely 
start to breaking things pretty soon.

Dale

:-)  :-)

Re: [gentoo-user] Pre OpenRC update question...

[Stroller]

On 16/5/2011, at 11:47am, Tanstaafl wrote:
> ...
> On that note - I think I asked this a few months ago - I'm assuming I
> could continue using the old baselayout for a while, if I wanted,
> emerging updates (skipping the baselayout/OpenRC updates) for a while,
> without any problems, right?

I don't believe you can do this safely, as I don't believe that the runtime-depends of all other ebuilds distinguish properly between the old baselayout and OpenRC / baselayout2.

There were some comments here the other week about checking for libraries & programs which has been updated / recompiled, but for which the old versions were still in use. The programs `lib_users` and `checkrestart` were mentioned, and sure enough the latter indicated some init.d scripts; however some of these failed to restart, complaining "I'm written for the new baselayout, not this old crap!".

I run a mostly "stable" x86 system, with a handful of ~x86 packages unmasked by hand, so I can't say this isn't to blame. I personally think the cause is that I synced and updated a handful of packages just as or before the migration warning appeared, and that these were stabilised in preparation for the other. Whatever - I think Portage should be clever enough to say "hang on, this init.d script doesn't match the baselayout verstion - let's not emerge this!", but it doesn't seem to be.

Stroller