View unanswered posts    View active topics

All times are UTC - 6 hours





Post new topic Reply to topic  [ 67 posts ] 
Go to page 1, 2, 3, 4, 5  Next

Print view Previous topic   Next topic  
Author Message
Search for:
PostPosted: Sat Oct 18, 2014 1:06 pm 
Offline
Joined: Sun Apr 30, 2006 7:49 pm
Posts: 37
Location: Ottawa
With the upcoming Schedules Direct change, I thought it might be best to do an upgrade from 8.1 to 8.2, as described in the R8.2 Release Notes on the Roadmap page. I downloaded the upgrade script and executed it. I was not successful, and have recovered from backup, but I'm posting here to provide my experiences so that the upgrade might be less painful for others in the future.

First of all, my system is a bit non-standard because I had to override some behaviour during the installation from the CD. I have a very small SSD for my root filesystem, and the CD installer wanted to take some of that for my recordings directories. I have three 3TB drives in the box for those, so I interfered with the installation procedure in order to get the root filesystem and swap on my SSD and my recordings on the other three drives. Nothing too exotic, but it might be relevant to the breakage.

Fine, so I downloaded the script and ran it. First problem, my community repo mirror has shutdown, and I couldn't find a replacement, so I was getting error messages, but it turns out those were relatively harmless. The glibc and intermediate filesystem packages were downloaded, but I got errors when it tried to install the glibc because the linux-api-headers available to it were for too low a version. I eventually figured out that I had to change my pacman.conf to use core-testing and extra-testing instead of core and extra. It's possible that running part of the upgrade without testing repos messed some things up. After this, things progressed further, but there were still problems. The script failed out, saying that I had /sbin and /usr/sbin directories that had to be removed. However, renaming them and re-running the script caused some subtle badness: the initial RAM disk for the upgraded system was missing everything it wanted from /sbin. Without blkid it couldn't mount the root filesystem, and without runinit and family the boot failed badly. I started added files back into the initrd until it could boot, but my confidence was starting to wane by this point.

While I could eventually boot the computer, it was in a bad state. It couldn't prime its network interface, it had no reboot or shutdown commands, it seemed as if I was missing a large number of commands and files. At this point I gave up on the procedure and recovered from my full disk backup.

Anyway, this is not a complaint, just a report from an unwitting tester. The upgrade script didn't work for me. I look forward to trying again in the future.


Top
 Profile  
 
PostPosted: Sat Oct 18, 2014 6:55 pm 
Offline
Joined: Fri Jul 21, 2006 11:12 pm
Posts: 1194
Location: SC
Quote:
First of all, my system is a bit non-standard because I had to override some behaviour during the installation from the CD. I have a very small SSD for my root filesystem, and the CD installer wanted to take some of that for my recordings directories. I have three 3TB drives in the box for those, so I interfered with the installation procedure in order to get the root filesystem and swap on my SSD and my recordings on the other three drives. Nothing too exotic, but it might be relevant to the breakage.
I am a little confused here. By default the install would create root, home, swap, mysql and if you wanted you could use the rest for recordings but you don't have to. How did you override it?

Quote:
The glibc and intermediate filesystem packages were downloaded, but I got errors when it tried to install the glibc because the linux-api-headers available to it were for too low a version. I eventually figured out that I had to change my pacman.conf to use core-testing and extra-testing instead of core and extra.
Yes, currently in testing you do have to switch you repos to -testing but once we make 8.2 final all the pkgs in testing will be moved to release and the script will operate as intended with the new packages.

Quote:
It's possible that running part of the upgrade without testing repos messed some things up.
Unlikely as the glibc errors you saw because of incorrect kernel version made sure nothing got installed.

Quote:
After this, things progressed further, but there were still problems. The script failed out, saying that I had /sbin and /usr/sbin directories that had to be removed. However, renaming them and re-running the script caused some subtle badness: the initial RAM disk for the upgraded system was missing everything it wanted from /sbin. Without blkid it couldn't mount the root filesystem, and without runinit and family the boot failed badly. I started added files back into the initrd until it could boot, but my confidence was starting to wane by this point.
The root of this is most likely the packages that were installed from non-LinHES repos. But it could also be files that are not owned by any package that the user may have moved into /sbin or /usr/sbin. The non-LinHES packages that were still installed need to be removed before attempting to upgrade. Once that is done there will still be items in /sbin and /usr/sbin but if they are all owned by LinHES packages then when they get updated by the script they will be moved to /usr/bin.

Quote:
While I could eventually boot the computer, it was in a bad state. It couldn't prime its network interface, it had no reboot or shutdown commands, it seemed as if I was missing a large number of commands and files.
It probably was missing quite a few command because they had been moved and then orphaned by renaming /sbin and /usr/sbin. Do you know at what point the script failed out? That dialog about removing /sbin and /usr/sbin needs to be made more clear.

Quote:
Anyway, this is not a complaint, just a report from an unwitting tester. The upgrade script didn't work for me. I look forward to trying again in the future.
Thanks for the feedback.


Top
 Profile  
 
PostPosted: Sat Oct 18, 2014 8:26 pm 
Offline
Joined: Sun Apr 30, 2006 7:49 pm
Posts: 37
Location: Ottawa
brfransen wrote:
Quote:
First of all, my system is a bit non-standard because I had to override some behaviour during the installation from the CD. I have a very small SSD for my root filesystem, and the CD installer wanted to take some of that for my recordings directories. I have three 3TB drives in the box for those, so I interfered with the installation procedure in order to get the root filesystem and swap on my SSD and my recordings on the other three drives. Nothing too exotic, but it might be relevant to the breakage.
I am a little confused here. By default the install would create root, home, swap, mysql and if you wanted you could use the rest for recordings but you don't have to. How did you override it?


I wrote a posting at the time, describing what I had done: http://forum.linhes.org/viewtopic.php?f=22&t=23788.

brfransen wrote:
Quote:
The glibc and intermediate filesystem packages were downloaded, but I got errors when it tried to install the glibc because the linux-api-headers available to it were for too low a version. I eventually figured out that I had to change my pacman.conf to use core-testing and extra-testing instead of core and extra.
Yes, currently in testing you do have to switch you repos to -testing but once we make 8.2 final all the pkgs in testing will be moved to release and the script will operate as intended with the new packages.


OK, I didn't realize that condition. I figured it out when I noticed the URL of the upgrade script to be downloaded.

brfransen wrote:
Quote:
It's possible that running part of the upgrade without testing repos messed some things up.
Unlikely as the glibc errors you saw because of incorrect kernel version made sure nothing got installed.


That's good to know. I'll keep it in mind the next time I do this.

brfransen wrote:
Quote:
After this, things progressed further, but there were still problems. The script failed out, saying that I had /sbin and /usr/sbin directories that had to be removed. However, renaming them and re-running the script caused some subtle badness: the initial RAM disk for the upgraded system was missing everything it wanted from /sbin. Without blkid it couldn't mount the root filesystem, and without runinit and family the boot failed badly. I started added files back into the initrd until it could boot, but my confidence was starting to wane by this point.
The root of this is most likely the packages that were installed from non-LinHES repos. But it could also be files that are not owned by any package that the user may have moved into /sbin or /usr/sbin.


Is there some command I can use through pacman to retrieve the list of non-LinHES repos installed? I scanned the recovered /sbin and found the following packages owning files therein: btrfs-progs crda device-mapper dhcpcd dmraid dosfstools e2fsprogs fuse glibc hdparm iproute2 jfsutils keyutils kmod lvm2 mdadm net-tools nfs-utils nilfs-utils pam pcmciautils poweroff-scripts procps-ng reiserfsprogs runit runit-scripts shadow squashfs-tools systemd-tools sysvinit sysvinit-tools udisks util-linux v86d xfsprogs

There were also poweroff.init and reboot.init that weren't owned by any packages, maybe debris left over from a previous install. I'm guessing xfsprogs is a non-LinHES repo?

brfransen wrote:
The non-LinHES packages that were still installed need to be removed before attempting to upgrade. Once that is done there will still be items in /sbin and /usr/sbin but if they are all owned by LinHES packages then when they get updated by the script they will be moved to /usr/bin.


OK, perhaps the intermediate filesystem installation package should reword its error message there. The implication of the message was that the /sbin and /usr/sbin directories should be deleted, but that caused the chaos that followed.

brfransen wrote:
Quote:
While I could eventually boot the computer, it was in a bad state. It couldn't prime its network interface, it had no reboot or shutdown commands, it seemed as if I was missing a large number of commands and files.
It probably was missing quite a few command because they had been moved and then orphaned by renaming /sbin and /usr/sbin. Do you know at what point the script failed out? That dialog about removing /sbin and /usr/sbin needs to be made more clear.


It failed several times through my attempts. Once I had switched to testing repos it made it past trying to install new java certificates, it succeeded in installing the new kernel, but I never made it past the glibc/filesystem-intermediate installation line until I renamed /sbin and borked everything.

I guess I should next try to figure out which files are not owned by LinHES repos in /bin, /sbin, and /usr/sbin, record them, verify I can download new versions of these compatible with the upgraded LinHES, and then uninstall them. Is there a way I can use pacman to verify that, say, xfsprogs will work with the glibc and kernel that will be present in the post-upgrade system?


Top
 Profile  
 
PostPosted: Sun Oct 19, 2014 12:50 pm 
Offline
Joined: Fri Jul 21, 2006 11:12 pm
Posts: 1194
Location: SC
neufeld wrote:
I wrote a posting at the time, describing what I had done: http://forum.linhes.org/viewtopic.php?f=22&t=23788.

Yes, that is quite non-LinHES R8 standard. I would expect all kinds of problems from many of the LinHES R8 tools because it is expecting a specific partition and db layout. But I still don't understand why you needed to go this route. A small boot drive with several large drives for media works very well.

Quote:
Is there some command I can use through pacman to retrieve the list of non-LinHES repos installed? I scanned the recovered /sbin and found the following packages owning files therein: btrfs-progs crda device-mapper dhcpcd dmraid dosfstools e2fsprogs fuse glibc hdparm iproute2 jfsutils keyutils kmod lvm2 mdadm net-tools nfs-utils nilfs-utils pam pcmciautils poweroff-scripts procps-ng reiserfsprogs runit runit-scripts shadow squashfs-tools systemd-tools sysvinit sysvinit-tools udisks util-linux v86d xfsprogs
I think pacman -Qm will list installed packages that are not in any repos currently listed in your pacman.conf.

Quote:
There were also poweroff.init and reboot.init that weren't owned by any packages, maybe debris left over from a previous install. I'm guessing xfsprogs is a non-LinHES repo?
The poweroff and reboot files are taken care of in the upgrade script as well as the poweroff-scripts package. xfsprogs is in both the release repo and testing repo.

Quote:
OK, perhaps the intermediate filesystem installation package should reword its error message there. The implication of the message was that the /sbin and /usr/sbin directories should be deleted, but that caused the chaos that followed.
I don't think that we can reword that error message since it comes from pacman, not the script. The error message in the script says to check the various directories for packages that need to be upgraded. The basic flow for upgrading is to update all packages except filesystem, glibc. The idea here is that all LinHES packages have been updated to install into /usr/bin so there should not be anything left in /sbin /usr/sbin or /bin. Then install filesystem-intermediate and glibc to get the filesystem ready. And then install the current filesystem package that will ultimately have /bin /sbin and /usr/sbin as links to /usr/bin. Lastly we reinstall the kernel to make sure the boot image is updated.

Quote:
It failed several times through my attempts. Once I had switched to testing repos it made it past trying to install new java certificates, it succeeded in installing the new kernel, but I never made it past the glibc/filesystem-intermediate installation line until I renamed /sbin and borked everything.
That is odd because at that point all the LH packages should have been install and not pointing to /sbin anymore.


Top
 Profile  
 
PostPosted: Sun Oct 19, 2014 5:50 pm 
Offline
Joined: Sun Apr 30, 2006 7:49 pm
Posts: 37
Location: Ottawa
brfransen wrote:
neufeld wrote:
I wrote a posting at the time, describing what I had done: http://forum.linhes.org/viewtopic.php?f=22&t=23788.

Yes, that is quite non-LinHES R8 standard. I would expect all kinds of problems from many of the LinHES R8 tools because it is expecting a specific partition and db layout. But I still don't understand why you needed to go this route. A small boot drive with several large drives for media works very well.


The problem I encountered was that I was unable to set up the fresh install while asking it to use my 3TB drives for storage. If there was a way to not put it on the SSD, I didn't find it. It might be because the CD couldn't read the (GPT) partition tables on the 3TB drives, so didn't offer the choice. I would have been happy with the option of no storage drives, since I could always fiddle fstab afterwards, but I was unable to figure out how to put the system on the SSD and the recordings on the 3TB drives using the installer on the CD. Naturally, I didn't want the installer to erase my 3TB drives, this was only a fresh install in the sense that it was a migration from Mythbuntu, I still had thousands of hours of recordings to keep, and a database to copy back. When the dust cleared, I had a small boot drive with several large drives for media, but I had to get there manually. I might, some day, re-partition the SSD to look like a LinHES standard setup, but for now it works for me.

brfransen wrote:
Quote:
Is there some command I can use through pacman to retrieve the list of non-LinHES repos installed? I scanned the recovered /sbin and found the following packages owning files therein: btrfs-progs crda device-mapper dhcpcd dmraid dosfstools e2fsprogs fuse glibc hdparm iproute2 jfsutils keyutils kmod lvm2 mdadm net-tools nfs-utils nilfs-utils pam pcmciautils poweroff-scripts procps-ng reiserfsprogs runit runit-scripts shadow squashfs-tools systemd-tools sysvinit sysvinit-tools udisks util-linux v86d xfsprogs
I think pacman -Qm will list installed packages that are not in any repos currently listed in your pacman.conf.


OK, that works, thank you. For completeness, though, I also went through it the long way, querying each of the files in /sbin and then looking up the packages in the linhes.org/repo directories in a web browser. I found that systemd-tools, sysvinit, and sysvinit-tools, while present in core, are not in core-testing.

In /usr/sbin, there were files from ca-certificates-java and tcp_wrappers that are not in the testing repos. I know the second is removed, not sure about the certificates one.

In /bin, there's also stuff from sysvinit-tools, which isn't in the testing repos.

Should I be changing my pacman configuration to use both testing and non-testing repos? There are, according to pacman, 15 repositories in my installation that are not found in -testing repos (but not all impinge upon /bin, /sbin, or /usr/sbin).

Thank you for your help through this.


Top
 Profile  
 
PostPosted: Sun Oct 19, 2014 6:26 pm 
Offline
Joined: Fri Jul 21, 2006 11:12 pm
Posts: 1194
Location: SC
Quote:
The problem I encountered was that I was unable to set up the fresh install while asking it to use my 3TB drives for storage. If there was a way to not put it on the SSD, I didn't find it. It might be because the CD couldn't read the (GPT) partition tables on the 3TB drives, so didn't offer the choice. I would have been happy with the option of no storage drives, since I could always fiddle fstab afterwards, but I was unable to figure out how to put the system on the SSD and the recordings on the 3TB drives using the installer on the CD. Naturally, I didn't want the installer to erase my 3TB drives, this was only a fresh install in the sense that it was a migration from Mythbuntu, I still had thousands of hours of recordings to keep, and a database to copy back. When the dust cleared, I had a small boot drive with several large drives for media, but I had to get there manually. I might, some day, re-partition the SSD to look like a LinHES standard setup, but for now it works for me.
With LinHES you add the additional drives after install using add_storage.py --no_destruction. Transitioning from Mythbuntu to LinHES R8.x is similar in process to LinHES R7 to R8 (http://linhes.org/projects/linhes/wiki/ ... -R8-system).

Quote:
OK, that works, thank you. For completeness, though, I also went through it the long way, querying each of the files in /sbin and then looking up the packages in the linhes.org/repo directories in a web browser. I found that systemd-tools, sysvinit, and sysvinit-tools, while present in core, are not in core-testing.

In /usr/sbin, there were files from ca-certificates-java and tcp_wrappers that are not in the testing repos. I know the second is removed, not sure about the certificates one.

In /bin, there's also stuff from sysvinit-tools, which isn't in the testing repos.
All of these you mentioned are not in -testing because they have been replace by packages with different names. The script will step you though each of these and you should answer yes to replace each of them.

Quote:
Should I be changing my pacman configuration to use both testing and non-testing repos?
No. Use only release (core and extra) or only testing (core-testing and extra-testing). Do not mix and match.

Quote:
There are, according to pacman, 15 repositories in my installation that are not found in -testing repos (but not all impinge upon /bin, /sbin, or /usr/sbin).
There are only 4 LinHES repos, core, extra, core-testing, and extra-testing. And as stated above only 2 of those should be active at a time. Adding in other repos is not supported and strongly discouraged.


Top
 Profile  
 
PostPosted: Sun Oct 19, 2014 7:48 pm 
Offline
Joined: Sun Apr 30, 2006 7:49 pm
Posts: 37
Location: Ottawa
brfransen wrote:
Quote:
The problem I encountered was that I was unable to set up the fresh install while asking it to use my 3TB drives for storage. If there was a way to not put it on the SSD, I didn't find it. It might be because the CD couldn't read the (GPT) partition tables on the 3TB drives, so didn't offer the choice. I would have been happy with the option of no storage drives, since I could always fiddle fstab afterwards, but I was unable to figure out how to put the system on the SSD and the recordings on the 3TB drives using the installer on the CD. Naturally, I didn't want the installer to erase my 3TB drives, this was only a fresh install in the sense that it was a migration from Mythbuntu, I still had thousands of hours of recordings to keep, and a database to copy back. When the dust cleared, I had a small boot drive with several large drives for media, but I had to get there manually. I might, some day, re-partition the SSD to look like a LinHES standard setup, but for now it works for me.
With LinHES you add the additional drives after install using add_storage.py --no_destruction.


Perhaps so, but at that point in the installation I could not figure out how to prevent the installer from setting aside a partition on the SSD for recordings. I wanted all that space for the root filesystem, and if there was a way to do that, I failed to locate it. The problem wasn't adding in the 3TB drives, it was in making full use of the SSD.

brfransen wrote:
Quote:
OK, that works, thank you. For completeness, though, I also went through it the long way, querying each of the files in /sbin and then looking up the packages in the linhes.org/repo directories in a web browser. I found that systemd-tools, sysvinit, and sysvinit-tools, while present in core, are not in core-testing.

In /usr/sbin, there were files from ca-certificates-java and tcp_wrappers that are not in the testing repos. I know the second is removed, not sure about the certificates one.

In /bin, there's also stuff from sysvinit-tools, which isn't in the testing repos.
All of these you mentioned are not in -testing because they have been replace by packages with different names. The script will step you though each of these and you should answer yes to replace each of them.


I'm quite certain I explicitly answered yes to each question, even in those cases where the default was no.

brfransen wrote:
Quote:
Should I be changing my pacman configuration to use both testing and non-testing repos?
No. Use only release (core and extra) or only testing (core-testing and extra-testing). Do not mix and match.


OK, that you for that clarification. I was configuring the system correctly.

brfransen wrote:
Quote:
There are, according to pacman, 15 repositories in my installation that are not found in -testing repos (but not all impinge upon /bin, /sbin, or /usr/sbin).
There are only 4 LinHES repos, core, extra, core-testing, and extra-testing. And as stated above only 2 of those should be active at a time. Adding in other repos is not supported and strongly discouraged.


Sorry, I'm not used to the language of package managers, and my statement was unclear. There are 15 packages in my installation that are not found in -testing LinHES repos. All of these are found in the non-testing LinHES repos. There are no packages installed that I did not get from LinHES sources. When I install software, such as ccextractor or afio, I always compile from sources and install only in /root/bin (this makes it easier for me to keep track of them during upgrades). My pacman.conf has only ever held the LinHES records for core and extra, and an unreachable "community" entry that I have never used, and have since commented out.

So, at this point, it seems to me from our discussions that my system was in the expected state for the update script, and that I used the script correctly, once I had the repositories moved to -testing. I will attempt this again, probably Wednesday morning, and see what happens. I will record a transcript of the session.


Top
 Profile  
 
PostPosted: Mon Oct 20, 2014 7:04 am 
Offline
Joined: Fri Jul 21, 2006 11:12 pm
Posts: 1194
Location: SC
The more I think about it the more it becomes clear that most of the problems you encountered are a result how your boot drive is partitioned.

Quote:
Perhaps so, but at that point in the installation I could not figure out how to prevent the installer from setting aside a partition on the SSD for recordings. I wanted all that space for the root file system, and if there was a way to do that, I failed to locate it. The problem wasn't adding in the 3TB drives, it was in making full use of the SSD.
There is not an option to prevent the installer from creating a partition for data on the boot drive. Above I said you don't have to use that partition for recordings but I should have been more clear. If you don't want recordings on the data partition of the boot drive you have to do that after install by removing the directories from Storage Groups. But you still need the data partition as LinHES expects it and uses it for pacman, backups and other things. You can remap /data/storage/disk0 and some things will work but without the data partition (sdX7) and the other partitions the installer created, upgrades from the install iso will fail. Upgrades using pacman (including this script) are extremely likely to fail as well.

Quote:
I'm quite certain I explicitly answered yes to each question, even in those cases where the default was no.
pacman is probably broken without the data partition. It does weird things without a cache.

Quote:
So, at this point, it seems to me from our discussions that my system was in the expected state for the update script, and that I used the script correctly, once I had the repositories moved to -testing.
Without the data partition on the boot drive the system is not in an expected state.


Top
 Profile  
 
PostPosted: Mon Oct 20, 2014 8:33 am 
Offline
Joined: Sun Apr 30, 2006 7:49 pm
Posts: 37
Location: Ottawa
brfransen wrote:
The more I think about it the more it becomes clear that most of the problems you encountered are a result how your boot drive is partitioned.


Recall, my directory layout is precisely the same, it's merely the hard drive partitioning itself that is different. I performed an install from the CD. Then I booted the CD to back it up (it's difficult to back up all files in a modern Linux system live because of overmounts and virtual mounts). I copied the entire tree to backup, repartitioned the drive, then copied the tree back. Without looking at the device number in stat(), you wouldn't know that anything changed. Well, not entirely true, you might notice that there's a bind mount from one part of the filesystem to itself, holding the backup files. So you have the same file showing up in two places in the tree, same device and inode, but the link counts on the backup files are all 1. The bind mount replicates /data/storage/disk0 in /data/storage/<LONG_NAME>, so the two subtrees under /data/storage look identical.

brfransen wrote:
Quote:
Perhaps so, but at that point in the installation I could not figure out how to prevent the installer from setting aside a partition on the SSD for recordings. I wanted all that space for the root file system, and if there was a way to do that, I failed to locate it. The problem wasn't adding in the 3TB drives, it was in making full use of the SSD.
There is not an option to prevent the installer from creating a partition for data on the boot drive. Above I said you don't have to use that partition for recordings but I should have been more clear. If you don't want recordings on the data partition of the boot drive you have to do that after install by removing the directories from Storage Groups.


As I was performing the install, I did not understand that partition to be something other than a recording storage partition, and as my SSD space was limited, I didn't want to leave an unused partition using much of the SSD. To make sure there were no surprises, then, I copied that tree into the root partition.

brfransen wrote:
But you still need the data partition as LinHES expects it and uses it for pacman, backups and other things. You can remap /data/storage/disk0 and some things will work but without the data partition (sdX7) and the other partitions the installer created, upgrades from the install iso will fail. Upgrades using pacman (including this script) are extremely likely to fail as well.


The backups are there, as are the pacman files. The pacman cache is present, it's occupying 200MB of disc space at the moment with its .tar.xz files.

brfransen wrote:
Quote:
I'm quite certain I explicitly answered yes to each question, even in those cases where the default was no.
pacman is probably broken without the data partition. It does weird things without a cache.


It's not difficult for me to re-partition the drive, I have good backups of all the drives. As I mentioned, the only reason I copied everything over to a single partition was that it was the end of a long install adventure, taking several hours, and I didn't want to add any complications to the procedure, or try to guess how much space I might use in /home over time so I could tune the partition sizes.

So, I should repartition before my next attempt. What partitions is LinHES expecting? I've got a 60GB SSD, currently partitioned into sda1 with 47GB for / (formatted ext3), and the remaining 11GB in sda2 for swap. What would the new partition layout be, and where are they mounted on the root tree? Currently, backups are about 600MB each, so the two weeks runs over 7GB, while /data/srv is about 0.5GB for the database and httpd files. Most of the length of the backups comes from the /home/mythtv/.mythtv/remotecache directory, which contains 4300 .png files.

Thank you again for your help with this.


Top
 Profile  
 
PostPosted: Mon Oct 20, 2014 9:06 am 
Offline
Joined: Fri Jul 21, 2006 11:12 pm
Posts: 1194
Location: SC
Quote:
So, I should repartition before my next attempt.
I recommend reinstalling with the install iso and letting the installer partition for you. I have installed LinHES on many many 60-80GB drives both spinning and SSD using the installer default sizes and have not had many issues with running out of space. The only time I remember having an issue was when the default root was set to 3GB but that is no longer the case. If you are concerned bump up OS and home a couple of GB.


Top
 Profile  
 
PostPosted: Mon Oct 20, 2014 9:19 am 
Offline
Joined: Sun Apr 30, 2006 7:49 pm
Posts: 37
Location: Ottawa
brfransen wrote:
Quote:
So, I should repartition before my next attempt.
I recommend reinstalling with the install iso and letting the installer partition for you. I have installed LinHES on many many 60-80GB drives both spinning and SSD using the installer default sizes and have not had many issues with running out of space. The only time I remember having an issue was when the default root was set to 3GB but that is no longer the case. If you are concerned bump up OS and home a couple of GB.


Well, I'm willing to boot up the installer far enough to see what it wants to lay out as a partition table, but my system is somewhat heavily customized, so a reinstall would require a lot of tweaking and editing of files to get back to where I want to be. It would be much simpler for me to copy files around and partition the drive by hand than to install from the 8.0 CD, upgrade to 8.1 again, and restore my customizations. Less intrusive on the users of the system.

I'll check the partitioning in a VM, see what it says. Thanks again.


Top
 Profile  
 
PostPosted: Mon Oct 20, 2014 9:35 am 
Offline
Joined: Fri Jul 21, 2006 11:12 pm
Posts: 1194
Location: SC
Quote:
It would be much simpler for me to copy files around and partition the drive by hand than to install from the 8.0 CD, upgrade to 8.1 again, and restore my customizations.
Starting from the 8.1.1 iso would cut out a step. http://www.linhes.org/downloads/R8/R8.1/


Top
 Profile  
 
PostPosted: Wed Oct 22, 2014 11:38 am 
Offline
Joined: Sun Apr 30, 2006 7:49 pm
Posts: 37
Location: Ottawa
I have made a second attempt to upgrade. The partition layout is as expected by LinHES, but the upgrade failed in the same way. I have logged the full text of the upgrade, which I invoked with /bin/sh -x to help show what commands were executing within the script.

When the script failed out, some changes had been made to the filesystem, I recovered from backup and my system is back to 8.1.

Changed/deleted files were listed by the backup recovery. They include:
In /bin: bash, bashbug, sh
In /etc: bash.bashrc, hosts.allow, hosts.deny
In /sbin: halt, halt-runit, halt.init, poweroff, poweroff.init, reboot, reboot-runit, reboot.init, regdbdump, resierfsck, reiserfstune, remove_service.sh, request-key, resize2fs, resize_reiserfs
In /usr/bin: sh, bashbug, bash, tdbbackup, tdbdump, tdbrestore, tdbtool,
Various headers in /usr/include
Changes in /usr/lib related to libtdb, libreadline, libhistory, libwrap
In /usr/bin: readprofile, resizepart, safe_finger, tcpd, tcpdchk, tcpdmatch, try-from
Changes in /usr/share/info related to bash, history, readline, rluserman

I've attached the log to this posting. Based on inspecting the filesystem after the update, bash-related files had disappeared from /bin and new ones appeared in /usr/bin. No symlink was produced from /bin to /usr/bin.

If you examine the transcript, you will see an execv failure (No such file or directory) while upgrading bash. There is also an earlier failure due to a conflict in ca-certificates-utils.


Top
 Profile  
 
PostPosted: Wed Oct 22, 2014 11:42 am 
Offline
Joined: Sun Apr 30, 2006 7:49 pm
Posts: 37
Location: Ottawa
neufeld wrote:
I've attached the log to this posting.


I can't see the attachment on the post. I've tried to attach it twice. If you can't see it, you can download it from http://www.cneufeld.ca/neufeld/TEMPORAR ... pgrade.txt. The file will be there for the next month.


Top
 Profile  
 
PostPosted: Wed Oct 22, 2014 1:17 pm 
Offline
Joined: Sun Apr 30, 2006 7:49 pm
Posts: 37
Location: Ottawa
So, here are my thoughts on the update failure. Sometime since the system was installed, a program created the file /etc/ssl/certs/java/cacerts. This file is on my filesystem, but is not owned by any package.

During the update, the command pacman -Syu --ignore filesystem,bash,glibc was executed. A conflict with that cacerts file caused the pacman command to exit with an error. At this point, the script should have warned and exited. Because the upgrades didn't go through, it had not cleared out the files from /bin, /sbin, and /usr/sbin, and the later package installs broke the system by messing up bash.

I will continue as follows. First, I'm setting -e in the script, so errors exit immediately. Then, I'm going to delete the cacerts file and try the update again.


Top
 Profile  
 

Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 67 posts ] 
Go to page 1, 2, 3, 4, 5  Next



All times are UTC - 6 hours




Who is online

Users browsing this forum: No registered users and 33 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group

Theme Created By ceyhansuyu