Re: complicated downgrade
Tue, Jul 22, 2003 at 09:20:30, bmilekic wrote about "Re: complicated downgrade": > This sounds like the same symptoms as the latest USB problem... > when/if you track -current or even run one of the 5.x releases, it's > key to realize that this is very active code that you're running; it's > not the same thing as running 4.x, for example. The code in 5.x is > constantly actively changing, whereas the code in 4.x only receives > comparatively well-regulated merges from 5.x, for the most part. > Therefore, one of the things to always try is to update to the latest > -current, rebuild, and see if you can reproduce. Chances are, your > problem may have been fixed and, if not, at least we can be confident > that it's reproducable on your hardware with the latest sources. Well, I can do such mad rides on home machine, but not on remote collocation in another country. Running fresh -current I can get a bunch of some other problems which effectively will prevent system from running ;( The most problem I see preventing having much more wide testbase for -current is continuous nature of its committing. If it were developed, e.g., on week pulse, with only fixing bugs since Thu till Mon, and providing semi-stable snapshot on Mon, it can be more attractive to many users which want to track -current but have no will to deal with permanent panics... (Pulse iteration length can be arbitrary. One week is one averagely reasonable value. 3 months, as in RELENG_4, is too long.) -netch- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: complicated downgrade
On Tue, Jul 22, 2003 at 09:01:06AM +0300, Valentin Nechayev wrote: > Mon, Jul 21, 2003 at 23:40:05, des wrote about "Re: complicated downgrade": > > >> I need to downgrade a remote FreeBSD system from 5.1-release to 4.8-release > >> remotely without any local help (except possible hitting Reset). > > Maybe if you tell us why you need to do this we can figure out a way > > for you to avoid doing it? > > System periodically hangs up. Average uptime is ~6 hours. No crash info > is available. No serial console is available. Different invariants didn't > help, AFAIK (this testing was done by another admin, so I'm not 100% sure). > 4.8 in any case is considered more stable, so switching can exclude > some software problems or software-caused triggerings of hardware problems. This sounds like the same symptoms as the latest USB problem... when/if you track -current or even run one of the 5.x releases, it's key to realize that this is very active code that you're running; it's not the same thing as running 4.x, for example. The code in 5.x is constantly actively changing, whereas the code in 4.x only receives comparatively well-regulated merges from 5.x, for the most part. Therefore, one of the things to always try is to update to the latest -current, rebuild, and see if you can reproduce. Chances are, your problem may have been fixed and, if not, at least we can be confident that it's reproducable on your hardware with the latest sources. > Just now question isn't so important because it was decided to move to another > box (including more friendly environment), so my question is more theoretical > than practical. But, there is opportunity to play with configs, so I'll try > again to play with invariants, witnesses, etc. > > Thanks to all for help. > > > -netch- Cheers, -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] TECHNOkRATIS Consulting Services * http://www.technokratis.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: complicated downgrade
Mon, Jul 21, 2003 at 23:40:05, des wrote about "Re: complicated downgrade": >> I need to downgrade a remote FreeBSD system from 5.1-release to 4.8-release >> remotely without any local help (except possible hitting Reset). > Maybe if you tell us why you need to do this we can figure out a way > for you to avoid doing it? System periodically hangs up. Average uptime is ~6 hours. No crash info is available. No serial console is available. Different invariants didn't help, AFAIK (this testing was done by another admin, so I'm not 100% sure). 4.8 in any case is considered more stable, so switching can exclude some software problems or software-caused triggerings of hardware problems. Just now question isn't so important because it was decided to move to another box (including more friendly environment), so my question is more theoretical than practical. But, there is opportunity to play with configs, so I'll try again to play with invariants, witnesses, etc. Thanks to all for help. -netch- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: complicated downgrade
Valentin Nechayev <[EMAIL PROTECTED]> writes: > I need to downgrade a remote FreeBSD system from 5.1-release to 4.8-release > remotely without any local help (except possible hitting Reset). Maybe if you tell us why you need to do this we can figure out a way for you to avoid doing it? DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: complicated downgrade
On Sat, Jul 19, 2003 at 08:48:40AM -0700, LLeweLLyn Reese wrote:
> Valentin Nechayev <[EMAIL PROTECTED]> writes:
> [snip]
> > 8. Disable all processes except sshd and run the following (saying generally):
> >
> >for D in /bin /sbin /etc /boot /usr/bin /usr/sbin /usr/lib /usr/libexec \
> > /usr/libdata /usr/share /usr/local /var/db
> >do
> >mv ${D} ${D}5
> >mv ${D}4 {D}
> >done
> [snip]
>
> Once you mv /usr/lib /usr/lib5, dynamicly linked executables will be
> broken, until you mv /usr/lib4 /usr/lib (I think). I think it
> would be a good idea check every tool you think you might need,
> and build a staticly linked executable if the existing executable
> isn't. Most of what you need will be staticly linked by default,
> but e.g. sshd, ftp, find, vim, are not. (If all goes as planned,
> you won't need any of those while /usr/lib is being moved, but
> ... ) (Caveat: this isn't based on experience with freebsd, it's
> based experience with linux boxen, where *everything* is typically
> staticly linked, unless someone rebuilt tools.)
This thought occurred to me too; actually, you could get around this
problem by rebuilding the whole FreeBSD base system with purely static
binaries. This could be done by putting NOSHARED=yes in /etc/make.conf,
then going through the buildworld/buildkernel/installkernel/installworld
dance. You might have to do this for your 5.x world, reboot with the
statically-linked binaries (just in case), build the 4.x world with
NOSHARED=yes before the downgrade, do the downgrade (without having to
worry about any dynamic libs), then, when the 4.x system is working
(hopefully), rebuild the 4.x world without the NOSHARED=yes setting.
Note that a NOSHARED world tends to take up quite a bit more space :)
G'luck,
Peter
--
Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED]
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
I've heard that this sentence is a rumor.
pgp0.pgp
Description: PGP signature
Re: complicated downgrade
On Fri, Jul 18, 2003 at 09:34:28PM -0700 I heard the voice of Terry Lambert, and lo! it spake thus: > > Your biggest problems are going to be the creation of the /dev, > which will need to occur in an rc.local on reboot, Mightn't you be able to get away with this by something like: - Downgrade / to read-only - Mount / device rw on /mnt - Go into /mnt/dev and run the MAKEDEV -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: complicated downgrade
Valentin Nechayev <[EMAIL PROTECTED]> writes:
[snip]
> 8. Disable all processes except sshd and run the following (saying generally):
>
>for D in /bin /sbin /etc /boot /usr/bin /usr/sbin /usr/lib /usr/libexec \
> /usr/libdata /usr/share /usr/local /var/db
>do
>mv ${D} ${D}5
>mv ${D}4 {D}
>done
[snip]
Once you mv /usr/lib /usr/lib5, dynamicly linked executables will be
broken, until you mv /usr/lib4 /usr/lib (I think). I think it
would be a good idea check every tool you think you might need,
and build a staticly linked executable if the existing executable
isn't. Most of what you need will be staticly linked by default,
but e.g. sshd, ftp, find, vim, are not. (If all goes as planned,
you won't need any of those while /usr/lib is being moved, but
... ) (Caveat: this isn't based on experience with freebsd, it's
based experience with linux boxen, where *everything* is typically
staticly linked, unless someone rebuilt tools.)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: complicated downgrade
Valentin Nechayev wrote: > I need to downgrade a remote FreeBSD system from 5.1-release to 4.8-release > remotely without any local help (except possible hitting Reset). > Don't ask why the collocation provider is too ugly and too far from me; it's > given and unchangeable. This system never was 4.* (began from 5.0-DP2). I have done this before. The best was to deal with this is to create a 5.1 system locally, and deal with all the problems that come up there, transplanting the resulting scripts to the system in question. Your biggest problems are going to be the creation of the /dev, which will need to occur in an rc.local on reboot, replacing the disklabel boot code, and the changes to the conf file for ssh to operate correctly (you will likely need to regenerate keys). If you can't remotely NFS mount a CDROM, a lot of the work is going to be getting access to installation media. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: complicated downgrade
On Fri, 18 Jul 2003, Valentin Nechayev wrote:
> (Cc'ed to phk@ as to main GEOM and DEVFS developer; see corresponding
> questions below.)
>
> Hi,
>
> I need to downgrade a remote FreeBSD system from 5.1-release to 4.8-release
> remotely without any local help (except possible hitting Reset).
> Don't ask why the collocation provider is too ugly and too far from me; it's
> given and unchangeable. This system never was 4.* (began from 5.0-DP2).
>
> I suppose the following algorith to have chance to succeed.
> If anybody can check it and fix, please help.
>
> 1. Download 4.8-release and untar it to the separate tree in file system.
>
> 2. Remove all unneeded for this system (including modules, fore_dlnd,
>mount_portalfs and other unused programs) from directories placed
>on root fs; this is due to its small size (~64M).
>
> 3. Place directories for 4.8 as /bin4, /sbin4, /etc4, /boot4, /usr/lib4, etc.
>
> 4. Place kernel for this system as /kernel; add /kernel.GENERIC also.
>
> 5. Run MAKEDEV in /dev4 for all standard entries and entries for specific
>disks (/dev/ar0s1a, etc.)
>
> 6. Add minimal site-specific contents to /etc4, enough to boot and run sshd
> to allow admin to enter. It includes master.passwd (with admin entry),
> /etc/ssh/* (copied keys and configs), /etc/resolv.conf, /etc/rc.conf,
> /etc/fstab, /etc/group (allowing su); what else?
>
> 7. (The most horrible step.)
>
>Goal is to have /dev on disk (not DEVFS!) appropriate for booting 4.8.
>Two alternatives are possible:
>
>7a.1. Patch kernel to disable GEOM's protection against writing to
> devices which is mounted or have mounted subparts.
> (Here is most foggy place: I don't know how to do it in such way
> as to disable rereading of disk structure on this place.)
>7a.2. Reboot with patched kernel.
>7a.3. Use a binary editor and renames root directory entries directly:
> /dev4 to /dev, /dev to /dev5. (If entry name length matters,
> use, e.g., de4 instead of dev4.)
>7a.4. Immediately reboot as to prevent namei subsystem damage.
>
>Result of all this is that devfs is mounted not over empty directory
>(or only with standard entries, without local specific disks), but over
>full working one.
>
>Alternative variant for step 7:
>
>7b. add code to /sbin/init before mounting devfs: remount root to rw,
>copy entries to it (/bin/cp -Rp). It will work if mount() allows
>remounting to rw without correct /dev entry (this may have problems,
>as I saw on 4.8). Reboot to run this code from init.
>
> 8. Disable all processes except sshd and run the following (saying generally):
>
>for D in /bin /sbin /etc /boot /usr/bin /usr/sbin /usr/lib /usr/libexec \
> /usr/libdata /usr/share /usr/local /var/db
>do
>mv ${D} ${D}5
>mv ${D}4 {D}
>done
>
> 9. Reboot and hope 4.8 will load and run.
>
> I attached some local outputs to check for unexpectedness.
>
>
> -netch-
This is probably obvious, but whatever you do, I would suggest building a
crash box to locally test the procedure on beforehand. I made the mistake
of not perfectly testing a remote upgrade once upon a time, and will never
do it again.
- Matt
--
Matt Loschert - Software Engineer | email: [EMAIL PROTECTED]|
ServInt Internet Services | web: http://www.servint.net/ |
McLean, Virginia USA| phone: (703) 847-1381 |
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: complicated downgrade
Fri, Jul 18, 2003 at 12:44:33, nick wrote about "Re: complicated downgrade":
> +>do
> +>mv ${D} ${D}5
> +>mv ${D}4 {D}
> +>done
> Here is a race:)
> # mv /bin /bin5
> # mv /bin4 /bin
> mv: Command not found.
PATH=/bin4:/bin:/bin5/...
I used the same at home for a long time to switch 4.* <-> 5.0
-netch-
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: complicated downgrade
On Fri, Jul 18, 2003 at 12:12:48PM +0300, Valentin Nechayev wrote:
This is really hard task...
+>for D in /bin /sbin /etc /boot /usr/bin /usr/sbin /usr/lib /usr/libexec \
+> /usr/libdata /usr/share /usr/local /var/db
+>do
+>mv ${D} ${D}5
+>mv ${D}4 {D}
+>done
Here is a race:)
# mv /bin /bin5
# mv /bin4 /bin
mv: Command not found.
:)
--
Pawel Jakub Dawidek [EMAIL PROTECTED]
UNIX Systems Programmer/Administrator http://garage.freebsd.pl
Am I Evil? Yes, I Am! http://cerber.sourceforge.net
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: complicated downgrade
In message <[EMAIL PROTECTED]>, Valentin Nechayev writes: >(Cc'ed to phk@ as to main GEOM and DEVFS developer; see corresponding >questions below.) I'm on vacation right now, and sort of semi offline (you know, the undocumented ACPI S-1 "wife mandated offline state" :-) In addition to what you already have discovered, you _may_ have an issue with your bsd disklabels (too). I would probably do it like this (assuming you have remote console): Put 4.8 kernel and a 4.8 mfsroot image (with plenty of fixit like stuff, size is not a big issue if you boot this from disk) on the 5.x system, boot that kernel using the mfsroot as root filesystem and try to do the surgery from there. The advantage to this approach is that you can explore the issues returning to your 5.x installation and adjust your approach. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: complicated downgrade
On Fri, Jul 18, 2003 at 12:12:48PM +0300, Valentin Nechayev typed:
>
> 8. Disable all processes except sshd and run the following (saying generally):
>
>for D in /bin /sbin /etc /boot /usr/bin /usr/sbin /usr/lib /usr/libexec \
> /usr/libdata /usr/share /usr/local /var/db
>do
>mv ${D} ${D}5
>mv ${D}4 {D}
>done
I think you're screwed the moment $D == /usr/lib
-Ruben
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: complicated downgrade
Hi, Valentin Nechayev wrote on Fri, Jul 18, 2003 at 12:12:48PM +0300: [..] > I need to downgrade a remote FreeBSD system from 5.1-release to 4.8-release > remotely without any local help (except possible hitting Reset). > Don't ask why the collocation provider is too ugly and too far from me; it's > given and unchangeable. This system never was 4.* (began from 5.0-DP2). [..] I predict, you will need serial console access. Chances are very high, that something even minor goes wrong, such that you cannot login to the box using ssh at some stage. You might still be able to complete the downgrade if you would have console access. People, who can hit the reset button, can also connect two serial ports with a null modem cable. So you should convince somebody to do that. Set up the serial console port on the machine should be feasable remotely without great risks. For the 4.x System you should also provide a kernel with serial console enabled. You chance of success will be much better, as I would see it. Good luck, Daniel -- IRCnet: Mr-Spock- All your .sigs are belong to us - Daniel Lang * [EMAIL PROTECTED] * +49 89 289 18532 * http://www.leo.org/~dl/ smime.p7s Description: S/MIME cryptographic signature
