Mailing List Archive

On 13/09/2020 11:17, Peter Humphrey wrote:
> Morning all,
>
> My ~amd64 system uses partitions 1 to 18 on /dev/nvme0n1, and it has two SATA
> disks as well, for various purposes. Today, after I'd taken the system down
> for its weekly backup (I tar all the partitions to a USB disk) and started up
> again, invoking gparted to look around, libparted spat out a list of
> partitions from 19 to 128 which, it said, "have been written but we have been
> unable to inform the kernel of the change..."
>
> I remerged gparted, parted, libparted and udisks, then booted another system
> and ran fsck -f on all the partitions from 4 to 18 - those that this system
> uses - and rebooted. No change - the same complaint from libparted.
>
> I get a similar complaint about /dev/sda.
>
> Those errors are repeated once.
>
> Is this a terminal condition? I could repartition and restore from backup, but
> I hope someone can offer a clue before I resort to that.
>
You're using the wrong tool to try and fix it. There's clearly something
wrong with your partition TABLE, and you're using a tool that fixes the
partition CONTENTS.

Use gparted (or gdisk) on the DISK, and that should sort things out.
Check whether it thinks those partitions exist or not, and then get it
to write a new partition table to clean things up.

Cheers,
Wol

On Sunday, 13 September 2020 12:40:47 BST antlists wrote:

> You're using the wrong tool to try and fix it. There's clearly something
> wrong with your partition TABLE, and you're using a tool that fixes the
> partition CONTENTS.

Yes, I was clutching at straws, rather.

> Use gparted (or gdisk) on the DISK, and that should sort things out.
> Check whether it thinks those partitions exist or not, and then get it
> to write a new partition table to clean things up.

Gparted 0.31.0 on my rescue CD finds no problems. Parted in this system doesn't
offer a checking tool, but gdisk does and it reports "no problems". Gparted
1.1.0 in this system still reports the errors, but only once now on each disk
(so what's changed there? Beats me).

Udisks was upgraded on 13 August and I may not have used gparted since then,
but reverting to the previous version hasn't helped. All the other packages I
mentioned have not been changed for months.

So I'm still left wondering what to do. I'm happy that the hardware isn't on
the blink, anyway.

--
Regards,
Peter.

On 13/09/20 13:26, Peter Humphrey wrote:
> So I'm still left wondering what to do. I'm happy that the hardware isn't on
> the blink, anyway.

Can you use gdisk to create a new partition in some empty space on the
disk, delete it again, and write a partition table? Basically anything
to get gdisk or gparted to actually write a new partition table (that
should be the same as the old one, of course).

If there are hidden problems that udisk or whatever is picking up on -
garbage data somewhere most likely - that's the most likely way of
clearing it.

Cheers,
Wol

I'm backing up my partitions maps to avoid such problems, I've had them before on spinning rust.  Also backing up the headers of luks partitions, loose those and your' really sunk!

--"Fascism begins the moment a ruling class, fearing the people may use their political democracy to gain economic democracy, begins to destroy political democracy in order to retain its power of exploitation and special privilege." Tommy Douglas




Sep 13, 2020, 06:26 by peter@prh.myzen.co.uk:

> On Sunday, 13 September 2020 12:40:47 BST antlists wrote:
>
>> You're using the wrong tool to try and fix it. There's clearly something
>> wrong with your partition TABLE, and you're using a tool that fixes the
>> partition CONTENTS.
>>
>
> Yes, I was clutching at straws, rather.
>
>> Use gparted (or gdisk) on the DISK, and that should sort things out.
>> Check whether it thinks those partitions exist or not, and then get it
>> to write a new partition table to clean things up.
>>
>
> Gparted 0.31.0 on my rescue CD finds no problems. Parted in this system doesn't
> offer a checking tool, but gdisk does and it reports "no problems". Gparted
> 1.1.0 in this system still reports the errors, but only once now on each disk
> (so what's changed there? Beats me).
>
> Udisks was upgraded on 13 August and I may not have used gparted since then,
> but reverting to the previous version hasn't helped. All the other packages I
> mentioned have not been changed for months.
>
> So I'm still left wondering what to do. I'm happy that the hardware isn't on
> the blink, anyway.
>
> --
> Regards,
> Peter.
>

On Sun, Sep 13, 2020 at 8:17 PM Peter Humphrey <peter@prh.myzen.co.uk>
wrote:

> Morning all,
>
> My ~amd64 system uses partitions 1 to 18 on /dev/nvme0n1, and it has two
> SATA
> disks as well, for various purposes. Today, after I'd taken the system
> down
> for its weekly backup (I tar all the partitions to a USB disk) and started
> up
> again, invoking gparted to look around, libparted spat out a list of
> partitions from 19 to 128 which, it said, "have been written but we have
> been
> unable to inform the kernel of the change..."
>
> I remerged gparted, parted, libparted and udisks, then booted another
> system
> and ran fsck -f on all the partitions from 4 to 18 - those that this
> system
> uses - and rebooted. No change - the same complaint from libparted.
>

I would start by dd ing an image of the entire disk, then making a copy to
work on (keeping the original image as a backup) then running testdisk
against the working copy image to see what it reports.

On Sunday, 13 September 2020 17:05:22 BST Wols Lists wrote:
> On 13/09/20 13:26, Peter Humphrey wrote:
> > So I'm still left wondering what to do. I'm happy that the hardware isn't
> > on the blink, anyway.
>
> Can you use gdisk to create a new partition in some empty space on the
> disk, delete it again, and write a partition table? Basically anything
> to get gdisk or gparted to actually write a new partition table (that
> should be the same as the old one, of course).

Nice idea. Thanks.

> If there are hidden problems that udisk or whatever is picking up on -
> garbage data somewhere most likely - that's the most likely way of
> clearing it.

I used gdisk to create a new partition at the end of the disk, then rebooted
so that the kernel would have the right disk layout. No change.

Just before this started, I booted Win-10 on /dev/sdb and ran its update
process. I don't use it for anything at the moment, just keeping it up to date
in case I ever do. I do this most weeks, but is it possible that Win-10
tampered in some way that it hasn't before? I'm seeing these errors on /dev/
sda (which does have an NTFS partition) and /dev/nvme0n1 (which does not), but
not on /dev/sdb.

--
Regards,
Peter.

On Monday, September 14, 2020 9:48:07 AM CEST Peter Humphrey wrote:
> On Sunday, 13 September 2020 17:05:22 BST Wols Lists wrote:
> > On 13/09/20 13:26, Peter Humphrey wrote:

> Just before this started, I booted Win-10 on /dev/sdb and ran its update
> process.
>
> I don't use it for anything at the moment, just keeping it up to
> date in case I ever do. I do this most weeks, but is it possible that
> Win-10 tampered in some way that it hasn't before? I'm seeing these errors
> on /dev/ sda (which does have an NTFS partition) and /dev/nvme0n1 (which
> does not), but not on /dev/sdb.

This right here can be the problem.
My laptop is dual-boot and I had a few times my boot-process was killed
because MS Windows 10 likes to, randomly, add additional partitions for it's
restore stuff. It will happily resize existing partitions to make room.

If the partition layout is not something MS considers "normal", you get into
these issues.

--
Joost

On Monday, 14 September 2020 09:04:04 BST J. Roeleveld wrote:
> On Monday, September 14, 2020 9:48:07 AM CEST Peter Humphrey wrote:
> > On Sunday, 13 September 2020 17:05:22 BST Wols Lists wrote:
> > > On 13/09/20 13:26, Peter Humphrey wrote:
> > Just before this started, I booted Win-10 on /dev/sdb and ran its update
> > process.
> >
> > I don't use it for anything at the moment, just keeping it up to
> > date in case I ever do. I do this most weeks, but is it possible that
> > Win-10 tampered in some way that it hasn't before? I'm seeing these errors
> > on /dev/ sda (which does have an NTFS partition) and /dev/nvme0n1 (which
> > does not), but not on /dev/sdb.
>
> This right here can be the problem.
> My laptop is dual-boot and I had a few times my boot-process was killed
> because MS Windows 10 likes to, randomly, add additional partitions for it's
> restore stuff. It will happily resize existing partitions to make room.
>
> If the partition layout is not something MS considers "normal", you get into
> these issues.

Hm. I'm wondering why it might fiddle with the two disks it's not installed on,
but not the one it is. Also, why damage the partition tables without adding,
deleting or resizing any partitions? And Windows must be able to recognise
ext4 by now, surely?

--
Regards,
Peter.

On 14/09/2020 08:48, Peter Humphrey wrote:
> Just before this started, I booted Win-10 on /dev/sdb and ran its update
> process. I don't use it for anything at the moment, just keeping it up to date
> in case I ever do. I do this most weeks, but is it possible that Win-10
> tampered in some way that it hasn't before? I'm seeing these errors on/dev/
> sda (which does have an NTFS partition) and /dev/nvme0n1 (which does not), but
> not on /dev/sdb.

I know Windows has hidden partitions and things, but it shouldn't be
tampering with the partition table. What sector does sda1 start on? It
should be something like 2048. I don't play with that enough to really
know what's going on, but if that number is single digits then that
could be the problem ...

Cheers,
Wol

On Monday, 14 September 2020 09:38:10 BST antlists wrote:
> On 14/09/2020 08:48, Peter Humphrey wrote:
> > Just before this started, I booted Win-10 on /dev/sdb and ran its update
> > process. I don't use it for anything at the moment, just keeping it up to
> > date in case I ever do. I do this most weeks, but is it possible that
> > Win-10 tampered in some way that it hasn't before? I'm seeing these
> > errors on/dev/ sda (which does have an NTFS partition) and /dev/nvme0n1
> > (which does not), but not on /dev/sdb.
>
> I know Windows has hidden partitions and things, but it shouldn't be
> tampering with the partition table. What sector does sda1 start on? It
> should be something like 2048. I don't play with that enough to really
> know what's going on, but if that number is single digits then that
> could be the problem ...

Well, I bit the bullet and started again with a new GPT partition table. I
made the partitions the same sizes as before, but this time when I ran
mkfs.ext4 on them, I wasn't told that a file system already existed with the
same name. Something had evidently been changed.

Then followed three days of trying to get the system to boot. Even though the
root and /boot partitions were exactly as before and I gave the same commands
to efibootmgr and bootctl, either the BIOS couldn't find a kernel, or it did but
then the kernel couldn't find a file system.

In the end I pointed efibootmgr at the systemd directory and it then started.
That was definitely a new arrangement.

The Gentoo wiki could do with some expert revision; it doesn't explain any of
the structure, so when its commands don't return the expected result, I'm left
with guesswork. For example, I've only recently realised that bootctl is
needed if you want a boot menu of kernels (not counting grub-2, which I would
only install under duress).

At the end of all this, I'm left wondering what happened to the original
system. (Cosmic-ray strike?) I'm not convinced that Win-10 would go round
seeding something into all those partitions that could exist but don't, on the
disks it wasn't installed on. And why did mkfs not recognise the old file
systems?

I don't like mysteries.

--
Regards,
Peter.

On Thursday, 17 September 2020 09:34:04 -00 Peter Humphrey wrote:
> On Monday, 14 September 2020 09:38:10 BST antlists wrote:
> > On 14/09/2020 08:48, Peter Humphrey wrote:
> > > Just before this started, I booted Win-10 on /dev/sdb and ran its update
> > > process. I don't use it for anything at the moment, just keeping it up
> > > to
> > > date in case I ever do. I do this most weeks, but is it possible that
> > > Win-10 tampered in some way that it hasn't before? I'm seeing these
> > > errors on/dev/ sda (which does have an NTFS partition) and /dev/nvme0n1
> > > (which does not), but not on /dev/sdb.
> >
> > I know Windows has hidden partitions and things, but it shouldn't be
> > tampering with the partition table. What sector does sda1 start on? It
> > should be something like 2048. I don't play with that enough to really
> > know what's going on, but if that number is single digits then that
> > could be the problem ...
>
> Well, I bit the bullet and started again with a new GPT partition table. I
> made the partitions the same sizes as before, but this time when I ran
> mkfs.ext4 on them, I wasn't told that a file system already existed with the
> same name. Something had evidently been changed.
>
> Then followed three days of trying to get the system to boot. Even though
> the root and /boot partitions were exactly as before and I gave the same
> commands to efibootmgr and bootctl, either the BIOS couldn't find a kernel,
> or it did but then the kernel couldn't find a file system.
>
> In the end I pointed efibootmgr at the systemd directory and it then
> started. That was definitely a new arrangement.
>
> The Gentoo wiki could do with some expert revision; it doesn't explain any
> of the structure, so when its commands don't return the expected result,
> I'm left with guesswork. For example, I've only recently realised that
> bootctl is needed if you want a boot menu of kernels (not counting grub-2,
> which I would only install under duress).
>
> At the end of all this, I'm left wondering what happened to the original
> system. (Cosmic-ray strike?) I'm not convinced that Win-10 would go round
> seeding something into all those partitions that could exist but don't, on
> the disks it wasn't installed on. And why did mkfs not recognise the old
> file systems?
>
> I don't like mysteries.

Mystery solved. It was a disk failure: a 256GB NVMe drive. It was 4.5 years
old, which doesn't seem a long life to me.

--
Regards,
Peter.

On 19/10/2020 12:33, Peter Humphrey wrote:
> Mystery solved. It was a disk failure: a 256GB NVMe drive. It was 4.5 years
> old, which doesn't seem a long life to me.

Doesn't sound old, but if it breaks in the fault-tolerance-management
area, then you're stuffed. Bit like old MFM (pre-IDE) drives had the
bad-block-management area, and if the first (boot/partition) sector
went, or said bad-block area, the drive was scrap.

Cheers,
Wol