Re: [OpenIndiana-discuss] dell 15810 bricked after latest update

2022-06-27 Thread s...@pandora.be


By the way the subject line says "dell 15810" but in fact in the text you wrote

t5810

I think the T5810 is probably the right model name 'T' for Tower not '1' like 
15810

There is no entry for the T5810 but interesting perhaps to have it submitted 
(added) to

http://docs.openindiana.org/community-hcl/systems

I believe the current version T5820 and T7920 are available with some Linux 
distributions,
and perhaps OpenIndiana installs.

In fact I suspect these systems are perhaps even better,
than the T3640, but overall OpenIndiana runs fine and very stable on the 3640.






___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] problem replacing a disk by a bigger one

2022-06-27 Thread Gary Mills
On Mon, Jun 27, 2022 at 05:33:45PM +0200, Marc Lobelle wrote:
> 
> My current situation is thus that I booted from the internal disk, attached
> the external one and detached the internal one (at this point everything
> runs fine)
> 
> My two questions are thus:
> 
> 1. Now that I have detached the disk inside the computer, can I still
>reboot with only this disk ?
> 2. Do I have to change something in the new disk to connect it as sata
>drive rather than as usb drive and boot the system from it ?
> 
> Thanks, I wait for your advice before risking to turn off the notebook

What does "zpool status" show?


-- 
-Gary Mills--refurb--Winnipeg, Manitoba, Canada-

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] problem replacing a disk by a bigger one

2022-06-27 Thread Marc Lobelle

Hello

Thanks for your help._/I also found a good step by step guide at 
https://omnios.org/info/migrate_rpool. /_(There are other ones, but over 
10 years old) The only change I had to make was using the guid for the 
source disk and the complete real path name to the new device ( even 
/dev/dsk/..., which is a symlink did not work) in zpool attach. The need 
to use the GUID is a known old  bug that was supposed to have been 
fixed. I do not know why I had the use the full pathname of the new 
disk. Maybe it is due to the fact that the new disk was connected to a 
usb adaptor.


However my bios could not boot from this usb disk, so I rebooted the old 
internal disk and I detached it and now the notebook runs on the 
external disk.


Of course, my aim is to put the new inside the notebook at the place 
where the old one was.


I assume that there are probably things to change in the new disk before 
putting it in the notebook.


Besides, now that the old internal disk has been detached, can I still 
reboot the computer if I let it in place and reboot without the external 
disk.


My current situation is thus that I booted from the internal disk, 
attached the external one and detached the internal one (at this point 
everything runs fine)


My two questions are thus:

1. Now that I have detached the disk inside the computer, can I still
   reboot with only this disk ?
2. Do I have to change something in the new disk to connect it as sata
   drive rather than as usb drive and boot the system from it ?

Thanks, I wait for your advice before risking to turn off the notebook

Best regards

Marc


On 6/26/22 23:46, Marc Lobelle wrote:

Hello

In tried to replace the ssd of my notebook running openindiana (120G) 
by a bigger one (1T).


I first copied the small ssd on the big one: I connected the big disk 
on a usb adapter, ran format to identify the two devices then


dd if=/dev/rdsk/c6t0d0p0 of=/dev/rdsk/c4t0d0p0 bs=2048K

then I replaced the small internal disk by the big one.

However, when booting, I got the following message

   ZFS:i/o error - all block copies unavailable

   ZFS: Can't read MOS of pool rpool

   Can't find /boot/loader

   Can't find /boot/zfsloader

   illumos/x86 boot

   Default: /boot/loader

   boot:

if I type , I get

   Can't find /boot/loader

   illumos/x86 boot

   Default: /boot/loader

   boot:

How can I fix this ? (without reinstalling everything if possible;-) 
(after that I plan of course to grow the fs to the whole disk)


Marc
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] problem replacing a disk by a bigger one

2022-06-27 Thread Toomas Soome via openindiana-discuss
hi!

Ok, first of all, there is no reason to copy zfs pool with dd. It may or may 
not work. For single disk migration, it is better to use either zpool mirror + 
zpool split, or zfs send, as zfs send or beadm create -p poolname beName. 
please note that beadm create does not mirror everything over - only BE related 
datasets, so you would need to recreate swap/dump and copy over rpool/export 
and whatever else you have there.

Now, you got error about error on reading MOS. This means, you have gptzfsboot 
running in memory, but it is in trouble - MOS is like ufs superblock - if you 
can not read it, the whole pool is not accessible.

Why this does happen? In general, there could be 2 reasons - either we can not 
read the sectors with MOS (physical IO, checksum errors, LBA too large for 
bios), or there is some sort of error and we get wrong pointer from uberblock 
in pool label. 

Wrong pointer *may* happen when pool label copies have different updates and 
most recent update is in last 2 copies of the label (should not happen with 
clean shutdown), and we fail to access those 2 last copies (they are stored at 
the end of the pool).

Please note, zfs mirror and dd only can work with same sector size disks 
(apparently your old disk has 512B). The BIOS boot only does support 512B 
sector size, for 4kn you need UEFI boot and zfs send/beadm create, as you need 
to create new pool.

I guess this is pretty much all I can add based on the information below.

thope this helps,
toomas

> On 27. Jun 2022, at 10:00, Guenther Alka  wrote:
> 
> If you want to replace the bootdisk the easiest disaster recovery method is 
> to zfs send the current BE to your datapool, then do a clean install of OI to 
> a new disk, send the BE back, activate then boot into the old BE.
> 
> For a non boot disk (with rpool) do a zpool replace poolname olddisk newdisk.
> 
> With an ongoing sync of the BE via incremental zfs send you always have an up 
> to date BE copy for recovery.
> 
> 
> Gea
> 
> Am 26.06.2022 um 23:52 schrieb Judah Richardson:
>> IIRC dd doesn't work reliably for ZFS.
>> 
>> I tried (& failed, possibly due to a bad source disk) to do this
>> previously, but I think you have to ZFS send all the datasets in the source
>> disk to the destination & then possibly do some beadm stuff on the target
>> disk.
>> 
>> Or do a default installation on the new disk, then ZFS send the
>> non-bootloader datasets from the old disk to the new.
>> 
>> 
>> On Sun, Jun 26, 2022, 16:46 Marc Lobelle  wrote:
>> 
>>> Hello
>>> 
>>> In tried to replace the ssd of my notebook running openindiana (120G) by
>>> a bigger one (1T).
>>> 
>>> I first copied the small ssd on the big one: I connected the big disk on
>>> a usb adapter, ran format to identify the two devices then
>>> 
>>> dd if=/dev/rdsk/c6t0d0p0 of=/dev/rdsk/c4t0d0p0 bs=2048K
>>> 
>>> then I replaced the small internal disk by the big one.
>>> 
>>> However, when booting, I got the following message
>>> 
>>> ZFS:i/o error - all block copies unavailable
>>> 
>>> ZFS: Can't read MOS of pool rpool
>>> 
>>> Can't find /boot/loader
>>> 
>>> Can't find /boot/zfsloader
>>> 
>>> illumos/x86 boot
>>> 
>>> Default: /boot/loader
>>> 
>>> boot:
>>> 
>>> if I type , I get
>>> 
>>> Can't find /boot/loader
>>> 
>>> illumos/x86 boot
>>> 
>>> Default: /boot/loader
>>> 
>>> boot:
>>> 
>>> How can I fix this ? (without reinstalling everything if possible;-)
>>> (after that I plan of course to grow the fs to the whole disk)
>>> 
> 
> 
> ___
> openindiana-discuss mailing list
> openindiana-discuss@openindiana.org
> https://openindiana.org/mailman/listinfo/openindiana-discuss


___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] problem replacing a disk by a bigger one

2022-06-27 Thread Guenther Alka
If you want to replace the bootdisk the easiest disaster recovery method 
is to zfs send the current BE to your datapool, then do a clean install 
of OI to a new disk, send the BE back, activate then boot into the old BE.


For a non boot disk (with rpool) do a zpool replace poolname olddisk 
newdisk.


With an ongoing sync of the BE via incremental zfs send you always have 
an up to date BE copy for recovery.



Gea

Am 26.06.2022 um 23:52 schrieb Judah Richardson:

IIRC dd doesn't work reliably for ZFS.

I tried (& failed, possibly due to a bad source disk) to do this
previously, but I think you have to ZFS send all the datasets in the source
disk to the destination & then possibly do some beadm stuff on the target
disk.

Or do a default installation on the new disk, then ZFS send the
non-bootloader datasets from the old disk to the new.


On Sun, Jun 26, 2022, 16:46 Marc Lobelle  wrote:


Hello

In tried to replace the ssd of my notebook running openindiana (120G) by
a bigger one (1T).

I first copied the small ssd on the big one: I connected the big disk on
a usb adapter, ran format to identify the two devices then

dd if=/dev/rdsk/c6t0d0p0 of=/dev/rdsk/c4t0d0p0 bs=2048K

then I replaced the small internal disk by the big one.

However, when booting, I got the following message

 ZFS:i/o error - all block copies unavailable

 ZFS: Can't read MOS of pool rpool

 Can't find /boot/loader

 Can't find /boot/zfsloader

 illumos/x86 boot

 Default: /boot/loader

 boot:

if I type , I get

 Can't find /boot/loader

 illumos/x86 boot

 Default: /boot/loader

 boot:

How can I fix this ? (without reinstalling everything if possible;-)
(after that I plan of course to grow the fs to the whole disk)




___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss