Re: [9fans] The lost (9front) boot menus ...
yes, patches are welcome. if you prefer longer timeout, you know what code to change now. -- cinap
Re: [9fans] The lost (9front) boot menus ...
hell. i have to do *exactly* the same with same dimension of timeouts slightly earlier for my bios to be allowed to select my boot disk, too. it's a totally common mechanism. windows bootloader also always had that behavior for their recovery/boot menus, just that you have to be more careful actually, to use the correct key.
Re: [9fans] The lost (9front) boot menus ...
it doesn't matter how old you are cause you need no low reaction time here, you can just start mashing a key multiple times per second, starting slightly earlier than the prompts would appear
Re: [9fans] The lost (9front) boot menus ...
> I object to quadrupling the timeout. I am old and my eyesight sucks and > one second is perfectly sane. Shut the refrigerator door! You're running up long distance charges!!!
Re: [9fans] The lost (9front) boot menus ...
On Fri, Apr 19, 2019 at 05:33:07PM -0700, Lyndon Nerenberg wrote: > > How about a FOUR second timeout, and some manpage patches? > I object to quadrupling the timeout. I am old and my eyesight sucks and one second is perfectly sane. khm
Re: [9fans] The lost (9front) boot menus ...
cinap_len...@felloff.net writes: > err... thats precisely how it works. the ONLY difference is that the > timeout is hardcoded to ONE second see: /sys/src/boot/pc/sub.c:304 Fine, but a ONE second timeout is insane. And it's NOT at all clearly documented in the 9boot(8) manpage. How about a FOUR second timeout, and some manpage patches?
Re: [9fans] The lost (9front) boot menus ...
> err... thats precisely how it works. the ONLY difference is that the > timeout is hardcoded to ONE second see: /sys/src/boot/pc/sub.c:304 ONE second, eh? I need to become much younger again ;-)
Re: [9fans] The lost (9front) boot menus ...
> Given a working fileserver config, I want something that does > 'user=foo; nobootpromt=bar', but with a (say) five second timeout. > This is different from the current scheme that provides an escape, > but which requires manual intervention. What I'm looking for is a > timed-out option from the 'nobootprompt=' config, that lets me > override, but only if I'm right there. > It's the same as how (e.g. FreeBSD) lets you interrupt the boot > process and muck about. But if you don't, it times out and boots > the 'default' configuration. err... thats precisely how it works. the ONLY difference is that the timeout is hardcoded to ONE second see: /sys/src/boot/pc/sub.c:304 so your plan9.ini is the default config. and you hit any key during that timeout window, you get to the bootloader console where you can edit the plan9.ini variables (in ram). you can remove variables with the clear command, so you can get rid of nobootprompt. its all documented in 9boot(8). -- cinap
Re: [9fans] The lost (9front) boot menus ...
cinap_len...@felloff.net writes: > the bootloader has a console where you can change any > plan9.ini parameter, including bootfile=. read 9boot(8). I described this badly. Let me try again. Given a working fileserver config, I want something that does 'user=foo; nobootpromt=bar', but with a (say) five second timeout. This is different from the current scheme that provides an escape, but which requires manual intervention. What I'm looking for is a timed-out option from the 'nobootprompt=' config, that lets me override, but only if I'm right there. It's the same as how (e.g. FreeBSD) lets you interrupt the boot process and muck about. But if you don't, it times out and boots the 'default' configuration.
Re: [9fans] The lost (9front) boot menus ...
the bootloader has a console where you can change any plan9.ini parameter, including bootfile=. read 9boot(8). if you really want menus in the bootloader, you can also load the kernel directly with some other multiboot capable bootloader. or you start the kernel from another kernel using the reboot!kernelpath!method... on the bootargs prompt. -- cinap
Re: [9fans] The lost (9front) boot menus ...
there's always the GRand Unified Bootloader. On Fri, Apr 19, 2019 at 3:16 PM Lyndon Nerenberg wrote: > > Something I miss in 9front is the 'boot menu' functionality 9labs > had in plan9.ini. Being able to fall back to an alternative config > was a godsend when debugging fileserver setups. I'm curious why > that was removed from the 9front bootstrap code. > > --lyndon >
[9fans] The lost (9front) boot menus ...
Something I miss in 9front is the 'boot menu' functionality 9labs had in plan9.ini. Being able to fall back to an alternative config was a godsend when debugging fileserver setups. I'm curious why that was removed from the 9front bootstrap code. --lyndon
Re: [9fans] 9front dhcpd installer buglet
noted. its missing in the proto file. -- cinap
[9fans] 9front dhcpd installer buglet
The 9front installer doesn't create the /lib/ndb/dhcp directory. This makes ip/dhcpd silently fail when it tries to hand out dynamic addresses.
Re: [9fans] SMC SYS-5018A-FTN4 lapic weirdness (9front)
Hi. I get the exact same error every time I (in|de)crease the backlight brightness in the x220. On Thu, Apr 18, 2019, 3:49 AM Lyndon Nerenberg wrote: > I have a stack of Supermicro SYS-5018A-FTN4 servers upon which I'm trying > to > spin up 9front. > > For the most part they work, but one annoyance is the *endless* stream of > > cpu0: lapicerror: 0x0080 > > messages the kernel prints out. Sometimes these originate from cpu1 as > well. > The hardware has eight CPU cores. I don't think I've seen anything from > cpu>1, but in the blizzard of messages, who knows. > > I poked a wee bit inside the kernel source, but I don't have time right now > to chase this. The hardware runs fine, other than refusing to reboot, > which > I put down to the usual BIOS ACPI table stupidity. > > For the time being I'm going to put a filter on the kprints, but I'm > curious > if this sounds familiar to anyone. > > Note this happens with both the 32- and 64-bit kernels. > > I don't have a quick way to attach sysinfo(1) to this message, but if > somebody > can use that I'll figure something out. > > --lyndon > >
