Am Fri, Dec 20, 2024 at 11:02:55PM +0100 schrieb k...@aspodata.se:
> Alan Mackenzie:
> ...
> > By the way, do you know an easy way for copying an entire filesystem,
> > such as the root system, but without copying other systems mounted in
> > it? I tried for some while with rsync and various combi
> I think any system admins reading this would long for the
> predictability of "consumer hardware", having too often been
> confronted with indistinguishable 32 hex digit identifiers. I would
> imagine it quite likely that the said admins have written scripts to
> make this more manageable.
Si
Hello, Wol.
On Sun, Dec 22, 2024 at 16:53:17 +, Wols Lists wrote:
> On 22/12/2024 15:29, Peter Humphrey wrote:
> > On Sunday 22 December 2024 13:43:08 GMT Alan Mackenzie wrote:
> >> The trouble [is] that a kernel command line, or /etc/fstab, using lots
> >> of these is not human readable, and
On 22/12/2024 15:29, Peter Humphrey wrote:
On Sunday 22 December 2024 13:43:08 GMT Alan Mackenzie wrote:
The trouble [is] that a kernel command line, or /etc/fstab, using lots
of these is not human readable, and hence is at the edge of
unmaintainability. This maintenance difficulty surely outw
On Sunday 22 December 2024 13:43:08 GMT Alan Mackenzie wrote:
> The trouble [is] that a kernel command line, or /etc/fstab, using lots
> of these is not human readable, and hence is at the edge of
> unmaintainability. This maintenance difficulty surely outweighs the
> rare situation where the phy
Hello, Wol.
On Sun, Dec 22, 2024 at 12:02:49 +, Wols Lists wrote:
> On 20/12/2024 17:44, k...@aspodata.se wrote:
> >> If I understand things correctly, with this mechanism one can have the
> >> kernel assemble the RAID arrays at boot up time with a modern metadata,
> >> but still without needi
Hello again!
On Sat, Dec 21, 2024 at 16:58:59 +, Alan Mackenzie wrote:
> Hello, Karl.
> On Sat, Dec 21, 2024 at 17:45:13 +0100, k...@aspodata.se wrote:
> > Alan Mackenzie:
> > ...
> > > I've now got working code which assembles a metadata 1.2 RAID array at
> > > boot time. The syntax needed
On 21/12/2024 12:43, Alan Mackenzie wrote:
, where the extra bit is optional. This enhancement would not be
difficult. The trouble is more political. I think this code is
maintained by RedHat. RedHat's customers all use initramfs, so they
probably think everybody else should, too, hence would
On 20/12/2024 20:19, Alan Mackenzie wrote:
I've just tried it, with metadata 1.2, and it doesn't work. I got error
messages at boot up to the effect that the component partitions were
lacking valid version 0.0 super blocks.
People without initramfs appear not to be in the sights of the
maintain
On 20/12/2024 17:44, k...@aspodata.se wrote:
If I understand things correctly, with this mechanism one can have the
kernel assemble the RAID arrays at boot up time with a modern metadata,
but still without needing the initramfs. My arrays are still at
metadata 0.90.
Please tell if you make bo
Hello, Karl.
On Sat, Dec 21, 2024 at 17:45:13 +0100, k...@aspodata.se wrote:
> Alan Mackenzie:
> ...
> > I've now got working code which assembles a metadata 1.2 RAID array at
> > boot time. The syntax needed on the command line is, again,
> > md=124,1.2,/dev/nvme0n1p6,/dev/nvme1n1p6
> > ..
Alan Mackenzie:
...
> I've now got working code which assembles a metadata 1.2 RAID array at
> boot time. The syntax needed on the command line is, again,
>
> md=124,1.2,/dev/nvme0n1p6,/dev/nvme1n1p6
>
> .. In place of 1.2 can be any of 0.90, 1.0, 1.1, though I haven't tested
> it with anyt
Hello again, Karl.
On Sat, Dec 21, 2024 at 12:43:50 +, Alan Mackenzie wrote:
> On Fri, Dec 20, 2024 at 23:02:58 +0100, k...@aspodata.se wrote:
> > Alan Mackenzie:
> > > On Fri, Dec 20, 2024 at 18:44:53 +0100, k...@aspodata.se wrote:
> > ...
> > > > Please tell if you make booting with metadata
Hello, Karl.
On Fri, Dec 20, 2024 at 23:02:58 +0100, k...@aspodata.se wrote:
> Alan Mackenzie:
> > On Fri, Dec 20, 2024 at 18:44:53 +0100, k...@aspodata.se wrote:
> ...
> > > Please tell if you make booting with metadata 1.2 work.
> > > I havn't tested that.
> > I've just tried it, with metadata
Alan Mackenzie:
> On Fri, Dec 20, 2024 at 18:44:53 +0100, k...@aspodata.se wrote:
...
> > Please tell if you make booting with metadata 1.2 work.
> > I havn't tested that.
>
> I've just tried it, with metadata 1.2, and it doesn't work. I got error
> messages at boot up to the effect that the comp
Alan Mackenzie:
...
> By the way, do you know an easy way for copying an entire filesystem,
> such as the root system, but without copying other systems mounted in
> it? I tried for some while with rsync and various combinations of
> find's and xargs's, and in the end booted up into the rescue dis
Hello, Hoël.
On Fri, Dec 20, 2024 at 21:38:42 +0100, Hoël Bézier wrote:
> Am Fr, Dez 20, 2024 am 08:19:55 + schrieb Alan Mackenzie:
> >By the way, do you know an easy way for copying an entire filesystem,
> >such as the root system, but without copying other systems mounted in
> >it? I tried
Am Fr, Dez 20, 2024 am 08:19:55 + schrieb Alan Mackenzie:
By the way, do you know an easy way for copying an entire filesystem,
such as the root system, but without copying other systems mounted in
it? I tried for some while with rsync and various combinations of
find's and xargs's, and in t
Hello, Karl.
On Fri, Dec 20, 2024 at 18:44:53 +0100, k...@aspodata.se wrote:
> Alan Mackenzie:
> > On Fri, Dec 20, 2024 at 15:50:53 +0100, k...@aspodata.se wrote:
> ...
> > Because I didn't know about it. I found out about it this morning, and
> > immediately tested it by setting up an
> > "md=12
Alan Mackenzie:
> On Fri, Dec 20, 2024 at 15:50:53 +0100, k...@aspodata.se wrote:
...
> Because I didn't know about it. I found out about it this morning, and
> immediately tested it by setting up an
> "md=126,/dev/nvme0n1p4,/dev/nvme1n1p4" on the kernel command line, using
> the rescue disk to ma
Hello, Karl.
On Fri, Dec 20, 2024 at 15:50:53 +0100, k...@aspodata.se wrote:
> Alan Mackenzie:
> ...
> > The cause was me booting up the machine with a rescue disk. This
> > assembled my RAID partitions /dev/md127 and /dev/md126 reversed, but
> > also wrote those wrong identifiers, 126 and 127, i
Alan Mackenzie:
...
> The cause was me booting up the machine with a rescue disk. This
> assembled my RAID partitions /dev/md127 and /dev/md126 reversed, but
> also wrote those wrong identifiers, 126 and 127, into the "preferred
> minor" field of the partitions' super blocks. In essence, they got
Hello, Gentoo.
After having got the syslinux boot manager working well, I lost the root
partition on my newer machine. I spent the entire evening yesterday
trying to get it back again, with various expedients for recovering ext4
partitions from backup superblocks, and so on.
It wasn't until the
23 matches
Mail list logo
