Re: Upgrade issue with Debian 9 -> 10
On 7/5/22 04:36, Miroslav Skoric wrote: On 7/3/22 7:51 PM, David Christensen wrote: On 7/3/22 02:31, Miroslav Skoric wrote: Yesterday I attempted to upgrade Compaq Presario CQ56 laptop to buster. I followed instructions in 'Chapter 4. Upgrades from Debian 9 (stretch)', so all went well with a minimal upgrade (apt-get upgrade). When it finished, I went to the main part of the upgrade (apt full-upgrade). It ran well until some 40-45% and then started complaining about lack of disk space. The KISS approach is to check in your system configuration files to a version control system, back up your data, take an image of the OS drive, remove the OS drive, insert a blank OS drive, do a fresh install, check out the old system configuration files to a side directory, configure the new OS instance, restore your data, and validate everything. Seems as a drastic solution :-) Will try to cure this one, and if things go wrong I can always do a fresh install. For me, Debian is tool that I *use* for both personal and professional work. I have no need or desire to learn the internals of Debian beyond how to configure and operate the services and applications I need. Other people depend upon myself and my systems. Unplanned downtime and data loss are unacceptable. My goal is professional system administration of all of the networks and systems I maintain. When I broke my systems years ago (Linux and otherwise), I used to try and "find the needle in the haystack". This took an unpredictable amount of time with unpredictable results. I had little confidence in the process or in the outcome. So, I choose to invest my learning in configuration management, disaster preparedness, and development/ operations. I bought books, courses, additional computers, spare parts, hardware and software tools, etc.. I wrote shell and Perl scripts to facilitate system administration chores, including those I outlined above. This has proven to be a much better approach. The last time I broke my daily driver, it was fully operational again within a few hours. Put another way, my computers were once pets; now they are cattle: https://html.duckduckgo.com/html?q=cattle%20vs.%20pets David p.s. Do a fresh install of Debian 11.
Re: Upgrade issue with Debian 9 -> 10
El mar, 5 jul 2022 a las 8:39, Miroslav Skoric () escribió: > > On 7/5/22 9:37 AM, Tom Dial wrote: > > > > Post the output from > > > > # fdisk -l (or $ sudo fdisk -l) > > # vgdisplay -v (or $ sudo vgdisplay -v) > > > > Here it is: > > # fdisk -l > Disk /dev/sda: 298.1 GiB, 320072933376 bytes, 625142448 sectors > Disk model: Hitachi HTS54323 > Units: sectors of 1 * 512 = 512 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 512 bytes > Disklabel type: dos > Disk identifier: 0x0005de22 > > Device Boot Start End Sectors Size Id Type > /dev/sda1 * 2048499711497664 243M 83 Linux > /dev/sda2 501758 625141759 624640002 297.9G 5 Extended > /dev/sda5 501760 625141759 62464 297.9G 83 Linux > > > > > Disk /dev/mapper/sda5_crypt: 297.9 GiB, 319814627328 bytes, 624637944 > sectors > Units: sectors of 1 * 512 = 512 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 512 bytes > > > Disk /dev/mapper/localhost-root: 5.3 GiB, 5716836352 bytes, 11165696 sectors > Units: sectors of 1 * 512 = 512 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 512 bytes > > > Disk /dev/mapper/localhost-usr: 13.4 GiB, 14365491200 bytes, 28057600 > sectors > Units: sectors of 1 * 512 = 512 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 512 bytes > > > Disk /dev/mapper/localhost-var: 2.8 GiB, 2998927360 bytes, 5857280 sectors > Units: sectors of 1 * 512 = 512 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 512 bytes > > > Disk /dev/mapper/localhost-swap_1: 5.7 GiB, 6090129408 bytes, 11894784 > sectors > Units: sectors of 1 * 512 = 512 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 512 bytes > > > Disk /dev/mapper/localhost-tmp: 2.4 GiB, 2545942528 bytes, 4972544 sectors > Units: sectors of 1 * 512 = 512 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 512 bytes > > > Disk /dev/mapper/localhost-home: 261 GiB, 280246616064 bytes, 547356672 > sectors > Units: sectors of 1 * 512 = 512 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 512 bytes > > > > > # vgdisplay -v >--- Volume group --- >VG Name localhost >System ID >Formatlvm2 >Metadata Areas1 >Metadata Sequence No 17 >VG Access read/write >VG Status resizable >MAX LV0 >Cur LV6 >Open LV 6 >Max PV0 >Cur PV1 >Act PV1 >VG Size <297.85 GiB >PE Size 4.00 MiB >Total PE 76249 >Alloc PE / Size 74378 / <290.54 GiB >Free PE / Size 1871 / <7.31 GiB >VG UUID fbCaw1-u3SN-2HCy-w6y8-v0nK-QsFE-FETNZM > >--- Logical volume --- >LV Path/dev/localhost/root >LV Nameroot >VG Namelocalhost >LV UUIDz3MLJc-UsXY-hxOE-xSk2-ipAl-NUny-PDpXv6 >LV Write Accessread/write >LV Creation host, time , >LV Status available ># open 1 >LV Size5.32 GiB >Current LE 1363 >Segments 2 >Allocation inherit >Read ahead sectors auto >- currently set to 256 >Block device 254:1 > >--- Logical volume --- >LV Path/dev/localhost/usr >LV Nameusr >VG Namelocalhost >LV UUIDUbFZNN-Y0oA-tEAb-5a8g-z65r-Ekqv-agbmrc >LV Write Accessread/write >LV Creation host, time , >LV Status available ># open 1 >LV Size<13.38 GiB >Current LE 3425 >Segments 2 >Allocation inherit >Read ahead sectors auto >- currently set to 256 >Block device 254:2 > >--- Logical volume --- >LV Path/dev/localhost/var >LV Namevar >VG Namelocalhost >LV UUIDyljPiS-bfh3-w0vA-fAg9-anAE-OaiF-XgvyoY >LV Write Accessread/write >LV Creation host, time , >LV Status available ># open 1 >LV Size2.79 GiB >Current LE 715 >Segments 1 >Allocation inherit >Read ahead sectors auto >- currently set to 256 >Block device 254:3 > >--- Logical volume --- >LV Path/dev/localhost/swap_1 >LV Name
Re: Upgrade issue with Debian 9 -> 10
On 7/5/22 9:37 AM, Tom Dial wrote: Post the output from # fdisk -l (or $ sudo fdisk -l) # vgdisplay -v (or $ sudo vgdisplay -v) Here it is: # fdisk -l Disk /dev/sda: 298.1 GiB, 320072933376 bytes, 625142448 sectors Disk model: Hitachi HTS54323 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x0005de22 Device Boot Start End Sectors Size Id Type /dev/sda1 * 2048499711497664 243M 83 Linux /dev/sda2 501758 625141759 624640002 297.9G 5 Extended /dev/sda5 501760 625141759 62464 297.9G 83 Linux Disk /dev/mapper/sda5_crypt: 297.9 GiB, 319814627328 bytes, 624637944 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/mapper/localhost-root: 5.3 GiB, 5716836352 bytes, 11165696 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/mapper/localhost-usr: 13.4 GiB, 14365491200 bytes, 28057600 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/mapper/localhost-var: 2.8 GiB, 2998927360 bytes, 5857280 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/mapper/localhost-swap_1: 5.7 GiB, 6090129408 bytes, 11894784 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/mapper/localhost-tmp: 2.4 GiB, 2545942528 bytes, 4972544 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/mapper/localhost-home: 261 GiB, 280246616064 bytes, 547356672 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes # vgdisplay -v --- Volume group --- VG Name localhost System ID Formatlvm2 Metadata Areas1 Metadata Sequence No 17 VG Access read/write VG Status resizable MAX LV0 Cur LV6 Open LV 6 Max PV0 Cur PV1 Act PV1 VG Size <297.85 GiB PE Size 4.00 MiB Total PE 76249 Alloc PE / Size 74378 / <290.54 GiB Free PE / Size 1871 / <7.31 GiB VG UUID fbCaw1-u3SN-2HCy-w6y8-v0nK-QsFE-FETNZM --- Logical volume --- LV Path/dev/localhost/root LV Nameroot VG Namelocalhost LV UUIDz3MLJc-UsXY-hxOE-xSk2-ipAl-NUny-PDpXv6 LV Write Accessread/write LV Creation host, time , LV Status available # open 1 LV Size5.32 GiB Current LE 1363 Segments 2 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 254:1 --- Logical volume --- LV Path/dev/localhost/usr LV Nameusr VG Namelocalhost LV UUIDUbFZNN-Y0oA-tEAb-5a8g-z65r-Ekqv-agbmrc LV Write Accessread/write LV Creation host, time , LV Status available # open 1 LV Size<13.38 GiB Current LE 3425 Segments 2 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 254:2 --- Logical volume --- LV Path/dev/localhost/var LV Namevar VG Namelocalhost LV UUIDyljPiS-bfh3-w0vA-fAg9-anAE-OaiF-XgvyoY LV Write Accessread/write LV Creation host, time , LV Status available # open 1 LV Size2.79 GiB Current LE 715 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 254:3 --- Logical volume --- LV Path/dev/localhost/swap_1 LV Nameswap_1 VG Namelocalhost LV UUIDpJlSwq-fmd6-sDck-XYOq-QkUs-Zwju-4Y3uSH LV Write Accessread/write LV Creation host, time , LV Status available # open 2 LV Size5.67 GiB Current LE 1452 Segments 1 Allocation inherit Read ahead sectors auto - currently set
Re: Upgrade issue with Debian 9 -> 10
On 7/3/22 7:51 PM, David Christensen wrote: On 7/3/22 02:31, Miroslav Skoric wrote: Hi all, Yesterday I attempted to upgrade Compaq Presario CQ56 laptop to buster. I followed instructions in 'Chapter 4. Upgrades from Debian 9 (stretch)', so all went well with a minimal upgrade (apt-get upgrade). When it finished, I went to the main part of the upgrade (apt full-upgrade). It ran well until some 40-45% and then started complaining about lack of disk space. (apt -o APT::Get::Trivial-Only=true full-upgrade did not say I shall get into any trouble.) So, at one point the full upgrade just exited. I tried to uninstall some old stuff but it was not possible. df -h showed that / and /usr were almost 100% used. Shutdown & reboot seemed going normally, although including few [FAILED] warnings mostly with firewall failed to start and like. Majority went [OK] until the point where it was about to perform fsck on mounted volumes where it looks as an endless process occasionally repeating this line: [nnn.nn] perf: interrupt took too long ( > ), lowering kernel.perf_event_max_sample_rate to n where 'n' are numbers. Ctrl-Alt-F2 brings tty2 from where I can log in, then sudo etc. df -h shows that filesystem /dev/mapper/localhost-root (mounted on /) is 99% used, and /dev/mapper/localhost-usr (mounted on /usr) is 100% used. As it is (an encrypted) LVM, where /dev/mapper/localhost-home (mounted on /home) is only 21% used, I suppose that it shall be possible to resize partitions i.e. logical volumes so that some space of /home to be assigned to / and /usr It seems that resize2fs, lvextend, and some related commands are available in tty2, but I am unsure about the proper order & syntax of those commands. Also, what about the ongoing fsck process in tty1? Any suggestion? The KISS approach is to check in your system configuration files to a version control system, back up your data, take an image of the OS drive, remove the OS drive, insert a blank OS drive, do a fresh install, check out the old system configuration files to a side directory, configure the new OS instance, restore your data, and validate everything. David Seems as a drastic solution :-) Will try to cure this one, and if things go wrong I can always do a fresh install. Misko
Re: Upgrade issue with Debian 9 -> 10
On 7/3/22 4:28 PM, Miroslav Skoric wrote:
Haven't tried that, but something else already helped: While it was
idling with fsck in tty1, I went to tty2 and entered: apt --fix-broken
install ... and it did/resumed full upgrade. (Interestingly, this time
it did not complain about no space in / and /usr.) When it finished, I
tested startx and it brought GUI. Not sure now but I think that I then
rebooted and it went it into GUI as expected. So far - so good. Few red
[FAILED] warnings during CLI phase related to not starting UFV,
Shorewall, and minissdpd services, so I need to check for that.
As a temporary cure for [FAILED] warnings, I removed ufw and gufw as I
sparsely used them anyway. Then I also removed completely all shorewall
things, purged its old folders, and reinstalled again. Now the shorewall
service starts properly. The only remaining [FAILED] warning comes from
minissdpd:
# systemctl status minissdpd.service
● minissdpd.service - keep memory of all UPnP devices that announced
themselves
Loaded: loaded (/lib/systemd/system/minissdpd.service; enabled;
vendor preset
Active: failed (Result: exit-code) since Tue 2022-07-05 13:00:48
CEST; 3min 1
Docs: man:minissdpd(1)
Process: 1225 ExecStart=/usr/lib/minissdpd/minissdpd-systemd-wrapper
${MiniSSD
Jul 05 13:00:48 localhost minissdpd-systemd-wrapper[1225]: can't parse
"wlo1" as
Jul 05 13:00:48 localhost minissdpd-systemd-wrapper[1225]: Usage:
/usr/sbin/mini
Jul 05 13:00:48 localhost minissdpd-systemd-wrapper[1225]:
is eith
Jul 05 13:00:48 localhost minissdpd-systemd-wrapper[1225]:
192.168.1.42/255.25
Jul 05 13:00:48 localhost minissdpd-systemd-wrapper[1225]: By default,
socket
Jul 05 13:00:48 localhost minissdpd-systemd-wrapper[1225]: and pid
written to
Jul 05 13:00:48 localhost minissdpd[1225]: ioctl(s, SIOCGIFADDR, ...):
Cannot as
Jul 05 13:00:48 localhost systemd[1]: minissdpd.service: Control process
exited,
Jul 05 13:00:48 localhost systemd[1]: minissdpd.service: Failed with
result 'exi
Jul 05 13:00:48 localhost systemd[1]: Failed to start keep memory of all
UPnP de
lines 1-16/16 (END)...skipping...
● minissdpd.service - keep memory of all UPnP devices that announced
themselves
Loaded: loaded (/lib/systemd/system/minissdpd.service; enabled;
vendor preset: enabled)
Active: failed (Result: exit-code) since Tue 2022-07-05 13:00:48
CEST; 3min 16s ago
Docs: man:minissdpd(1)
Process: 1225 ExecStart=/usr/lib/minissdpd/minissdpd-systemd-wrapper
${MiniSSDPd_INTERFACE_ADDRESS} $MiniSSDPd_OTHER_OPTIONS (code=exited,
status=1
Jul 05 13:00:48 localhost minissdpd-systemd-wrapper[1225]: can't parse
"wlo1" as a valid address or interface name
Jul 05 13:00:48 localhost minissdpd-systemd-wrapper[1225]: Usage:
/usr/sbin/minissdpd [-d] [-6] [-s socket] [-p pidfile] [-t TTL] [-f
device] -i Jul 05 13:00:48 localhost minissdpd-systemd-wrapper[1225]:
is either an IPv4 address with mask such as
Jul 05 13:00:48 localhost minissdpd-systemd-wrapper[1225]:
192.168.1.42/255.255.255.0, or an interface name such as eth0.
Jul 05 13:00:48 localhost minissdpd-systemd-wrapper[1225]: By default,
socket will be open as /var/run/minissdpd.sock
Jul 05 13:00:48 localhost minissdpd-systemd-wrapper[1225]: and pid
written to file /var/run/minissdpd.pid
Jul 05 13:00:48 localhost minissdpd[1225]: ioctl(s, SIOCGIFADDR, ...):
Cannot assign requested address
Jul 05 13:00:48 localhost systemd[1]: minissdpd.service: Control process
exited, code=exited, status=1/FAILURE
Jul 05 13:00:48 localhost systemd[1]: minissdpd.service: Failed with
result 'exit-code'.
Jul 05 13:00:48 localhost systemd[1]: Failed to start keep memory of all
UPnP devices that announced themselves.
~
~
~
~
... Seems it does not like network device change (wlan0 --> wlo1). It
makes me wonder if I shall try to remove/reinstall minissdpd. Any idea?
Well, for sure I missed to uninstall some software that I rarely used in
stretch, and if I did so I might have not got into trouble. Now will
take more care with buster.
I freed some 1.5 GB by removing LaTeX and TeX Live packages that I
installed few years ago just for test but never really used. Probably
need to get rid of more unneeded stuff.
So far - so good. Seems that buster runs a bit faster (than stretch) on
this old laptop.
Misko
Re: Upgrade issue with Debian 9 -> 10
On 7/3/22 08:28, Miroslav Skoric wrote: ... Haven't tried that, but something else already helped: While it was idling with fsck in tty1, I went to tty2 and entered: apt --fix-broken install ... and it did/resumed full upgrade. (Interestingly, this time it did not complain about no space in / and /usr.) When it finished, I tested startx and it brought GUI. Not sure now but I think that I then rebooted and it went it into GUI as expected. So far - so good. Few red [FAILED] warnings during CLI phase related to not starting UFV, Shorewall, and minissdpd services, so I need to check for that. A subsequent apt --fix-broken install (or some other command) only complained about some initrd issue with kernel image 4.19.0-20-686 so I removed that image and stayed with 4.9.0-19-686. After that, apt autoremove freed some 500MB of old stretch packages so now / is about 97% used, while /usr is still 100% used. Post the output from # fdisk -l (or $ sudo fdisk -l) # vgdisplay -v (or $ sudo vgdisplay -v) You likely will obtain some specific useful suggestions for moving forward that do not involve reinstallation. I have a (now virtual) image of a machine that began life as Debian 1.3 (Bo) and has been upgraded, now, through 11.3, the current release, with an Oracle 8.0.5 DBMS that was installed around . The upgrades ultimately finished satisfactorily, although were occasional bumps in the road. Regards, Tom Dial In thi situation, I might be tempted to save off any data in /home and any options in /etc/ to configure mail and things like that and do a reinstall with Debian 11 as a quick fix but that's a destructive option. ... Thanks. Misko
Re: Upgrade issue with Debian 9 -> 10
On 7/3/22 02:31, Miroslav Skoric wrote: Hi all, Yesterday I attempted to upgrade Compaq Presario CQ56 laptop to buster. I followed instructions in 'Chapter 4. Upgrades from Debian 9 (stretch)', so all went well with a minimal upgrade (apt-get upgrade). When it finished, I went to the main part of the upgrade (apt full-upgrade). It ran well until some 40-45% and then started complaining about lack of disk space. (apt -o APT::Get::Trivial-Only=true full-upgrade did not say I shall get into any trouble.) So, at one point the full upgrade just exited. I tried to uninstall some old stuff but it was not possible. df -h showed that / and /usr were almost 100% used. Shutdown & reboot seemed going normally, although including few [FAILED] warnings mostly with firewall failed to start and like. Majority went [OK] until the point where it was about to perform fsck on mounted volumes where it looks as an endless process occasionally repeating this line: [nnn.nn] perf: interrupt took too long ( > ), lowering kernel.perf_event_max_sample_rate to n where 'n' are numbers. Ctrl-Alt-F2 brings tty2 from where I can log in, then sudo etc. df -h shows that filesystem /dev/mapper/localhost-root (mounted on /) is 99% used, and /dev/mapper/localhost-usr (mounted on /usr) is 100% used. As it is (an encrypted) LVM, where /dev/mapper/localhost-home (mounted on /home) is only 21% used, I suppose that it shall be possible to resize partitions i.e. logical volumes so that some space of /home to be assigned to / and /usr It seems that resize2fs, lvextend, and some related commands are available in tty2, but I am unsure about the proper order & syntax of those commands. Also, what about the ongoing fsck process in tty1? Any suggestion? The KISS approach is to check in your system configuration files to a version control system, back up your data, take an image of the OS drive, remove the OS drive, insert a blank OS drive, do a fresh install, check out the old system configuration files to a side directory, configure the new OS instance, restore your data, and validate everything. David
Re: Upgrade issue with Debian 9 -> 10
On 7/3/22 1:17 PM, Andrew M.A. Cater wrote: Ctrl-Alt-F2 brings tty2 from where I can log in, then sudo etc. df -h shows that filesystem /dev/mapper/localhost-root (mounted on /) is 99% used, and /dev/mapper/localhost-usr (mounted on /usr) is 100% used. Apt tends to store files in /var - it's possible that /var is also full. Possibly. /var was always around 49-50% used here, but I knew from some earlier upgrade that it might be too small to store new packages for upgrading to buster. And because of that I added a thumb drive as a temporary /var/archives, and it served the purpose. If you repeat an apt-get update - do you have errors about needing to rerun a configure step? Haven't tried that, but something else already helped: While it was idling with fsck in tty1, I went to tty2 and entered: apt --fix-broken install ... and it did/resumed full upgrade. (Interestingly, this time it did not complain about no space in / and /usr.) When it finished, I tested startx and it brought GUI. Not sure now but I think that I then rebooted and it went it into GUI as expected. So far - so good. Few red [FAILED] warnings during CLI phase related to not starting UFV, Shorewall, and minissdpd services, so I need to check for that. A subsequent apt --fix-broken install (or some other command) only complained about some initrd issue with kernel image 4.19.0-20-686 so I removed that image and stayed with 4.9.0-19-686. After that, apt autoremove freed some 500MB of old stretch packages so now / is about 97% used, while /usr is still 100% used. In thi situation, I might be tempted to save off any data in /home and any options in /etc/ to configure mail and things like that and do a reinstall with Debian 11 as a quick fix but that's a destructive option. Will see whether it will work without such a destructive option :-) In fact, that laptop started running Linux as squeeze some ten years ago, and I gradually upgraded it to wheezy, jessie, ... It makes me wonder if I gave it few more years of life with buster, after stretch went EOL yesterday. When you installed, did you manually specify sizes for filesystems or did you say "install in one encrypted LVM"? I cannot remember because I made it with squeeze somewhere in 2013 or so. What I do recall is that at some upgrade point I had similar space issues, when resize2fs and/or lvextend solved the problem within the existing LVM. (I had 'borrowed' some space where I had a surplus, and added where needed. Probably I will need to learn it again.) If you did that then, effectively, /home and so on are auto-sized and LVM is keeping track of free space. Deleting unwanted files is the only way to reclaim space and then, perhaps resize. Well, for sure I missed to uninstall some software that I rarely used in stretch, and if I did so I might have not got into trouble. Now will take more care with buster. Good luck with it all - with every good wish, as ever, Andy Cater Thanks. Misko
Re: Upgrade issue with Debian 9 -> 10
On Sun, Jul 03, 2022 at 11:31:40AM +0200, Miroslav Skoric wrote: > Hi all, > > Yesterday I attempted to upgrade Compaq Presario CQ56 laptop to buster. I > followed instructions in 'Chapter 4. Upgrades from Debian 9 (stretch)', so > all went well with a minimal upgrade (apt-get upgrade). When it finished, I > went to the main part of the upgrade (apt full-upgrade). It ran well until > some 40-45% and then started complaining about lack of disk space. > > (apt -o APT::Get::Trivial-Only=true full-upgrade did not say I shall get > into any trouble.) > > So, at one point the full upgrade just exited. I tried to uninstall some old > stuff but it was not possible. df -h showed that / and /usr were almost 100% > used. > > Shutdown & reboot seemed going normally, although including few [FAILED] > warnings mostly with firewall failed to start and like. Majority went [OK] > until the point where it was about to perform fsck on mounted volumes where > it looks as an endless process occasionally repeating this line: > > [nnn.nn] perf: interrupt took too long ( > ), lowering > kernel.perf_event_max_sample_rate to n > > where 'n' are numbers. > > Ctrl-Alt-F2 brings tty2 from where I can log in, then sudo etc. df -h shows > that filesystem /dev/mapper/localhost-root (mounted on /) is 99% used, and > /dev/mapper/localhost-usr (mounted on /usr) is 100% used. > Apt tends to store files in /var - it's possible that /var is also full. If you repeat an apt-get update - do you have errors about needing to rerun a configure step? In thi situation, I might be tempted to save off any data in /home and any options in /etc/ to configure mail and things like that and do a reinstall with Debian 11 as a quick fix but that's a destructive option. apt-get clean may clear out some downloaded packages and provide some space. > As it is (an encrypted) LVM, where /dev/mapper/localhost-home (mounted on > /home) is only 21% used, I suppose that it shall be possible to resize > partitions i.e. logical volumes so that some space of /home to be assigned > to / and /usr > When you installed, did you manually specify sizes for filesystems or did you say "install in one encrypted LVM"? If you did that then, effectively, /home and so on are auto-sized and LVM is keeping track of free space. Deleting unwanted files is the only way to reclaim space and then, perhaps resize. There's a reason that I install into one filesystem if I can - manual sizing and partitioning rarely works unless you have a specific use. On one machine here I have a 7TB /srv partition deliberately because it's full of data that I want to serve out via a webserver - in any other machine, I'd probably have said use the whole 8TB filesystem and auto partition. > It seems that resize2fs, lvextend, and some related commands are available > in tty2, but I am unsure about the proper order & syntax of those commands. > Also, what about the ongoing fsck process in tty1? Any suggestion? > Good luck with it all - with every good wish, as ever, Andy Cater > Misko >
