Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #224225 > unrolled thread

Cannot get systemd to forget about swap space on a failed disk

Back to article view | Back to linux.debian.user

Contents

  Cannot get systemd to forget about swap space on a failed disk Bob McGowan <ramjr0915@gmail.com> - 2020-06-30 08:40 +0200
    Re: Cannot get systemd to forget about swap space on a failed disk Reco <recoverym4n@enotuniq.net> - 2020-06-30 09:00 +0200
      Re: Cannot get systemd to forget about swap space on a failed disk Bob McGowan <ramjr0915@gmail.com> - 2020-07-01 07:30 +0200
        Re: Cannot get systemd to forget about swap space on a failed disk David Wright <deblis@lionunicorn.co.uk> - 2020-07-02 03:30 +0200
    Re: Cannot get systemd to forget about swap space on a failed disk deloptes <deloptes@gmail.com> - 2020-06-30 09:20 +0200

#224225 — Cannot get systemd to forget about swap space on a failed disk

[Multipart message — attachments visible in raw view] — view raw

Please see thread with subject "Be careful when editing /etc/fstab" for 
a bit of background.

My computer had two swap partitions, on two different disks, when one of 
them started to generate CRC errors, seek errors, etc.

Once I determined which of the two it was, I commented out the 
/etc/fstab entry for it, halted the system, removed the faulty disk and 
rebooted.  I got dumped into the "emergency rescue" single user mode, 
after waiting several minutes for various "start jobs" to time out.

Given the above referenced email, and the info in the links it 
references, I would have thought that rebooting, with the modified fstab 
file, should have worked just fine.

However, as noted, it did not, so I must assume systemd has a unit (is 
this the right term?) defining my original swap setup.

I did find in man pages, that if both fstab and a systemd unit define 
the same thing, systemd wins.

That just reinforces the idea that somewhere, systemd knows the swap 
disk devices.

But I cannot figure out where this might be, or even if this is the 
correct interpretation.

Any suggestions on next steps greatly appreciated.

Bob

[toc] | [next] | [standalone]

#224227

	Hi.

On Mon, Jun 29, 2020 at 11:10:44PM -0700, Bob McGowan wrote:
> But I cannot figure out where this might be, or even if this is the correct interpretation.

Check out the contents of /etc/systemd/system first.
Rebuild initramfs second.

Reco

[toc] | [prev] | [next] | [standalone]

#224243

[Multipart message — attachments visible in raw view] — view raw

On 6/29/2020 11:37 PM, Reco wrote:
> 	Hi.
>
> On Mon, Jun 29, 2020 at 11:10:44PM -0700, Bob McGowan wrote:
>> But I cannot figure out where this might be, or even if this is the correct interpretation.
> Check out the contents of /etc/systemd/system first.
> Rebuild initramfs second.
>
> Reco

Hi,

It seems my troubleshooting skills are not up to snuff. :(

I isolated the wrong disk.  This is partly due to the complexity 
(excessive, I think) of the systemd system, partly due to the fact that 
the startup reports of running jobs associated with disks overwrite each 
other, and I just grabbed the wrong one.

Regardless, upon commenting the correct disk out of fstab, and adding 
back my new secondary swap, everything works again as expected.

It may help others to know what I did.

Part of my original failure to find anything was because I was focused 
on the /lib/systemd, /usr/lib/systemd and /etc/systemd directories.  
Even though I had read the documentation that referenced /run/systemd, I 
had not checked it out.

When I did, I immediately found the correct UUID information for the 
actual failing disk.  And the rest is history.

Thanks for taking the time to look into this.

Bob

[toc] | [prev] | [next] | [standalone]

#224277

On Tue 30 Jun 2020 at 22:04:02 (-0700), Bob McGowan wrote:
> On 6/29/2020 11:37 PM, Reco wrote:
> > On Mon, Jun 29, 2020 at 11:10:44PM -0700, Bob McGowan wrote:
> > > But I cannot figure out where this might be, or even if this is the correct interpretation.
> > Check out the contents of /etc/systemd/system first.
> > Rebuild initramfs second.
> 
> It seems my troubleshooting skills are not up to snuff. :(
> 
> I isolated the wrong disk.  This is partly due to the complexity
> (excessive, I think) of the systemd system, partly due to the fact
> that the startup reports of running jobs associated with disks
> overwrite each other, and I just grabbed the wrong one.
> 
> Regardless, upon commenting the correct disk out of fstab, and adding
> back my new secondary swap, everything works again as expected.
> 
> It may help others to know what I did.
> 
> Part of my original failure to find anything was because I was focused
> on the /lib/systemd, /usr/lib/systemd and /etc/systemd directories. 
> Even though I had read the documentation that referenced /run/systemd,
> I had not checked it out.
> 
> When I did, I immediately found the correct UUID information for the
> actual failing disk.  And the rest is history.

I've never consulted those directories, but just use the files
/etc/fstab and /etc/crypttab (written by yourself), a listing
of /dev/disk, and the appropriate commands for handling swap.
Also lsblk gives a neat overview.

So I would stop your broken partition with:

# swapoff foo
# swapon --show		(to see the remaining one and check it out)
# nano /etc/fstab	(and comment the bad entry)
# systemctl daemon-reload

rather than editing fstab while the partition is in use.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#224228

Bob McGowan wrote:

> Please see thread with subject "Be careful when editing /etc/fstab" for
> a bit of background.
> 
> My computer had two swap partitions, on two different disks, when one of
> them started to generate CRC errors, seek errors, etc.
> 
> Once I determined which of the two it was, I commented out the
> /etc/fstab entry for it, halted the system, removed the faulty disk and
> rebooted.  I got dumped into the "emergency rescue" single user mode,
> after waiting several minutes for various "start jobs" to time out.
> 
> Given the above referenced email, and the info in the links it
> references, I would have thought that rebooting, with the modified fstab
> file, should have worked just fine.
> 
> However, as noted, it did not, so I must assume systemd has a unit (is
> this the right term?) defining my original swap setup.
> 
> I did find in man pages, that if both fstab and a systemd unit define
> the same thing, systemd wins.
> 
> That just reinforces the idea that somewhere, systemd knows the swap
> disk devices.
> 
> But I cannot figure out where this might be, or even if this is the
> correct interpretation.
> 
> Any suggestions on next steps greatly appreciated.
> 
> Bob

If you are using LVM - check LVM. If you keep the disk in the machine -
remove the swap partition. Repeat the test.

# find /lib/systemd/ | grep swap
/lib/systemd/system/swap.target

also

# grep -i swap -r /lib/systemd/
Binary file /lib/systemd/systemd-udevd matches
/lib/systemd/system/sysinit.target:Wants=local-fs.target swap.target
/lib/systemd/system/sysinit.target:After=local-fs.target swap.target
emergency.service emergency.target
/lib/systemd/system/swap.target:Description=Swap
/lib/systemd/system/systemd-journald-dev-log.socket:# Mount and swap units
need this. If this socket unit is removed by an
/lib/systemd/system/systemd-journald-dev-log.socket:# isolate request the
mount and swap units would be removed too,
/lib/systemd/system/systemd-journald.socket:# Mount and swap units need
this. If this socket unit is removed by an
/lib/systemd/system/systemd-journald.socket:# isolate request the mount and
swap units would be removed too,

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web