Re: init (/rescue/sh) died
On Mon, Aug 22, 2022 at 12:29 PM Bjoern A. Zeeb < bzeeb-li...@lists.zabbadoz.net> wrote: > On Mon, 22 Aug 2022, Warner Losh wrote: > > Hi, > > > On Mon, Aug 22, 2022 at 9:17 AM Konstantin Belousov > > > wrote: > > > >> On Mon, Aug 22, 2022 at 02:56:47PM +, Bjoern A. Zeeb wrote: > >>> Hi, > >>> > >>> I am trying to get some arm64 up and running a bit but cannot use > >>> loader. I have an MD_ROOT embedded in the kernel with /rescue on it. > >>> I set INIT_PATH=/rescue/sh . > >>> > >>> However that doesn't seem to work: > >>> > >>> start_init: trying /rescue/sh > >>> init died (signal 0, exit 0) > >>> panic: Going nowhere without my init! > >>> > >>> Anyone any ideas? > >> > >> Kernel does not set up the standard file descriptors for stdin/out/err > >> for init. When you try to directly exec /rescue/sh (or /bin/sh), it > cannot > >> perform any io. > >> > > > > Agreed. init does lots of magic, in addition to setting up stdin/out/err > > (like > > deal with process groups, etc). /bin/sh doesn't do any of that magic, so > it > > can't possibly work as init (PID 1). > > > > Your best bet is to boot -s (RB_SINGLE in the kernel boot_single=yes in > the > > boot loader). You'd think you'd be able to symbolically link /etc/rc to > > /rescue/sh, > > but that will result in sh trying to execute /rescue/sh as a shell script > > and no good > > can come from it. I've had luck with "echo sh > $DESTDIR/etc/rc; > > chmod +x $DESTDIR/etc/rc" in the past, but I haven't tried that trick in > > ages... > > The simple equivalent to a tmp file does work. > > /rescue/init was simply "hanging" on earlier boots which is why I > had initially switche dto sh. > > Here's a few things I did overall: > - disable GDB in kernel config (it gave 2 lines of jitterish on >initial kernel printf lines before Copyrights. > - Added bootargs = FreeBSD:-vs to the chosen section in FDT >given I cannot have loader (no EFI); the guard trick is nice if you >know about it ;) > No EFI doesn't mean you can't have a loader :). What environment are you booting in? Seems interesting... > - Removed my previous env file I had added to the kernel to set >tunables. > - linked /bin/sh to /rescue/sh > - put a printf "hello world\n"; exit 1 in the top of /etc/rc just in >case -s wouldn't work > - changed INIT_PATH=/rescue/init > > Got a sh and can run sysctl and dmesg and type echo * in /rescue :) > Even reboot works :) > > Now that basic netbooting and user space work I can start adding SoC > drivers bit by bit over the next weeks/months :) That'll be a lot > more unfun. > > Thanks you two! Along with help from Andy earlier this made my day! > Glad I could help... Warner
Re: init (/rescue/sh) died
On Mon, 22 Aug 2022, Warner Losh wrote: Hi, On Mon, Aug 22, 2022 at 9:17 AM Konstantin Belousov wrote: On Mon, Aug 22, 2022 at 02:56:47PM +, Bjoern A. Zeeb wrote: Hi, I am trying to get some arm64 up and running a bit but cannot use loader. I have an MD_ROOT embedded in the kernel with /rescue on it. I set INIT_PATH=/rescue/sh . However that doesn't seem to work: start_init: trying /rescue/sh init died (signal 0, exit 0) panic: Going nowhere without my init! Anyone any ideas? Kernel does not set up the standard file descriptors for stdin/out/err for init. When you try to directly exec /rescue/sh (or /bin/sh), it cannot perform any io. Agreed. init does lots of magic, in addition to setting up stdin/out/err (like deal with process groups, etc). /bin/sh doesn't do any of that magic, so it can't possibly work as init (PID 1). Your best bet is to boot -s (RB_SINGLE in the kernel boot_single=yes in the boot loader). You'd think you'd be able to symbolically link /etc/rc to /rescue/sh, but that will result in sh trying to execute /rescue/sh as a shell script and no good can come from it. I've had luck with "echo sh > $DESTDIR/etc/rc; chmod +x $DESTDIR/etc/rc" in the past, but I haven't tried that trick in ages... The simple equivalent to a tmp file does work. /rescue/init was simply "hanging" on earlier boots which is why I had initially switche dto sh. Here's a few things I did overall: - disable GDB in kernel config (it gave 2 lines of jitterish on initial kernel printf lines before Copyrights. - Added bootargs = FreeBSD:-vs to the chosen section in FDT given I cannot have loader (no EFI); the guard trick is nice if you know about it ;) - Removed my previous env file I had added to the kernel to set tunables. - linked /bin/sh to /rescue/sh - put a printf "hello world\n"; exit 1 in the top of /etc/rc just in case -s wouldn't work - changed INIT_PATH=/rescue/init Got a sh and can run sysctl and dmesg and type echo * in /rescue :) Even reboot works :) Now that basic netbooting and user space work I can start adding SoC drivers bit by bit over the next weeks/months :) That'll be a lot more unfun. Thanks you two! Along with help from Andy earlier this made my day! Lots of joy! /bz -- Bjoern A. Zeeb r15:7
Re: Beadm can't create snapshot
On 2022-08-22 12:29, Peter Jeremy wrote: On 2022-Aug-22 10:56:51 +0200, "Patrick M. Hausen" wrote: Am 22.08.2022 um 10:45 schrieb Peter Jeremy : On 2022-Aug-17 18:07:20 +0200, "Patrick M. Hausen" wrote: Isn't beadm retired in favour of bectl? 2) "bectl activate" doesn't update /boot/loader.conf so the wrong root filesystem is mounted. You mean the vfs.root.mountfrom option? I thought that, too, was deprecated and replaced by the bootfs property of the zpool. I've looking through mailing list archives and searched the 'net and haven't found anything saying vfs.root.mountfrom is deprecated. loader(8) mentions that it will fallback to using "currdev" if there's no root entry in /etc/fstab and vfs.root.mountfrom isn't set. It's not deprecated, but it's a manual override of a _normal_ ZFS boot flow. If you mount root via fstab or you override it via vfs.root.mountfrom, then you should know what you do and why. At the very least, it's an undocumented incompatibility between beadm and bectl: I can't take an existing system that's using beadm and just switch to using bectl. Yeah, but I would blame beadm for doing things in a backwards fashion. -- Andriy Gapon https://standforukraine.com https://razomforukraine.org
Re: init (/rescue/sh) died
On Mon, Aug 22, 2022 at 9:17 AM Konstantin Belousov wrote: > On Mon, Aug 22, 2022 at 02:56:47PM +, Bjoern A. Zeeb wrote: > > Hi, > > > > I am trying to get some arm64 up and running a bit but cannot use > > loader. I have an MD_ROOT embedded in the kernel with /rescue on it. > > I set INIT_PATH=/rescue/sh . > > > > However that doesn't seem to work: > > > > start_init: trying /rescue/sh > > init died (signal 0, exit 0) > > panic: Going nowhere without my init! > > > > Anyone any ideas? > > Kernel does not set up the standard file descriptors for stdin/out/err > for init. When you try to directly exec /rescue/sh (or /bin/sh), it cannot > perform any io. > Agreed. init does lots of magic, in addition to setting up stdin/out/err (like deal with process groups, etc). /bin/sh doesn't do any of that magic, so it can't possibly work as init (PID 1). Your best bet is to boot -s (RB_SINGLE in the kernel boot_single=yes in the boot loader). You'd think you'd be able to symbolically link /etc/rc to /rescue/sh, but that will result in sh trying to execute /rescue/sh as a shell script and no good can come from it. I've had luck with "echo sh > $DESTDIR/etc/rc; chmod +x $DESTDIR/etc/rc" in the past, but I haven't tried that trick in ages... The simple equivalent to a tmp file does work. Warner
Re: init (/rescue/sh) died
On Mon, Aug 22, 2022 at 02:56:47PM +, Bjoern A. Zeeb wrote: > Hi, > > I am trying to get some arm64 up and running a bit but cannot use > loader. I have an MD_ROOT embedded in the kernel with /rescue on it. > I set INIT_PATH=/rescue/sh . > > However that doesn't seem to work: > > start_init: trying /rescue/sh > init died (signal 0, exit 0) > panic: Going nowhere without my init! > > Anyone any ideas? Kernel does not set up the standard file descriptors for stdin/out/err for init. When you try to directly exec /rescue/sh (or /bin/sh), it cannot perform any io.
Re: Beadm can't create snapshot
On Mon, Aug 22, 2022 at 5:10 AM Ronald Klop wrote: > > > > Van: Peter Jeremy > Datum: maandag, 22 augustus 2022 10:45 > Aan: "Patrick M. Hausen" > CC: Ryan Moeller , freebsd-current@freebsd.org > Onderwerp: Re: Beadm can't create snapshot > > On 2022-Aug-17 18:07:20 +0200, "Patrick M. Hausen" wrote: > >Isn't beadm retired in favour of bectl? > > bectl still has a number of bugs: > 1) The output from "bectl list" is in filesystem/bename order rather >than creation date order. This is an issue if you use (eg) git >commit hashes as the name. > 2) "bectl activate" doesn't update /boot/loader.conf so the wrong >root filesystem is mounted. > > That said "bectl create" appears to be a workable replacement for > "beadm create" and avoids the current "'snapshots_changed' is > readonly" bugs. > > -- > Peter Jeremy > > > > > > Hi, > > From man bectl: > activate [-t | -T] beName >Activate the given beName as the default boot filesystem. If >the -t flag is given, this takes effect only for the next boot. >Flag -T removes temporary boot once configuration. Without >temporary configuration, the next boot will use zfs dataset >specified in boot pool bootfs property. > > So it uses the bootfs property instead of loader.conf. If beadm used a > different mechaniscm it would by nice to mention that in the HISTORY section > of the bectl man page. > I was not aware that beadm touches loader.conf, but I find that slightly horrifying. I won't personally make bectl do that, but I guess I could at least document that it doesn't...
init (/rescue/sh) died
Hi, I am trying to get some arm64 up and running a bit but cannot use loader. I have an MD_ROOT embedded in the kernel with /rescue on it. I set INIT_PATH=/rescue/sh . However that doesn't seem to work: start_init: trying /rescue/sh init died (signal 0, exit 0) panic: Going nowhere without my init! Anyone any ideas? /bz -- Bjoern A. Zeeb r15:7
Re: Beadm can't create snapshot
Van: Peter Jeremy Datum: maandag, 22 augustus 2022 10:45 Aan: "Patrick M. Hausen" CC: Ryan Moeller , freebsd-current@freebsd.org Onderwerp: Re: Beadm can't create snapshot On 2022-Aug-17 18:07:20 +0200, "Patrick M. Hausen" wrote: >Isn't beadm retired in favour of bectl? bectl still has a number of bugs: 1) The output from "bectl list" is in filesystem/bename order rather than creation date order. This is an issue if you use (eg) git commit hashes as the name. 2) "bectl activate" doesn't update /boot/loader.conf so the wrong root filesystem is mounted. That said "bectl create" appears to be a workable replacement for "beadm create" and avoids the current "'snapshots_changed' is readonly" bugs. -- Peter Jeremy Hi, From man bectl: activate [-t | -T] beName Activate the given beName as the default boot filesystem. If the -t flag is given, this takes effect only for the next boot. Flag -T removes temporary boot once configuration. Without temporary configuration, the next boot will use zfs dataset specified in boot pool bootfs property. So it uses the bootfs property instead of loader.conf. If beadm used a different mechaniscm it would by nice to mention that in the HISTORY section of the bectl man page. Regards, Ronald.
BitchX segfault in libc.so.7
hi All I know this is not the ports list , but the problem only happens in CURRENT anyway BitchX from ports (at least for me and i've installed freebsd current several times here with the same result) uses CC to compile and in freebsd CURRENT its getting segfault as soon as BitchX connects to any network. I tracked the core on debugger and the fault always happens on libc7 Now using the same source code downloaded in work/ dir in ports, if you use GCC then it works just fine, which is what i did here with my own BitchX just a heads up for the ports guys thanks --tzk
Re: kernel panic during zfs pool import
Still the same with current.(from today). Opening a PR for it.. Santi On 8/22/22 10:43, Santiago Martinez wrote: Thanks Toommas, I compiling current right now and will give it a try, hopefully, will be able to mount and recover the machine. Will also open a PR as even if the is any corruption/pool damage it should not panic the machine. Santi On 8/18/22 21:45, Toomas Soome wrote: On 18. Aug 2022, at 18:46, Santiago Martinez wrote: Hi everyone, I have a server running 13.1-stable that was powered off (gracefully) and now is been powered on again and we have the following problem. The server boots almost properly, kernel load and when zfs import other pools it panic with the following message. "panic : Solaris (panic) zfs: adding existent segment to range tree (offset=4af2ca9000 size=a)". if i boot into single user and the pools (most specifically pool01 ) is not imported then there is no panic. but as soon as we try to import pool01 we get that panic error. it worth mentioning that the pool imported/online before. Have two question: * How i can tell to not import the pool automatically during boot so sever is not stuck in a boot/panic/reboot infinite loop? removing zpool.cache should do. unfortunately, you would need to boot alternate root (usb/cd/net) for that. * Anybody know what this panic means? in short - bug. I’d try to boot current and import pool there - maybe the issue is fixed in current… rgds, toomas Thanks in advance! Santi
Re: Beadm can't create snapshot
On 2022-Aug-22 10:56:51 +0200, "Patrick M. Hausen" wrote: >> Am 22.08.2022 um 10:45 schrieb Peter Jeremy : >> On 2022-Aug-17 18:07:20 +0200, "Patrick M. Hausen" wrote: >>> Isn't beadm retired in favour of bectl? >> >> 2) "bectl activate" doesn't update /boot/loader.conf so the wrong >> root filesystem is mounted. > >You mean the vfs.root.mountfrom option? I thought that, too, was deprecated and >replaced by the bootfs property of the zpool. I've looking through mailing list archives and searched the 'net and haven't found anything saying vfs.root.mountfrom is deprecated. loader(8) mentions that it will fallback to using "currdev" if there's no root entry in /etc/fstab and vfs.root.mountfrom isn't set. At the very least, it's an undocumented incompatibility between beadm and bectl: I can't take an existing system that's using beadm and just switch to using bectl. -- Peter Jeremy signature.asc Description: PGP signature
Re: Beadm can't create snapshot
Hi, > Am 22.08.2022 um 10:45 schrieb Peter Jeremy : > > On 2022-Aug-17 18:07:20 +0200, "Patrick M. Hausen" wrote: >> Isn't beadm retired in favour of bectl? > > bectl still has a number of bugs: > 1) The output from "bectl list" is in filesystem/bename order rather > than creation date order. This is an issue if you use (eg) git > commit hashes as the name. > 2) "bectl activate" doesn't update /boot/loader.conf so the wrong > root filesystem is mounted. You mean the vfs.root.mountfrom option? I thought that, too, was deprecated and replaced by the bootfs property of the zpool. I don't have vfs.root.mountfrom anywhere and bectl sets the active BE just as expected. The bootfs property changes accordingly. Kind regards, Patrick
Re: Beadm can't create snapshot
On 2022-Aug-17 18:07:20 +0200, "Patrick M. Hausen" wrote: >Isn't beadm retired in favour of bectl? bectl still has a number of bugs: 1) The output from "bectl list" is in filesystem/bename order rather than creation date order. This is an issue if you use (eg) git commit hashes as the name. 2) "bectl activate" doesn't update /boot/loader.conf so the wrong root filesystem is mounted. That said "bectl create" appears to be a workable replacement for "beadm create" and avoids the current "'snapshots_changed' is readonly" bugs. -- Peter Jeremy signature.asc Description: PGP signature
Re: kernel panic during zfs pool import
Thanks Toommas, I compiling current right now and will give it a try, hopefully, will be able to mount and recover the machine. Will also open a PR as even if the is any corruption/pool damage it should not panic the machine. Santi On 8/18/22 21:45, Toomas Soome wrote: On 18. Aug 2022, at 18:46, Santiago Martinez wrote: Hi everyone, I have a server running 13.1-stable that was powered off (gracefully) and now is been powered on again and we have the following problem. The server boots almost properly, kernel load and when zfs import other pools it panic with the following message. "panic : Solaris (panic) zfs: adding existent segment to range tree (offset=4af2ca9000 size=a)". if i boot into single user and the pools (most specifically pool01 ) is not imported then there is no panic. but as soon as we try to import pool01 we get that panic error. it worth mentioning that the pool imported/online before. Have two question: * How i can tell to not import the pool automatically during boot so sever is not stuck in a boot/panic/reboot infinite loop? removing zpool.cache should do. unfortunately, you would need to boot alternate root (usb/cd/net) for that. * Anybody know what this panic means? in short - bug. I’d try to boot current and import pool there - maybe the issue is fixed in current… rgds, toomas Thanks in advance! Santi
