[opensuse] How to move /usr?
Well this is one of those times I wish software designers would have followed the KISS principal, and design the Linux system in a way that is easily understandable, sigh... A recent set of updates broke, on one of my OpenSuSE Leap 42.2 x64 servers because of lack of disk space in the partition for the root partition for /. My investigations showed that the contents of /usr was taking up the lion's share of space (8GB) of the partition on which / is mounted, which only had 10GB of total space allocated to it. In other words, the /usr directory was not mounted in a separate partition, it was just a sub directory. So I thought the solution would be to simply create a separate partition on another disk drive, copy everything from /usr to the new partition, edit fstab to mount the new partition as /usr, rename the old /usr directory to something different like /usr_tmp, reboot and then delete the old /usr_tmp directory if everything worked OK, to get more space for /. Easy as pie right? WRONG! Things went badly haywire when I tried to reboot! Apparently something within the boot loader or early in the boot process/system startup phase (which I admit I poorly understand) is referencing /usr and got very unhappy about my attempt to move /usr to it's own partition. So much for the KISS principal... I have managed to restore my OpenSuSE Leap 42.2 system back to a bootable state, by using an older version of OpenSuSE that I had left on my system for just such an emergency and using it to access and edit the fstab and renaming /usr_tmp back to /usr, in my OpenSuSE Leap 42.2 root partition, so as to return these back to the state they were originally in. So now I am stumped, I cannot figure out what/how I need to change in the boot loader/GRUB/system loader stuff to get it to cope with a new location for /usr... Can some kind guru lead me out of this mess and tell me how I am suppose to be able to move my /usr directory to it's own partition? I do realize that messing with /usr is dangerous because so much of the system is dependent on it which is why I thought hard about the strategy I took and am so surprised that it failed.. Thanks, Marc.. -- "The Truth is out there" - Spooky -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Marc Chamberlin wrote:
So now I am stumped, I cannot figure out what/how I need to change in the boot loader/GRUB/system loader stuff to get it to cope with a new location for /usr...
The only suse supported way to have a separate user is to boot from a ram-disk first, which mounts /usr, and then boots the real kernel. It's not really about grub, but about the fact that many of the utils needed to bring the system up to running order were removed from root and placed in /usr/bin and /usr/lib64, with broken symlinks left in /bin pointing to /usr/bin (which of course may not be mounted yet, as you have discovered). Even if you put the programs on root that you need to boot with, you'll find many of the system-startup libraries were also moved out of /lib64 into /usr/lib64 -- like libmount (hope you didn't need to mount any disks onto your root!)... So what I'm wondering is, was your boot setup by a suse installer? If so, aren't you booting first from some init-ramdisk? That should be ensuring your /usr/ is mounted before allowing the boot to continue (or does systemd do that these days?). I really don't know, as I also have a separate usr, boot from my hard disk, and don't use systemd. You might try making a new initrd -- maybe that would pick up the fact that you have a separate usr and do the mounting? Someone more w/more expertise in creating/booting from initrd might be able to chime in here. I feel your annoyance, BTW, as I also have a separate /usr (and /usr/share), and have had to go through hoops to keep that *AND* boot from my hard disk. I have a program that monitors the binaries and libraries on my root and /usr to keep root bootable. It's not exactly 'simple'...though I try to simplified my setup as much as possible. So .. maybe (guessing) remake initrd? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/07/2017 05:34 PM, L A Walsh wrote:
So .. maybe (guessing) remake initrd?
That's what I sent Marc in a pvt post. There is no prohibition against having any part of the filesystem on any mount point you like, but not having done it, my best guess was looking at a "Linux from scratch" howto about what hooks are necessary to embed the early fstab locations into initrd so the system can be brought up. It's not that different from booting from RAID, it's just one level deeper. The key, as you correctly point out, is much of the early boot relies on files in /usr[64], so the kernel needs to know where everything is at the time of the kernel load. If I find a good link, I'll pass it along, it's just not currently in the 1600 or so booksmarks :) -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-04-08 00:43, David C. Rankin wrote:
On 04/07/2017 05:34 PM, L A Walsh wrote:
So .. maybe (guessing) remake initrd?
That's what I sent Marc in a pvt post. There is no prohibition against having any part of the filesystem on any mount point you like, but not having done it, my best guess was looking at a "Linux from scratch" howto about what hooks are necessary to embed the early fstab locations into initrd so the system can be brought up. It's not that different from booting from RAID, it's just one level deeper.
The key, as you correctly point out, is much of the early boot relies on files in /usr[64], so the kernel needs to know where everything is at the time of the kernel load. If I find a good link, I'll pass it along, it's just not currently in the 1600 or so booksmarks :)
It does not need to know where they are. It needs to have access to it, meaning, inside the boot ramdisk. Just run mkinitrd, it is that simple. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 2017-04-08 01:03, David C. Rankin wrote:
On 04/07/2017 05:48 PM, Carlos E. R. wrote:
Just run mkinitrd, it is that simple.
It sure is good to have people on the list that have done it :)
Unless its broken, that's what I did the last time I tried. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
David C. Rankin wrote:
On 04/07/2017 05:34 PM, L A Walsh wrote:
The key, as you correctly point out, is much of the early boot relies on files in /usr[64], so the kernel needs to know where everything is at the time of the kernel load.
Not exactly... The kernel doesn't use /usr/lib64. It's modules are in /lib/modules. It's not the kernel that has a problem booting, it's the system-bring-up that follows -- thinks like "mount" which had its libs moved to /usr/lib64. I was so impressed with that the first time I booted and nothing would mount because the lib needed to mount things was not mounted yet. So **brilliant** ;^/! That's why in the old sysVinit, they had a 'boot.d' to bring up all the system HW, then it turned over to run-level 3 or 5 (rc3.d or rc5.d) to bring up the system-services (running in user-land). The system-services and the bringing up extra HW in boot.d are NOT really part of the kernel. The "boot.d" tasks did things like mounting hard disks and making sure network modules were loaded and config'ed. **Maybe**, some of the stuff in boot.d might require loading another kernel module -- but that comes from /lib/modules. I do the equivalent of a wicked-config of the linux kernel, so my needed HW drivers get built into a kernel. Opensuse could dynamically rebuild the kernel the same way they rebuild an initrd using a cherry-picking program like wicked. Then users could boot just using a kernel instead of an initrd. Unix OEM's used to provide such scripts back in 90's to customers who wanted less downtime and faster booting. They customers ran the scripts which built the kernel for their HW, and that was it (ramdisks weren't an option back then). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
BTW -- dunno if this is overkill, but if so, just ignore it, you won't be tested on it tomorrow! ;-) I haven't booted for over a month, so haven't run my checker. Just ran it and it found quite a few potential problems. It first checks the mount order to see what file systems are dependent on others. Then it looks for broken symlinks, outdated libraries, and missing libraries (for which it will automatically look in my current distro-rpm-file list) ... This was a run in 'user' mode (not as root, so it only reports, but won't fix). I'll need to re-run it as root missing files at the end usually belong to old binaries that didn't get removed for some reason or another. If I recognize that a file isn't needed for boot, I might just leave it off of 'root' and remove the symlink on root instead, like "dumpexfat" in /usr/sbin -- no reason to have that in /sbin, as it's not a boot-related file nor is it one used for emergency repairs ...
rootfs_dependency_checker.pl fixes_enabled = , >=5013 (Start prelink-info analysis to find broken deps (backgrounded)) Scan file-system mount order Dependencies (rootfs):/, Order 1:/Lmedia, /Media, /Share, /athenae, /backups, /boot, /home, /homes, /local, /misc, /smb, /tmp, /usr, /var, Order 2:/backups/Media, /usr/share, /var/cache/squid,
find all libs check for old versions in /usr check for out of date root libs for lib /lib64/libavcodec, ver 57.24.102 in usr > 54.59.100 in / Would copy /usr/lib64/libavcodec.so.57.24.102 to /lib64 for lib /lib64/libavformat, ver 57.25.100 in usr > 54.29.104 in / Would copy /usr/lib64/libavformat.so.57.25.100 to /lib64 find all bins check for faulty or unsafe symlinks unsafe link: /sbin/cryptsetup => /usr/sbin/cryptsetup Would copy /usr/sbin/cryptsetup to /sbin/cryptsetup unsafe link: /sbin/dumpexfat => /usr/sbin/dumpexfat Would copy /usr/sbin/dumpexfat to /sbin/dumpexfat unsafe link: /sbin/ethtool => //usr/sbin/ethtool Would copy //usr/sbin/ethtool to /sbin/ethtool unsafe link: /sbin/exfatfsck => /usr/sbin/exfatfsck Would copy /usr/sbin/exfatfsck to /sbin/exfatfsck unsafe link: /sbin/exfatlabel => /usr/sbin/exfatlabel Would copy /usr/sbin/exfatlabel to /sbin/exfatlabel unsafe link: /sbin/fsck.exfat => /usr/sbin/fsck.exfat Would copy /usr/sbin/fsck.exfat to /sbin/fsck.exfat unsafe link: /sbin/insserv => /usr/sbin/insserv Would copy /usr/sbin/insserv to /sbin/insserv unsafe link: /sbin/mkexfatfs => /usr/sbin/mkexfatfs Would copy /usr/sbin/mkexfatfs to /sbin/mkexfatfs unsafe link: /sbin/mkfs.exfat => /usr/sbin/mkfs.exfat Would copy /usr/sbin/mkfs.exfat to /sbin/mkfs.exfat unsafe link: /sbin/mkfs.ntfs => /usr/sbin/mkntfs Would copy /usr/sbin/mkntfs to /sbin/mkfs.ntfs unsafe link: /sbin/rcvboxautostart-service => /usr/lib/virtualbox/vboxautostart-service.sh Would copy /usr/lib/virtualbox/vboxautostart-service.sh to /sbin/rcvboxautostart-service unsafe link: /sbin/rcvboxballoonctrl-service => /usr/lib/virtualbox/vboxballoonctrl-service.sh Would copy /usr/lib/virtualbox/vboxballoonctrl-service.sh to /sbin/rcvboxballoonctrl-service unsafe link: /sbin/rcvboxdrv => /usr/lib/virtualbox/vboxdrv.sh Would copy /usr/lib/virtualbox/vboxdrv.sh to /sbin/rcvboxdrv unsafe link: /sbin/rcvboxweb-service => /usr/lib/virtualbox/vboxweb-service.sh Would copy /usr/lib/virtualbox/vboxweb-service.sh to /sbin/rcvboxweb-service Dangling symlink at /sbin/rrestore: would remove unsafe link: /sbin/udhcpc => /usr/sbin/udhcpc Would copy /usr/sbin/udhcpc to /sbin/udhcpc unsafe link: /sbin/vboxconfig => /usr/lib/virtualbox/postinst-common.sh Would copy /usr/lib/virtualbox/postinst-common.sh to /sbin/vboxconfig unsafe link: /sbin/vconfig => /usr/sbin/vconfig Would copy /usr/sbin/vconfig to /sbin/vconfig unsafe link: /bin/gunzip => /usr/bin/gunzip Would copy /usr/bin/gunzip to /bin/gunzip unsafe link: /bin/gzip => /usr/bin/gzip Would copy /usr/bin/gzip to /bin/gzip unsafe link: /bin/initviocons => /usr/bin/initviocons Would copy /usr/bin/initviocons to /bin/initviocons unsafe link: /bin/nisdomainname => /usr/bin/nisdomainname Would copy /usr/bin/nisdomainname to /bin/nisdomainname unsafe link: /bin/ypdomainname => /usr/bin/ypdomainname Would copy /usr/bin/ypdomainname to /bin/ypdomainname unsafe link: /bin/zcat => /usr/bin/zcat Would copy /usr/bin/zcat to /bin/zcat unsafe link: /lib/cpp => ../usr/bin/cpp Would copy ../usr/bin/cpp to /lib/cpp Dangling symlink at /lib/mkinitrd/setup/12-kdumpfs.sh: would remove Dangling symlink at /lib/mkinitrd/setup/91-kdump.sh: would remove Dangling symlink at /lib/mkinitrd/setup/95-mkdumprd.sh: would remove Dangling symlink at /lib/mkinitrd/boot/91-kdump.sh: would remove check obj prelink dependencies Read prelink info... would move /usr/lib64/libexpat.so.1.6.0 to /lib64/libexpat.so.1.6.0 warning: /sbin/squid: /usr/lib64/libexpat.so.1.6.0, would move /usr/lib64/libexpat.so.1.6.0 to /lib64/libexpat.so.1.6.0 warning: /sbin/squid.old: /usr/lib64/libexpat.so.1.6.0, check for obsolete root libs num_objs=629, numlibs=3301 *** missing file: libosipparser2.so.6 Used by: /sbin/siproxd Searching /home/rpms/13.2... ----- *** missing file: libexslt.so.0 Used by: /usr/bin/meinproc4 /usr/bin/meinproc4_simple /usr/bin/xml /usr/bin/xsltproc Searching /home/rpms/13.2... /home/rpms/13.2/distribution/13.2/repo/oss/x64+noarch/libxslt1-1.1.28-7.1.2.x86_64.rpm.txt:distribution/13.2/repo/oss/x64+noarch/libxslt1-1.1.28-7.1.2.x86_64.rpm: /usr/lib64/libexslt.so.0 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/04/17 06:34 PM, L A Walsh wrote:
It's not really about grub, but about the fact that many of the utils needed to bring the system up to running order were removed from root and placed in /usr/bin and /usr/lib64, with broken symlinks left in /bin pointing to /usr/bin (which of course may not be mounted yet, as you have discovered). Even if you put the programs on root that you need to boot with, you'll find many of the system-startup libraries were also moved out of /lib64 into /usr/lib64
I must admit I always wondered why it was that way round. So we have /bin/<file> =>symlink=> /usr/bin/<file> why was it not done the other way round /usr/bin/<file> =>symlink=> /bin/<file> The only thing I can think of is that it was done to save space on the root FS. Which is kinda dumb because then this in turn necessitated having /usr/{bin.lib,lib64} on the root FS as well by having all of /usr on the ROOT FS in order to boot, as Linda points out. There are times, well OK, most of the time, that Linda's setup seems wacky to me, but this seems a bit wacky as well. If its all going to be one FS why have symlinks? Symlinks are a cross-FS mechanism. The only way that this makes sense is if /usr is not part of the ROOTFS. Linda has a reasoned and reasonable cause for the weird way she has her system set up. This is weird for no reason that I can see. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/07/2017 06:56 PM, Anton Aylward wrote:
I must admit I always wondered why it was that way round. So we have /bin/<file> =>symlink=> /usr/bin/<file> why was it not done the other way round /usr/bin/<file> =>symlink=> /bin/<file>
The only thing I can think of is that it was done to save space on the root FS.
Well, I may be wrong, but I recall a /lib /usr/lib change that occurred around glibc-2.17-2 and changes to merge a number of files packaged in the various /bin or other locations to /usr/bin to basically consolidate much of the Linux install under /usr, instead of the smattering of files under /bin, /usr/bin, /lib, /usr/lib (a 4-to-1 consolidation). I know Arch took this path around 2013, I'm not sure whether there was any influence on the suse moves. Regardless of the actual reason, it made sense... -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-04-07 22:03, Marc Chamberlin wrote:
Well this is one of those times I wish software designers would have followed the KISS principal, and design the Linux system in a way that is easily understandable, sigh... A recent set of updates broke, on one of my OpenSuSE Leap 42.2 x64 servers because of lack of disk space in the partition for the root partition for /. My investigations showed that the contents of /usr was taking up the lion's share of space (8GB) of the partition on which / is mounted, which only had 10GB of total space allocated to it.
My /usr contains 32 GB of files.
In other words, the /usr directory was not mounted in a separate partition, it was just a sub directory. So I thought the solution would be to simply create a separate partition on another disk drive, copy everything from /usr to the new partition, edit fstab to mount the new partition as /usr, rename the old /usr directory to something different like /usr_tmp, reboot and then delete the old /usr_tmp directory if everything worked OK,
Delete after rebooting, not before.
to get more space for /. Easy as pie right? WRONG! Things went badly haywire when I tried to reboot! Apparently something within the boot loader or early in the boot process/system startup phase (which I admit I poorly understand) is referencing /usr and got very unhappy about my attempt to move /usr to it's own partition. So much for the KISS principal...
Once the change is activated (fstab), you need to run mkinitrd to change the boot ramdisk. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 07/04/17 06:45 PM, Carlos E. R. wrote:
My /usr contains 32 GB of files.
I'm not extreme: main:~ # du -sh /usr 6.7G /usr main:~ # du -shx /usr 3.8G /usr So what is the 3G "gap"? I have /usr/share a s sperate FS. Back when the Bell Unix Systems Group came up with idea that workstations could be 'lighter' in their disk requirements (and hence cheaper -- keep the beancounters happy) by having things like documentation, fonts and more on a shared repository on a server and mounted via NFS. Years previously SUN had done a lot of experimentation with 'dumb workstations' even to the point of having SWAP NFS mounted. That proved not to be a good idea :-) Sharing man pages, fonts and other things you'll find on /usr/share does make sense. You don't need them for boot. There are other thing under /usr that you don't need for boot (X11, games ...) but there's no point in being obsessional about the small stuff. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/07/2017 05:17 PM, Anton Aylward wrote:
So what is the 3G "gap"? I have /usr/share a s sperate FS.
Back when the Bell Unix Systems Group
Anton, its time to move on. ;-) How many machines do you have sharing that separate /usr/share? I'm betting is less than 5, and 3Gig times 5 machines is still within round-off error in disk drive size these days. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/04/17 08:39 PM, John Andersen wrote:
On 04/07/2017 05:17 PM, Anton Aylward wrote:
So what is the 3G "gap"? I have /usr/share a s sperate FS.
Back when the Bell Unix Systems Group
Anton, its time to move on. ;-)
How many machines do you have sharing that separate /usr/share?
I'm betting is less than 5, and 3Gig times 5 machines is still within round-off error in disk drive size these days.
You are missing the point I was making. Everything we have today is the result of decisions, decisions about architecture, made in the past. Even the concept of the way transient programs are handled by the UNIX model is in contrast to the ways that had preceded it, the 'transient program area" model that even persisted into the VAX VMS world. That we have end-user accounts under "/home? rather than "/usr" is another architectural artefact of the Unix Systems Group at Bell. These divisions are clean cut. The point I am making is that it means that they can be simple separate file systems. The point that Linda was making was that in order of the symlink from /bin to /usr/bin to be functional and usable at boot that have to be the same file system. As I pointed out, if the symlink ran in the other direction there wouldn't be that problem. If that was the case there would be no linkage between the root FS and the /usr FS, and /usr would not need to be incorporated into the initrd. What do you think Linda's special script is about? So the issue isn't that I no longer have an office where the 16 workstations share, among other things, the /usr/share on the file server. We have to live with historic decisions. We lived with the historic decision, also out of USG, to use the /etc/init.d scripts for a long while, which the BSD people chose not to. Now we are living with the architectural decision to use systemd, while other UNIX-like derivatives choose not to. The size of *MY* /usr is, as I said, less than 8G. The size of Carlos' is 32G. That's more than routing error! Why do you think that is? *I* think it is because he has made different architectural decisions from the one's I've made. My architectural decisions mean that I'm actually using near 3/44 of a Terabyte, and that's before you figure in developed applications under /srv -- all the "web" stuff. I I do bring up other machines, yes /usr/share is shared. But these days I don't use a laptop and don't use a central server, as does a friend who has 4 kids, each of who do have their own workstation running Linux (he's bring them up properly). No, my "other" machine is my Android phone. Understanding history, understanding how things came to be how they are, how the people at the time made the decisions they did in the context that existed at the time they made those decisions, is always pertinent. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-04-08 04:30, Anton Aylward wrote:
The size of *MY* /usr is, as I said, less than 8G. The size of Carlos' is 32G. That's more than routing error! Why do you think that is? *I* think it is because he has made different architectural decisions from the one's I've made. My architectural decisions mean that I'm actually using near 3/44 of a Terabyte, and that's before you figure in developed applications under /srv -- all the "web" stuff.
The reason I have such a big usr is independent of it being a different partition or not; it simply comes from me having installed a lot of packages, some of them big. There are some games, for instance; I had to move elsewhere these: /usr/share clipart -> /usr/gamedata/movidos_de_usr/share/clipart doc -> /usr/gamedata/movidos_de_usr/share/doc fillets-ng -> /usr/gamedata/movidos_de_usr/share/fillets-ng fpcsrc -> /usr/gamedata/movidos_de_usr/share/fpcsrc help -> /usr/gamedata/movidos_de_usr/share/help icons -> /usr/gamedata/movidos_de_usr/share/icons sounds -> /usr/gamedata/movidos_de_usr/share/sounds stellarium -> /usr/gamedata/movidos_de_usr/share/stellarium supertuxkart -> /usr/gamedata/movidos_de_usr/share/supertuxkart All those directories are very large. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 04/07/2017 03:45 PM, Carlos E. R. wrote:
On 2017-04-07 22:03, Marc Chamberlin wrote:
Well this is one of those times I wish software designers would have followed the KISS principal, and design the Linux system in a way that is easily understandable, sigh... A recent set of updates broke, on one of my OpenSuSE Leap 42.2 x64 servers because of lack of disk space in the partition for the root partition for /. My investigations showed that the contents of /usr was taking up the lion's share of space (8GB) of the partition on which / is mounted, which only had 10GB of total space allocated to it. My /usr contains 32 GB of files. Wow! I will make a big partition for future growth!
In other words, the /usr directory was not mounted in a separate partition, it was just a sub directory. So I thought the solution would be to simply create a separate partition on another disk drive, copy everything from /usr to the new partition, edit fstab to mount the new partition as /usr, rename the old /usr directory to something different like /usr_tmp, reboot and then delete the old /usr_tmp directory if everything worked OK, Delete after rebooting, not before. Yeah, I thought I said that, but guess I wasn't clear... I don't delete anything until I know it is safe to do so..
to get more space for /. Easy as pie right? WRONG! Things went badly haywire when I tried to reboot! Apparently something within the boot loader or early in the boot process/system startup phase (which I admit I poorly understand) is referencing /usr and got very unhappy about my attempt to move /usr to it's own partition. So much for the KISS principal... Once the change is activated (fstab), you need to run mkinitrd to change the boot ramdisk.
Thanks Carlos for your guidance, just to be clear, (the devil is in the details as always...) the steps I think you are saying that I need to follow is - ? 1. Use Yast2 Partitioner to create a new partition and mount it as /usr_new 2. su root 3. cd /usr 4. cp -a * /usr_new 5. Edit fstab so as to change the mount my new partition from /usr_new to /usr now I am a bit unsure, I think I want to rename /usr to something else so that later I can delete it and recover the space, but the moment I do, I break a whole lot of the system! 6. mv /usr /usr_tmp You say I need to activate the new fstab but at this point I would not be able to execute a mount command! Or do much else for that matter. So should I perhaps just mount the new partition instead, on top of /usr and not rename it? What happens to the contents of my old /usr if I now do a mount -a and how would I eventually recover the space it occupies? 6. mount /usr Assuming I can get past step 6 somehow, which seems like a Catch22, and got /usr back, I think you are saying my next steps are - 7. mkinitrd 8. reboot 9. Pray all goes well.... 10. If all goes well and system boots up successfully and I have /usr_tmp then 11. su root 12. rm -rf /usr_tmp Easy Piezzy eh? ;-) Well only if I can grok what step 6 should be... Marc... -- "The Truth is out there" - Spooky -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-04-08 02:43, Marc Chamberlin wrote:
On 04/07/2017 03:45 PM, Carlos E. R. wrote:
On 2017-04-07 22:03, Marc Chamberlin wrote:
Well this is one of those times I wish software designers would have followed the KISS principal, and design the Linux system in a way that is easily understandable, sigh... A recent set of updates broke, on one of my OpenSuSE Leap 42.2 x64 servers because of lack of disk space in the partition for the root partition for /. My investigations showed that the contents of /usr was taking up the lion's share of space (8GB) of the partition on which / is mounted, which only had 10GB of total space allocated to it. My /usr contains 32 GB of files. Wow! I will make a big partition for future growth!
Mine is a bit extreme :-) And it is not in a single partition, but three. One of them YaST said was too small today during an update.
Once the change is activated (fstab), you need to run mkinitrd to change the boot ramdisk.
Thanks Carlos for your guidance, just to be clear, (the devil is in the details as always...) the steps I think you are saying that I need to follow is - ?
1. Use Yast2 Partitioner to create a new partition and mount it as /usr_new
2. su root
3. cd /usr
4. cp -a * /usr_new
This step I do with "mc". I'm lazy to remember all the proper switches. You have to ensure that hard/soft links stay. Also that sparse files remain sparse. The proper tool is rsync, but having a good look at the options. I use: OPTIONS="--archive --acls --xattrs --hard-links --stats --human-readable "
5. Edit fstab so as to change the mount my new partition from /usr_new to /usr
now I am a bit unsure, I think I want to rename /usr to something else so that later I can delete it and recover the space, but the moment I do, I break a whole lot of the system!
6. mv /usr /usr_tmp
You say I need to activate the new fstab but at this point I would not be able to execute a mount command!
Good point. I forgot that. You can try see what happens, perhaps. Try call "/usr_tmp/bin/mount", perhaps it works.
Or do much else for that matter. So should I perhaps just mount the new partition instead, on top of /usr and not rename it? What happens to the contents of my old /usr if I now do a mount -a and how would I eventually recover the space it occupies?
6. mount /usr
Yes, you can certainly mount usr partition on top of /usr, yes. Nothing happens to it, simply it becomes not accessible.
Assuming I can get past step 6 somehow, which seems like a Catch22, and got /usr back, I think you are saying my next steps are -
7. mkinitrd
If new partition is mounted on top of /usr, we need an extra step here. Halt computer, boot rescue system, rename /usr to /old_usr, create empty /usr.
8. reboot
9. Pray all goes well....
10. If all goes well and system boots up successfully and I have /usr_tmp then
11. su root
12. rm -rf /usr_tmp
Easy Piezzy eh? ;-) Well only if I can grok what step 6 should be... Marc...
Last time I did this was over a year or two ago. Another possibility of doing it all, is booting a rescue system, doing the partition-copy-move-fstab-edit thing, then chroot it all to run mkinitrd. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 04/07/2017 06:18 PM, Carlos E. R. wrote:
On 2017-04-08 02:43, Marc Chamberlin wrote:
On 04/07/2017 03:45 PM, Carlos E. R. wrote:
On 2017-04-07 22:03, Marc Chamberlin wrote:
Well this is one of those times I wish software designers would have followed the KISS principal, and design the Linux system in a way that is easily understandable, sigh... A recent set of updates broke, on one of my OpenSuSE Leap 42.2 x64 servers because of lack of disk space in the partition for the root partition for /. My investigations showed that the contents of /usr was taking up the lion's share of space (8GB) of the partition on which / is mounted, which only had 10GB of total space allocated to it. My /usr contains 32 GB of files. Wow! I will make a big partition for future growth! Mine is a bit extreme :-)
And it is not in a single partition, but three. One of them YaST said was too small today during an update.
Once the change is activated (fstab), you need to run mkinitrd to change the boot ramdisk.
Thanks Carlos for your guidance, just to be clear, (the devil is in the details as always...) the steps I think you are saying that I need to follow is - ?
1. Use Yast2 Partitioner to create a new partition and mount it as /usr_new
2. su root
3. cd /usr
4. cp -a * /usr_new This step I do with "mc". I'm lazy to remember all the proper switches. You have to ensure that hard/soft links stay. Also that sparse files remain sparse. The proper tool is rsync, but having a good look at the options. I use:
OPTIONS="--archive --acls --xattrs --hard-links --stats --human-readable "
5. Edit fstab so as to change the mount my new partition from /usr_new to /usr
now I am a bit unsure, I think I want to rename /usr to something else so that later I can delete it and recover the space, but the moment I do, I break a whole lot of the system!
6. mv /usr /usr_tmp
You say I need to activate the new fstab but at this point I would not be able to execute a mount command! Good point. I forgot that. You can try see what happens, perhaps. Try call "/usr_tmp/bin/mount", perhaps it works.
Or do much else for that matter. So should I perhaps just mount the new partition instead, on top of /usr and not rename it? What happens to the contents of my old /usr if I now do a mount -a and how would I eventually recover the space it occupies?
6. mount /usr Yes, you can certainly mount usr partition on top of /usr, yes. Nothing happens to it, simply it becomes not accessible.
Assuming I can get past step 6 somehow, which seems like a Catch22, and got /usr back, I think you are saying my next steps are -
7. mkinitrd If new partition is mounted on top of /usr, we need an extra step here. Halt computer, boot rescue system, rename /usr to /old_usr, create empty /usr.
8. reboot
9. Pray all goes well....
10. If all goes well and system boots up successfully and I have /usr_tmp then
11. su root
12. rm -rf /usr_tmp
Easy Piezzy eh? ;-) Well only if I can grok what step 6 should be... Marc... Last time I did this was over a year or two ago.
Another possibility of doing it all, is booting a rescue system, doing the partition-copy-move-fstab-edit thing, then chroot it all to run mkinitrd.
Thanks so much everyone for all the help and commentary! I managed to move /usr to a new partition following Carlos's instructions and for the most part all seems not bad although there is one anomaly that is occurring in the new version of my system. Launching Konsole from the KDE application menu launcher is taking an extraordinarily long time (3 to 5 minutes) before the Konsole window appears. But if I launch it from a command line, the window appears almost immediately. So far this is the only oddity I have noticed and launching any other KDE application seems to work just fine with windows appearing quickly. Only Konsole and the Terminal Super User Mode, when launched from the KDE application menu takes so long to respond. Weird! Anton - I really appreciated all your deep IN-Depth knowledge about /usr and I will incorporate some of your suggestions in breaking up /usr into separate partitions shortly. In particular /usr/share sounds like a good idea and it is almost 3GB. /usr/lib64 is the other big hog and seems like a good candidate to move to a separate partition. I am not a gamer and could care less about what is in there, I use my systems either for running servers or developing software for where I work. I only wish that the deep knowledge that you have about, the Linux filesystem, was better captured somewhere and easily discoverable by us poor mere users. But that is a whole nother subject that you don't want to get me started on! Perhaps when I retire I will work on creating a more user friendly OS where such knowledge can be easily shared and made discoverable/understandable by mere mortals! I do have a few ideas on how to do that, just need a lot of time and resources! LOL As for file system type of my new /usr partition, I chose to stay with Ext4. I got badly bit a while ago with using XFS and BtrFS, trying to figure out how to recover from file corruption issues with partitions using those file system types. I figure I will wait until they are more mature and perhaps integrated into fsck better. ReiserFS use to be offered in the YaST2 Partitioner but it no longer is, so I drew the conclusion (perhaps falsely) that OpenSuSE must not be supporting it for some reason, and I want to stick within the framework of tools that this distro wants to use, as best as I can.. David, L A Walsh, John - I will let you and others hash out the details of how the file system should be modeled, structured, and implemented. That is way beyond my abilities to grok at the moment! But I appreciate hearing your discussions and will follow along from the sideline as best as I can.. Marc... -- "The Truth is out there" - Spooky -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-04-09 01:34, Marc Chamberlin wrote:
On 04/07/2017 06:18 PM, Carlos E. R. wrote:
On 2017-04-08 02:43, Marc Chamberlin wrote:
On 04/07/2017 03:45 PM, Carlos E. R. wrote:
On 2017-04-07 22:03, Marc Chamberlin wrote:
Thanks so much everyone for all the help and commentary! I managed to move /usr to a new partition following Carlos's instructions and for the most part all seems not bad although there is one anomaly that is occurring in the new version of my system. Launching Konsole from the KDE application menu launcher is taking an extraordinarily long time (3 to 5 minutes) before the Konsole window appears. But if I launch it from a command line, the window appears almost immediately. So far this is the only oddity I have noticed and launching any other KDE application seems to work just fine with windows appearing quickly. Only Konsole and the Terminal Super User Mode, when launched from the KDE application menu takes so long to respond. Weird!
Weird. Maybe a broken link :-?
Anton - I really appreciated all your deep IN-Depth knowledge about /usr and I will incorporate some of your suggestions in breaking up /usr into separate partitions shortly. In particular /usr/share sounds like a good idea and it is almost 3GB.
You don't need to fragment it further, there is seldom a good reason for that.
/usr/lib64 is the other big hog and seems
That's a directory that is needed early, I would not touch it. Moving /usr because you need more space on "/" is a fair reason, but fragmenting it further is not necesary, unless your /usr also fills up. Separating /usr/local may have a different reason, namely protecting it from being formatted on upgrades. Another reason is splitting filesystems to different disks because it may speed up access. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 09/04/17 08:09 AM, Carlos E. R. wrote:
Separating /usr/local may have a different reason, namely protecting it from being formatted on upgrades.
There are a few other things under /usr that you may want to protect against being overwritten by upgrades. It's al YMMV For some idiot reason the default is to put the MySQL database there! While on a single-user system it makes sense to install additional custom fonts under ~/local, on a shared system the decision might be to install them under /us/share/fonts. It is worth looking to see it there is anything else you want to preserve though upgrades. Games perhaps
Another reason is splitting filesystems to different disks because it may speed up access.
I don't know about access in general, but FSCK is an O-Squared and it can be parallelized. I should also mention that huge swaths of /usr can be made read only, that is mounted as a read-only FS, which makes life a little easier on the kernel. I've done that with a NFS mounted /usr/share. It had symlinks back to the local machine to take care of many items. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-04-09 15:07, Anton Aylward wrote:
On 09/04/17 08:09 AM, Carlos E. R. wrote:
Separating /usr/local may have a different reason, namely protecting it from being formatted on upgrades.
There are a few other things under /usr that you may want to protect against being overwritten by upgrades. It's al YMMV
For some idiot reason the default is to put the MySQL database there!
Not that I know. It goes under /var. To /var/lib/mysql, that's where i have it and I didn't place it there.
Another reason is splitting filesystems to different disks because it may speed up access.
I don't know about access in general, but FSCK is an O-Squared and it can be parallelized.
Not fsck, but plain file access. It was mentioned in the old SUSE paper admin book. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On Sunday, 9 April 2017 22:37:18 ACST Anton Aylward wrote:
[...]
I should also mention that huge swaths of /usr can be made read only, that is mounted as a read-only FS, which makes life a little easier on the kernel. I've done that with a NFS mounted /usr/share. It had symlinks back to the local machine to take care of many items.
Yes - just don't forget to remount it RO before attempting to update the system... :) -- ============================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au ============================================================== -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/04/17 08:43 PM, Marc Chamberlin wrote:
On 04/07/2017 03:45 PM, Carlos E. R. wrote:
My /usr contains 32 GB of files. Wow! I will make a big partition for future growth!
I suggest that you think about what is actually under /usr/ I have # ls /usr X11R6 bin games include lib lib64 local sbin share src tmp x86_64-suse-linux Where do you think growth will occur? * /usr/local is a separate FS. I want my locally developed items to be able to survive a upgrade even if the rest of /usr gets formatted * /usr/share is a seperate FS as I've discussed previously It may grow as I add fonts etc * /usr/tmp is ... well it's another tmp FS. I have it as a symlink to /var/tmp but that's a decision I made. You might have it as another mounted FS. * /usr/src is where (some) development gets done. Sources there may also draw on /usr/include. I want those to survive a new installation for are also separate file systems. How large each of these file systems are will depend on many things. If you decide never to work on system packages perhaps /usr/src and /ur/include will never be populated so aren't separate file systems. Perhaps. Perhaps you are a game player and some games come with large databases, so that warrants /usr/games being a separate FS. Perhaps. As it stands, the solution to your overpopulated /usr might not be to move *all* of /usr to a larger partition but to create a partition for, say, /usr/share and move that off. Actually that's what I did many years ago. And it was easy for me to do as I had already adopted LVM.
Thanks Carlos for your guidance, just to be clear, (the devil is in the details as always...) the steps I think you are saying that I need to follow is - ?
1. Use Yast2 Partitioner to create a new partition and mount it as /usr_new
Well, no. I'd mount a RESCUE system and do it all from there.
2. su root
3. cd /usr
4. cp -a * /usr_new
Err, no, I would use RSYNC to d any such copy.
5. Edit fstab so as to change the mount my new partition from /usr_new to /usr
now I am a bit unsure, I think I want to rename /usr to something else so that later I can delete it and recover the space, but the moment I do, I break a whole lot of the system!
As I said, moving off /usr/share is less dramatic. if you get it wrong what have you lost? Or you might try it in a more granular way, move off /usr/share/man. # du -sh /usr/share/{doc,man,fonts} 483M /usr/share/doc 47M /usr/share/man 138M /usr/share/fonts John Anderson could call this a rounding error, and sicne I use LVM and can easily grow or shrink a FS and partition I can't argue. I could easily rsync the above and more off onto one of the 1G USB sticks that are free give-away at conferences (such as SUSE DAYS marketing presentations each year) and do some cleanup, the put them back, possibly with symlinks. For the most part I use ReiserFS rather than ext4. Ext4 is a wonderful FS but has one strange design limit. In a world where every other B-tree based FS has moved away from the old V7 FS model of having a certain fixed number of inodes and their space set at mkfs-time, ext4 has stuck with it. So it can mean that you have run out of data space but there is still a lot of free space on the disk psrtition, but it is preallocated for inodes. XFS, ReiserFS, BtrFS, the other B-tree file systems that are popular, do not have this limitation. Many people see this as an irrelevancy. I see it as being stuck with a 1960s view of resource allocation.
7. mkinitrd
8. reboot
Well, the nice thing about using LVM and growing a file system such as reiserFS using the LVM tools is that you can do it on a live system. No need to do a new mkinitrd, no need to reboot. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/04/17 11:04 PM, Anton Aylward wrote:
* /usr/share is a seperate FS as I've discussed previously It may grow as I add fonts etc
Oh, I forgot to mention, there are tools that can reduce the size of the file system by deleting or otherwise consolidating stuff, in particular stiff that you are never going to use. One of them, 'bleachbit', has the ability to remove all the language translation packages that you are never going to use. if you are the sole user of a machine then you can strip it down to the languages that you do use. What it does not do is go though the dot-desktop files and clean out their innards :-( There are also programs that 'de-duplicate'. Under /usr/share/doc are many copies of the GPL, all identical. Although there are other tools for this, my favourite is the Perl script 'finddups' because it ONLY finds them, it doesn't change anything, it leaves that up to me. The mechanism within 'bleachbit' leaves me uncertain what is actually going on. There is also the compiled file 'fdupes' which has a number of options and is quite fast. I've also just noticed that the package 'kernel-firmware' has not only many copies of the GPL in /usr/share but also many kernel modules that are for hardware I don't have. Pruning that is not something I'd willingly undertake though. YMMV. Of course if you want a 'portable' system, that is, a hard drive you are going to move between different machines, different hardware, different CPUs and CPU types, different device arrays, then such pruning is not something that is going to be useful. Oh, and its something that Microsoft simply will not allow. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-04-08 14:27, Anton Aylward wrote:
On 07/04/17 11:04 PM, Anton Aylward wrote:
* /usr/share is a seperate FS as I've discussed previously It may grow as I add fonts etc
Oh, I forgot to mention, there are tools that can reduce the size of the file system by deleting or otherwise consolidating stuff, in particular stiff that you are never going to use.
The problem with this approach is that when you attempt to update the system you may get again a full system, perhaps a failed update. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 08/04/17 02:53 PM, Carlos E. R. wrote:
On 2017-04-08 14:27, Anton Aylward wrote:
On 07/04/17 11:04 PM, Anton Aylward wrote:
* /usr/share is a seperate FS as I've discussed previously It may grow as I add fonts etc
Oh, I forgot to mention, there are tools that can reduce the size of the file system by deleting or otherwise consolidating stuff, in particular stiff that you are never going to use.
The problem with this approach is that when you attempt to update the system you may get again a full system, perhaps a failed update.
Yes, you are right in that an update puts back many of those files, especially the language ones. You have to keep running 'bleachbit'. *sigh* I've never had an update or install fail because of this. Bitch-and-complain, sometimes, to the log file, yes; fail? no, never. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-04-08 21:22, Anton Aylward wrote:
On 08/04/17 02:53 PM, Carlos E. R. wrote:
On 2017-04-08 14:27, Anton Aylward wrote:
On 07/04/17 11:04 PM, Anton Aylward wrote:
* /usr/share is a seperate FS as I've discussed previously It may grow as I add fonts etc
Oh, I forgot to mention, there are tools that can reduce the size of the file system by deleting or otherwise consolidating stuff, in particular stiff that you are never going to use.
The problem with this approach is that when you attempt to update the system you may get again a full system, perhaps a failed update.
Yes, you are right in that an update puts back many of those files, especially the language ones. You have to keep running 'bleachbit'. *sigh*
I've never had an update or install fail because of this. Bitch-and-complain, sometimes, to the log file, yes; fail? no, never.
I did, two days ago. Error, package not installed, package suchname needs 32 MB on /usr. Ignore, retry, abort. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 08/04/17 03:42 PM, Carlos E. R. wrote:
I've never had an update or install fail because of this. Bitch-and-complain, sometimes, to the log file, yes; fail? no, never.
I did, two days ago. Error, package not installed, package suchname needs 32 MB on /usr. Ignore, retry, abort.
That has nothing to do with removing language files or de-duplication. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-04-09 02:57, Anton Aylward wrote:
On 08/04/17 03:42 PM, Carlos E. R. wrote:
I've never had an update or install fail because of this. Bitch-and-complain, sometimes, to the log file, yes; fail? no, never.
I did, two days ago. Error, package not installed, package suchname needs 32 MB on /usr. Ignore, retry, abort.
That has nothing to do with removing language files or de-duplication.
It does. If you use those tricks to make free space on the disk, that space is instantly filled up again on the next upgrade. Disk full again, failed upgrade. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 09/04/17 08:11 AM, Carlos E. R. wrote:
That has nothing to do with removing language files or de-duplication.
It does. If you use those tricks to make free space on the disk, that space is instantly filled up again on the next upgrade. Disk full again, failed upgrade.
If you are that critical for space then 'tricks' are not what what you need. In reality, unless you set things otherwise, 'zypper up' or similar will download all the RPMs, check for conflicts ... O wait! if you're that critical for space that is where the !FAIL! happens. However if, like me, you change the settings so that so that it downloads one-and-only-one RPM, install that, deletes the RPM once the install has completed, then goes on to the next .. Perhaps, if you're that critical for space, those packages that _do_ have the extra language packs that 'bleachbit' cleaned out previously will put them back, and you'll need to run 'bleachbit' again. BUT not all packages are like that. And, more to the point here, you don't that the hit of having all the RPMs loaded at once. So if you don't have updates with language packs, you might get an update done without the !FAIL! of which you speak. But even if you do have some RPMs with language packs, this way it may not be enough to overflow you're poorly configured system. Let's face it, disk space is cheap. My 'out of the Anxiety Closet' Dell Optiplex only ha slots for 2 hard drives (unless I resort to external USB) but with LVM it was easy enough to 'upgrade' my 1T drive to the 3T drive my migrating LVs -- even when the system was live and I was doing other work. The 3T drive was under US$100 on special at a local store :-) (I think they were flushing their stocks of rotating rust to make room for SSD.) (I went back for a second.) (I went back for a 3rd to put in a USB container for 'external' but they had sold out :-( ) A more modern motherboard will undoubtedly have more <strike>IDE</strike> SATA connections or even a SCSI chain header. Failing that, there is, as I keep saying, the ability to migrate the /usr/share (which is where those pesky language packages reside) off to a NFS connected server. I really don't see why you people are inventing problems where there is no need for them, where Linux offers so many alternatives and potential solutions to all the fake problems. https://www.youtube.com/watch?v=MAfCQ-t7xY0 -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-04-09 14:54, Anton Aylward wrote:
On 09/04/17 08:11 AM, Carlos E. R. wrote:
That has nothing to do with removing language files or de-duplication.
It does. If you use those tricks to make free space on the disk, that space is instantly filled up again on the next upgrade. Disk full again, failed upgrade.
If you are that critical for space then 'tricks' are not what what you need.
We are talking of that precisely. The OP has that precise problem. And I do.
Perhaps, if you're that critical for space, those packages that _do_ have the extra language packs that 'bleachbit' cleaned out previously will put them back, and you'll need to run 'bleachbit' again.
You can't. The upgrade fails and aborts. That's the point. The solution is more disk space, period. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
participants (7)
-
Anton Aylward -
Carlos E. R. -
David C. Rankin -
John Andersen -
L A Walsh -
Marc Chamberlin -
Rodney Baker