A "last best rootfs"

[wxtofly]

I made the mistake of running pacman -Su on my pogoplug v3 oxnas.
If you are tempted, do not do it!
The upshot was that I could no longer talk to it after a reboot. (The serial port has never worked reliably.)

Coming to look for help I found the 10 old no-more-support notice.
I also found a main thread http://archlinux.2023198.n4.nabble.com/ ... 83514.html
that referenced the November announcement of a discontinuation of initscript support.

https://www.archlinux.org/news/end-of-i ... s-support/

Fortunately, I had a backup of the pre-pacman -Su system that is now running and I have access to the pogoplug again.

My question is this: Given this EOL state, Is there a Last Best rootfs for the pogoplug oxnas device that I can set and forget until I am inspired to find a new device with sata ports?
TJ
wxtofly

[wxtofly]

Should we assume that the 2012-Dec-04 is the last best rootfs?

Are there any subsequent upgrades that can be safely made without turning off things like sshd, that doesn't seem to run properly from systemd, but woks fine from initscripts.

If I run single upgrades for packages, should they be OK? Compatible with the mixed system and all?

My system is running again after restoring from backup the deleted initscripts to /etc/rc.d/ I don't know what the implications of having both are, but the last pacman -Syu I ran made sshd and therefore remote access to the pogoplug vanish. (One would think that sshd would only be removed from /etc/rc.d/ if it was going to be still working via systemd.)

TJ
from http://os.archlinuxarm.org/os/oxnas/
$this->bbcode_second_pass_code('', '
Name Last Modified Size
ArchLinuxARM-2012.02-oxnas.tar.gz 2012-Feb-17 02:30:51 149.7M
ArchLinuxARM-2012.02-oxnas.tar.gz.md5 2012-Feb-17 02:33:05 0.1K
ArchLinuxARM-2012.05-oxnas.tar.gz 2012-May-12 03:49:00 155.3M
ArchLinuxARM-2012.05-oxnas.tar.gz.md5 2012-May-12 03:49:00 0.1K
ArchLinuxARM-2012.12-oxnas.tar.gz 2012-Dec-04 13:37:29 154.1M
ArchLinuxARM-2012.12-oxnas.tar.gz.md5 2012-Dec-04 13:39:04 0.1K
oxnas-install.sh 2012-Jul-26 17:01:12 6.7K application/x-sh
oxnas-revert.sh 2011-Jun-16 02:30:32 3.4K application/x-sh
update-oxnas.tar.gz 2012-Jun-16 21:15:12 10.7M
')

[Geoff]

If you manage to get through all of the upgrades, including the "filesystem" upgrade that moves everything from /bin, /sbin, /usr/sbin into /usr/bin (and creates symlinks to /usr/bin), then you deserve a medal! (To avoid some gotchas, I recommend booting from a backup USB stick and using the "pacman --root" trick to upgrade another USB stick.) Restoring the /etc/rc.d/ and /etc/conf.d/ files gets a bit easier at that point, because you don't need to worry so much about editing these to fix paths to executables; the symlinks take care of most (but not all) of that. The only paths I have found that really need fixing at that point are in lines containing both "readlink" and "grep", which occur for example in /etc/rc.d/sshd and /etc/rc.d/named

I'm curious how many people have actually managed to do all this successfully, and still have working systems.

[chat1410]

$this->bbcode_second_pass_quote('Geoff', 'I')'m curious how many people have actually managed to do all this successfully, and still have working systems.

[moonman]

Somebody knowledgeable who knows how to get past last upgrade should create a new rootfs tarball. I could do it if I had the device but I don't. As long as sshd is running, everything else can be fixed. We can also create a special thread with all the missing initscripts to get these devices (community) going. There are already a couple, but one thread with just the scripts will be better.

[Geoff]

OK, I suppose I can take up the challenge. I can take two alternative approaches, which result in slightly different tarballs:

1. A rootfs that differs as little as possible from the one we're used to, but survives through "pacman -Syu". This leaves relevant as much as possible of the advice in this forum on how to get things (e.g., networking) to work, albeit obsolete and full of hacks as it is.
2. A rootfs that depends as little as possible on initscripts configuration, relying more on the compatibility layer between initscripts and systemd. This makes for more (but still not complete) consistency with the Arch documentation. It moves everything out of /etc/rc.conf except for the DAEMONS list. It means switching from using net-tools (which is obsolete) to netcfg (net-profiles, net-auto-wired, etc.).

I guess when I've done with these, I'll pass them by some of the experts for review and improvements, in case any of them haven't completely washed their hands of this platform. I don't want to turn this into a long-term commitment, though, any more than they do.

[nick2012]

$this->bbcode_second_pass_quote('Geoff', 'O')K, I suppose I can take up the challenge. I can take two alternative approaches, which result in slightly different tarballs:

1. A rootfs that differs as little as possible from the one we're used to, but survives through "pacman -Syu". This leaves relevant as much as possible of the advice in this forum on how to get things (e.g., networking) to work, albeit obsolete and full of hacks as it is.
2. A rootfs that depends as little as possible on initscripts configuration, relying more on the compatibility layer between initscripts and systemd. This makes for more (but still not complete) consistency with the Arch documentation. It moves everything out of /etc/rc.conf except for the DAEMONS list. It means switching from using net-tools (which is obsolete) to netcfg (net-profiles, net-auto-wired, etc.).

I guess when I've done with these, I'll pass them by some of the experts for review and improvements, in case any of them haven't completely washed their hands of this platform. I don't want to turn this into a long-term commitment, though, any more than they do.

[Socaltom]

I have a new tarball of a filesystem created by moonman. He took the 12.12 rootfs and updated it using the known workarounds. As soon as I get it uploaded somewhere I'll post a link. He's away from his computer for a few days due to weather related issues. He did the work on my pro, so I've created the tarball ( hopefully I did that correctly).
Tom

Link below
Thanks
Tom
[url]

[Socaltom]

I tested the tarball. It extracts and boots just fine on m pro.
Tom

[moonman]

I am back in business Finally I was able to return home last night and electricty was on an hour later. Calgary is mess at the moment...

Thank's to Tom for letting me to use his PP Pro, I was able to update 12.12 rootfs past the dreaded glibc update and past the update that moves all binaries to /usr/bin. I am currently uploading it to dropbox so everybody won't load Tom's server.

What I did:

- I had to create filesystem 2013.01 package to get past the glibc update because the latest filesystem package would move everything to /usr/bin/, but new glibc requires at least 2013.01 version. So updated glibc and filesystem - rebooted.
- After that, as usual updated everything except for bash and filesystem.
- moved all the remaining binaries to /usr/bin
-installed bash and filesystem
- Had to dig out initscripts from archlinux git history and manually put them into /etc/rc.d and of course changed the paths to /usr/bin
- These initscripts will not get removed with the package upgrades because they aren't part of the packages anymore

I might have missed some things, but this rootfs does boot up and is usable and ready to take the updates.

Link:
$this->bbcode_second_pass_code('', 'http://dl.dropboxusercontent.com/u/15043728/ArchLinuxArm/oxnas/oxnas-rootfs-2013-06.tar.gz')
There's a 20GB/day download limit for dropbox so here's a mirror:
$this->bbcode_second_pass_code('', 'http://www.mediafire.com/download/ocr1u6hpqj9a8c3/oxnas-rootfs-2013-06.tar.gz')