Re: Managed to mess up the system encrypted disk. I can no longer boot.
lun., 8 mar. 2021, 15:06 Marcus MERIGHI a scris: > Hello Samarul, > > > > Today I stumbled again on the same error, but in a different situation, > > let's say. > [...] > > 1. attach an encrypted disk (partition) with an OpenBSD installation on > > it, let's say sd1a --- "bioctl -c C -l sd1a softraid0" --- you will get > > the new sd2 > > 2. detach the sd2 "bioctl -d sd2" > > 3. The OpenBSD will no longer boot. > > No mount(8) and umount(8) between step 1 and 2? > > Marcus > I don't think that mount is important in this case. The culprit is bioctl. Eduard >
Re: Managed to mess up the system encrypted disk. I can no longer boot.
Hello Samarul, samarul@gmail.com (Samarul Meu), 2021.03.08 (Mon) 10:46 (CET): > On Thu, Jan 28, 2021 at 10:27 AM Samarul Meu wrote: > > Thank you so much! You made my day! > > So I used FuguIta (6.8 - stable) attached the encrypted partition > > (accessible as sd1 now) and 'installboot sd1', reboot and surprise - > > everything is working. I still have no idea why detaching the softraid > > determined this kind of behavior. > > Today I stumbled again on the same error, but in a different situation, > let's say. [...] > 1. attach an encrypted disk (partition) with an OpenBSD installation on > it, let's say sd1a --- "bioctl -c C -l sd1a softraid0" --- you will get > the new sd2 > 2. detach the sd2 "bioctl -d sd2" > 3. The OpenBSD will no longer boot. No mount(8) and umount(8) between step 1 and 2? Marcus
Re: Managed to mess up the system encrypted disk. I can no longer boot.
On Thu, Jan 28, 2021 at 10:27 AM Samarul Meu wrote: > > Thank you so much! You made my day! > So I used FuguIta (6.8 - stable) attached the encrypted partition > (accessible as sd1 now) and 'installboot sd1', reboot and surprise - > everything is working. I still have no idea why detaching the softraid > determined this kind of behavior. > Today I stumbled again on the same error, but in a different situation, let's say. I have installed OpenBSD 6.8 on a USB disk as a portable solution (full disk encryption). At work I also have the same 6.8 installed on a computer (on an encrypted partition). I booted the new USB install, I mounted the partition from the computer to copy some settings and then detached the device. At home I mounted the encrypted USB disk on my laptop and copied something from it. Detached the device and all seemed OK. But today, boy, I was for a surprise. The USB disk and the computer OpenBSD installations were not booting. The same error as before open(hd0a:/etc/boot.conf): Invalid argument boot> cannot open hd0a:/etc/random.seed: Invalid argument booting hd0a:/bsd: open hd0a:/bsd: Invalid argument failed(22). will try /bsd For the moment I did not understand what was happening. I tried again boot> boot sr0a:/bsd, but after a false start the system hanged. So the solution 'installboot sd2' (where sd2 is the attached encrypted partition) and now both installed boot normally. As I am a newbie in the OpenBSD environment I do not know if I should report this as a bug of bioctl or not. The error I encounter is easy to reproduce: 1. attach an encrypted disk (partition) with an OpenBSD installation on it, let's say sd1a --- "bioctl -c C -l sd1a softraid0" --- you will get the new sd2 2. detach the sd2 "bioctl -d sd2" 3. The OpenBSD will no longer boot. Thank you very much for your time!
Re: Managed to mess up the system encrypted disk. I can no longer boot.
On Thu, Jan 28, 2021 at 10:27:47AM +0200, Samarul Meu wrote: Thank you so much! You made my day! So I used FuguIta (6.8 - stable) attached the encrypted partition (accessible as sd1 now) and 'installboot sd1', reboot and surprise - everything is working. I still have no idea why detaching the softraid determined this kind of behavior. Best regards, Samarul P.S. To tetrahedra --- maybe this solution will solve your problem also. Unfortunately not... I will explain what I tried over in that thread.
Re: Managed to mess up the system encrypted disk. I can no longer boot.
On Wed, Jan 27, 2021 at 11:12 PM vejetaryenvampir wrote: > I think I was having the same problem when I changed the passphrase > of my disk. I managed to fix it with installboot(8). You can > access the bug report in here: > https://marc.info/?l=openbsd-bugs=161075212820257=2 > I had the panic with the 6.8-stable device, but the 6.8-current device > was booting just fine. In fact, I've used installboot(8) on that device > while it was running (booted by hand with sr0a:/bsd as you did). > > Sincerely, > vejetaryenvampir > Thank you so much! You made my day! So I used FuguIta (6.8 - stable) attached the encrypted partition (accessible as sd1 now) and 'installboot sd1', reboot and surprise - everything is working. I still have no idea why detaching the softraid determined this kind of behavior. Best regards, Samarul P.S. To tetrahedra --- maybe this solution will solve your problem also.
Re: Managed to mess up the system encrypted disk. I can no longer boot.
On Thu, Jan 28, 2021 at 4:38 AM Nick Holland wrote: > -a at the boot prompt is my thought, too...but the little bit of your > dmesg that you show seems to indicate you are not seeing the encrypted > drive handled by in softraid at all. So I have my concerns this won't > do much but delay the panic (the kernel's panic. Too late for your > panic, I'm sure). > I tried booting using -a or -s, but I have no luck. When I use -a it gets to the moment where it asks for the root device but the keyboard is dead, I can't do anything. And when using -s it just hangs with the previous panic message. > > If this doesn't work for you, I'd start by booting off a bsd.rd (USB, > CDROM, network, whatever) and looking around a bit. What does the > fdisk of your physical drive look like? Is your OpenBSD partition > still there? If not, recreate it (hopefully you either used the > defaults or remember what you did). All that really matters is the > starting sector (probably 64 assuming MBR. UEFI is 1024, iirc, but > I'm too lazy to look this up right now. Dammit, no I'm not, yes, > probably 1024, but I'm DEFINITELY not looking to see if that's a > hard number or if there are things that cause it to move around). > > After the fdisk partitions, look at the disklabel in on the physical > drive -- should be one big RAID partition as 'a' and type RAID. > > I looked at the softraid partition and everything seems fine. As I mentioned I see it as a 'a' RAID partition. Then I do a bioctl on it and I can access it and see al the other partitions 'a-j' . I did an fsck -p on all of them and I get no errors. I even mount them to see if everything is ok and I managed to get the work done in '/home', but that is all. When I reboot nothing works. > I am kinda suspicious that the bioctl command you gave was not the > culprit in this situation, but something else in your script. > > Actually in the moment I was not running the script. I was doing some tests and I could no longer access the sd1 which was used by a previous bioctl attempt. So i tried to do a 'bioctl -d', but by mistake instead of sd1 I did it on sd0. All froze and I had to do a hard reset. > As for safeguards...Well, from personal experience recently, I can > *assure* you I understand the first response when something goes > horribly wrong and your finger is the one on the (virtual) trigger > is, "Why wasn't there a safeguard??". I get that, and I bet mine > was a bigger oops than yours. But realistically, there are an > almost unlimited number of ways to hurt yourself, and a much smaller > number of ways to do things right, and often what to person A is > a horrible mistake, person B needs as a way to solve a big problem. > I have often needed to use an OS like OpenBSD to clean up messes in > other OSs because the safeguards in the other OS prevented me from > doing what I needed to do. So yes, I understand, but no, I don't > want a "are you sure?" on every step of everything that could cause > an "event". > > I understand the point and maybe it is ok this way. Actually that is why I am creating this scripts --- to check before doing anything that I am not trying to modify the 'root' disk. > And think how much you just learned about the value of good backups... > > I learned this lesson a long time ago, on my beginner Linux years. Now, is just a reminder. Thank for your answer and help and I appreciate any further hints. > Nick. >
Re: Managed to mess up the system encrypted disk. I can no longer boot.
On 1/27/21 1:45 PM, Samarul Meu wrote: mie., 27 ian. 2021, 20:24 a scris: Ironically this is the same error I have been getting, and recently posted about in the thread "Bootloader on USB stick fails with "root device not found"" ... I read your thread just now. I will try the -a option. Interesting, but I must mention that my OpenBSD is installed on an encrypted partition. -a at the boot prompt is my thought, too...but the little bit of your dmesg that you show seems to indicate you are not seeing the encrypted drive handled by in softraid at all. So I have my concerns this won't do much but delay the panic (the kernel's panic. Too late for your panic, I'm sure). If this doesn't work for you, I'd start by booting off a bsd.rd (USB, CDROM, network, whatever) and looking around a bit. What does the fdisk of your physical drive look like? Is your OpenBSD partition still there? If not, recreate it (hopefully you either used the defaults or remember what you did). All that really matters is the starting sector (probably 64 assuming MBR. UEFI is 1024, iirc, but I'm too lazy to look this up right now. Dammit, no I'm not, yes, probably 1024, but I'm DEFINITELY not looking to see if that's a hard number or if there are things that cause it to move around). After the fdisk partitions, look at the disklabel in on the physical drive -- should be one big RAID partition as 'a' and type RAID. I am kinda suspicious that the bioctl command you gave was not the culprit in this situation, but something else in your script. As for safeguards...Well, from personal experience recently, I can *assure* you I understand the first response when something goes horribly wrong and your finger is the one on the (virtual) trigger is, "Why wasn't there a safeguard??". I get that, and I bet mine was a bigger oops than yours. But realistically, there are an almost unlimited number of ways to hurt yourself, and a much smaller number of ways to do things right, and often what to person A is a horrible mistake, person B needs as a way to solve a big problem. I have often needed to use an OS like OpenBSD to clean up messes in other OSs because the safeguards in the other OS prevented me from doing what I needed to do. So yes, I understand, but no, I don't want a "are you sure?" on every step of everything that could cause an "event". And think how much you just learned about the value of good backups... Nick.
Re: Managed to mess up the system encrypted disk. I can no longer boot.
On Wed, Jan 27, 2021 at 05:50:07PM +0200, Samarul Meu wrote:
After searching online I discovered this: boot sr0a:/bsd. Now it asks
for
my Passphrase and it starts booting but then it hangs
softraid0 at root
scsibus2 at softraid0: 256 targets
panic: root device (3312a...) not found
Stopped at db_enter+0x10: popq %rbp
TID PID UID PRFLAGS PFLAGS CPU COMMAND
* 00 0 0x1 0x2000 0kswapper
panic(ff81dff) at panic+0x12a
setroot(80..) at setroot+0xdeb
disconf(1b21..) at diskconf+0x185
main(0,0,0,0,0,80..) at main+0x500
end trace frame: 0x0, count:10https://www.openbsd.org/ddb.html
describes the minimum info required inbug reports. Insufficient
info makes it difficult to find and fix bugs.
ddb{0}>
Using a usb drive with *FuguIta* I managed to do a fsck on all partitions
(some errors appeared, but I cleaned them).
I was even able to mount them and everything seems fine, I recovered what I
was working on, but I have no luck in booting. Again and again the above
error.
Ironically this is the same error I have been getting, and recently
posted about in the thread "Bootloader on USB stick fails with "root
device not found"" ...
Re: Managed to mess up the system encrypted disk. I can no longer boot.
Samarul Meu wrote:
> It showed only this:
>
> open(hd0a:/etc/boot.conf): Invalid argument
> boot>
> cannot open hd0a:/etc/random.seed: Invalid argument
> booting hd0a:/bsd: open hd0a:/bsd: Invalid argument
> failed(22). will try /bsd
>
> After searching online I discovered this: boot sr0a:/bsd. Now it asks for
> my Passphrase and it starts booting but then it hangs
>
> softraid0 at root
> scsibus2 at softraid0: 256 targets
> panic: root device (3312a...) not found
> Stopped at db_enter+0x10: popq %rbp
> TID PID UID PRFLAGS PFLAGS CPU COMMAND
> * 00 0 0x1 0x2000 0kswapper
> panic(ff81dff) at panic+0x12a
> setroot(80..) at setroot+0xdeb
> disconf(1b21..) at diskconf+0x185
> main(0,0,0,0,0,80..) at main+0x500
> end trace frame: 0x0, count:10https://www.openbsd.org/ddb.html
> describes the minimum info required inbug reports. Insufficient
> info makes it difficult to find and fix bugs.
> ddb{0}>
I think I was having the same problem when I changed the passphrase
of my disk. I managed to fix it with installboot(8). You can
access the bug report in here:
https://marc.info/?l=openbsd-bugs=161075212820257=2
I had the panic with the 6.8-stable device, but the 6.8-current device
was booting just fine. In fact, I've used installboot(8) on that device
while it was running (booted by hand with sr0a:/bsd as you did).
Sincerely,
vejetaryenvampir
Re: Managed to mess up the system encrypted disk. I can no longer boot.
On Wed, Jan 27, 2021 at 05:50:07PM +0200, Samarul Meu wrote: > I was playing with some script trying to create an encrypted image and > accidentally I did bioctl -d sd0 where sd0 is the disk with my OpenBSD > install. Of course the system hanged. When I tried to reboot it no longer > ask me for my passphrase. > [...] > Using a usb drive with *FuguIta* I managed to do a fsck on all partitions > (some errors appeared, but I cleaned them). > > I was even able to mount them and everything seems fine, I recovered what I > was working on, but I have no luck in booting. Again and again the above > error. > I am a little puzzled that there is no failsafe mechanism for commands like > bioctl or fdisk on the already mounted disk. For me the obvious think was > that the system complains when trying bioctl -d sd0. Perhaps. But that would require not-trivial WORK, maybe a LOT, which someone would have to DO, probably for FREE. I suspect detaching a running encrypted root disk is somewhat uncharted territory. In a perfect world the same command might've offered a "failsafe" mechanism and performed logout, shutdown, umount and sync and whatnot in the case of an affirmative response, but not in ours. Such a perfect world might not even be preferable given how much added code complexity and size such "failsafe" mechanisms could involve. For now, consider yourself lucky to have recovered your data. That is the most important thing and I'm happy on your behalf to hear that you managed so. Regards
Re: Managed to mess up the system encrypted disk. I can no longer boot.
mie., 27 ian. 2021, 20:24 a scris: > > Ironically this is the same error I have been getting, and recently > posted about in the thread "Bootloader on USB stick fails with "root > device not found"" ... > I read your thread just now. I will try the -a option. Interesting, but I must mention that my OpenBSD is installed on an encrypted partition. >
Re: Managed to mess up the system encrypted disk. I can no longer boot.
Color me surprised...I can't say I've ever tried it to know. Still, rm is a little different to something that's talking directly to a device. On Wed, 27 Jan 2021 at 12:33, Daniel Jakots wrote: > > On Wed, 27 Jan 2021 11:31:13 -0500, Ashton Fagg > wrote: > > > Do you want "rm -rf /" to hold your hand also? > > As a matter of fact, it does :) > https://github.com/openbsd/src/commit/c11d908c7069eb03d103482ce1d0227f3d47b349 >
Re: Managed to mess up the system encrypted disk. I can no longer boot.
On Wed, 27 Jan 2021 11:31:13 -0500, Ashton Fagg wrote: > Do you want "rm -rf /" to hold your hand also? As a matter of fact, it does :) https://github.com/openbsd/src/commit/c11d908c7069eb03d103482ce1d0227f3d47b349
Re: Managed to mess up the system encrypted disk. I can no longer boot.
Pressed send too early. It is also worth pointing out that I'm fairly sure every *nix has similar ways to blow your arms and legs off. There's nothing special about OpenBSD or bioctl in that sense. On Wed, 27 Jan 2021 at 11:31, Ashton Fagg wrote: > > On Wed, 27 Jan 2021 at 10:55, Samarul Meu wrote: > > > > I am a little puzzled that there is no failsafe mechanism for commands like > > bioctl or fdisk on the already mounted disk. For me the obvious think was > > that the system complains when trying bioctl -d sd0. > > To be fair, bioctl talks to block I/O devices (i.e. nothing to do with > filesystems). So it is hardly surprising that this can happen > considering that fact. Do you want "rm -rf /" to hold your hand also? > You could also blow away a disk with "dd" if you're not careful - > should that try and preempt you from making a mistake? > > I know that doesn't help you, but I can imagine that's the rationale. > If you want to shoot yourself in the foot, that's just fine.
Re: Managed to mess up the system encrypted disk. I can no longer boot.
On Wed, 27 Jan 2021 at 10:55, Samarul Meu wrote: > > I am a little puzzled that there is no failsafe mechanism for commands like > bioctl or fdisk on the already mounted disk. For me the obvious think was > that the system complains when trying bioctl -d sd0. To be fair, bioctl talks to block I/O devices (i.e. nothing to do with filesystems). So it is hardly surprising that this can happen considering that fact. Do you want "rm -rf /" to hold your hand also? You could also blow away a disk with "dd" if you're not careful - should that try and preempt you from making a mistake? I know that doesn't help you, but I can imagine that's the rationale. If you want to shoot yourself in the foot, that's just fine.
