On Fri, Oct 02, 2015 at 01:43:11PM +0200, Holger Sebert wrote:
> X-Mailer: iPhone Mail (11D257)
>
> unsubscribe
>
hahaha
[-- Attachment #1: Type: text/plain, Size: 273 bytes --] Guys, read the tin: http://lists.9front.org sl On Oct 2, 2015, 10:32 AM, at 10:32 AM, Kurt H Maier <khm@sciops.net> wrote: >On Fri, Oct 02, 2015 at 01:43:11PM +0200, Holger Sebert wrote: >> X-Mailer: iPhone Mail (11D257) >> >> unsubscribe >> > >hahaha [-- Attachment #2: Type: text/html, Size: 216 bytes --]
nice! :-) i like the back picture :-) -- cinap
> 9FRONT "CONTENTS, MAINTAINED, STABLE" RELEASED
> ==============================================
Thank you very much this release!
Now
(1) I can use sandy bridge (Dell desktop) machine without any problem
up tp 1920x1200x32 resolution.
(2) Now I don't need nupas, the generic upas now has its functionarity.
Now I'm wrinting this mail by the new upas program.
Kenji
On Wed, Jun 06, 2018 at 03:30:13PM +0300, Stanislav Paskalev wrote:
> unsubscribe
if you send this message to 9front-owner@9front.org it might even work
khm
Hi, This is not quite how I have it set up but I think this is probably the way to go: Have each mail box, /mail/box/$user/mbox, be owned by upas, with the group set to $user and the mode set to 0770. Then run your upas/smtpd listener as upas. This will allow upas access to all mail boxes, but each user will only have access to their own. Files created by upas in the mailboxes will be owned by upas and the group will be inherited from the parent directory. Note, however, that there is a bug in hjfs(4) which means this last part won't work. I already have a patch for this; I'll send it to the list now. -- Cheers, Alex Musolino
> Note, however, that there is a bug in hjfs(4) which means this last
> part won't work. I already have a patch for this; I'll send it to the
> list now.
Thanks! I didn't realise that the fact I'd switched to hjfs might be relevant
but that is clearly why it worked before and why I am tearing my hair out now.
Will someone commit the patch?
umbraticus
unsubscribe
It won't be that easy, my friend.
On Sat, Jan 23, 2021 at 3:28 AM Марко М. Костић
<marko.m.kostic@gmail.com> wrote:
>
> unsubscribe
--
Tanami Muller
Chief Technology Officer
Email: tanami@oneworldled.com
Mobile: 0450 107 311
Office: (08) 8374 4557
Address: 1024 South Road, Edwardstown
Polo
On Fri, Jan 22, 2021 at 11:58 AM Марко М. Костић
<marko.m.kostic@gmail.com> wrote:
>
> unsubscribe
One does not simply unsubscribe from 9front.
send an e-mail message to 9front-owner@9front.org, this time containing, on a single line, the unsubscribe command.
Subect: state of emmc and usb on pi400 and cm4 Hola, I'm in preparation for a new 9front release, fixing penting issues. I have confirmation that the XHCI (USB3) works now on the pi400, but there are still issues with the sdcard. On the CM4, we have to enable the usbdwc driver (as it does not have the xhci controller chip) in the kernel configuration, but i have no confirmation if this works. So is it possible for anyone owning these devices to troubleshoot this before the end of this week? It would be nice to get this fixed and include it in the upcoming release... -- cinap
[-- Attachment #1: Type: text/plain, Size: 959 bytes --] On March 31, 2021 4:32:37 PM UTC, cinap_lenrek@felloff.net wrote: >Subject: state of emmc and usb on pi400 and cm4 >I'm in preparation for a new 9front release, >fixing penting issues. > >I have confirmation that the XHCI (USB3) works >now on the pi400, but there are still issues with >the sdcard. > >On the CM4, we have to enable the usbdwc driver >(as it does not have the xhci controller chip) >in the kernel configuration, but i have no >confirmation if this works. > >So is it possible for anyone owning these devices >to troubleshoot this before the end of this week? I don't have a pi400, but I do have a macbook pro, 13", early 2011. With the last release's ISO (8013), it booted and installed fine (albeit with a bunch of i8042 warnings and bcm not functioning) . I resolved my networking issue by tethering to a pinephone. However, with tip I get a kernel panic. I have attached screenshots. Any idea what could be the cause? [-- Attachment #2: IMAG9252.jpg --] [-- Type: image/jpeg, Size: 1550115 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1105 bytes --] Looks like the second image was not attached. On April 1, 2021 6:33:48 PM UTC, Romano <unobe@cpan.org> wrote: > > >On March 31, 2021 4:32:37 PM UTC, cinap_lenrek@felloff.net wrote: >>Subject: state of emmc and usb on pi400 and cm4 >>I'm in preparation for a new 9front release, >>fixing penting issues. >> >>I have confirmation that the XHCI (USB3) works >>now on the pi400, but there are still issues with >>the sdcard. >> >>On the CM4, we have to enable the usbdwc driver >>(as it does not have the xhci controller chip) >>in the kernel configuration, but i have no >>confirmation if this works. >> >>So is it possible for anyone owning these devices >>to troubleshoot this before the end of this week? > >I don't have a pi400, but I do have a macbook pro, 13", early 2011. >With the last release's ISO (8013), it booted and installed fine >(albeit with a bunch of i8042 warnings and bcm not functioning) . I >resolved my networking issue by tethering to a pinephone. However, with >tip I get a kernel panic. I have attached screenshots. Any idea what >could be the cause? [-- Attachment #2: IMAG9253.jpg --] [-- Type: image/jpeg, Size: 1549944 bytes --]
i dont see a kernelpanic here. it seems just that it locks up as soon as it tries to enable the broadcom ethernet? Does the bcm ethernet work before? and i see that we run out of conf.mem[] slots (is this 386 or amd64 kernel?). The easiest is to just increase the number of Confmem slots in pc64/dat.h: - Confmem mem[16]; /* physical memory */ + Confmem mem[64]; /* physical memory */ Can you be more specific on what is the regression here? -- cinap
[-- Attachment #1: Type: text/plain, Size: 1310 bytes --] On April 1, 2021 7:03:37 PM UTC, cinap_lenrek@felloff.net wrote: >i dont see a kernelpanic here. > >it seems just that it locks up as soon as it tries to enable the >broadcom ethernet? > >Does the bcm ethernet work before? It initializes, and can send packets, but never receives any. >and i see that we run out of conf.mem[] slots (is this 386 or amd64 >kernel?). amd64 >The easiest is to just increase the number of Confmem slots in >pc64/dat.h: > >- Confmem mem[16]; /* physical memory */ >+ Confmem mem[64]; /* physical memory */ > >Can you be more specific on what is the regression here? I know I've replied with my results off-list to your other email you sent, but hadn't tried this yet. I still get a machine check error, but the inital boot text has a lot of 'xinit' errors. I then commented out the bcm line in pc64 and rebuilt the kernel. That got me a little farther, but now loading hjfs with -m 581 I get an out of memory error. If I use -m 128, I get to rio. Then, if I switch back Confmem to use 16 instead of 64, I still grt the meminit errors but successfully boot using -m 581 with hjfs. (I noticed that the 64 for Confmem set aside a lot more for the kernel and loads more mem overall, but left little for user mem). Hopefully some of this is helpful. [-- Attachment #2: IMAG9254.jpg --] [-- Type: image/jpeg, Size: 1549830 bytes --]
This is why we'r loosing amlsost 2GB of user memory because of the high fragmentation of the memory map. The xinit errors are due to us running out of pallocmem slots. change the Palloc struct in /sys/src/9/port/portdat.h: - Pallocmem mem[16]; /* physical user page banks */ + Pallocmem mem[32]; /* physical user page banks */ We could also try to minimize the memory loss by sorting the Conf.mem[] array by region size. For the machine check, do you confirm that it is related to the bcm ethernet driver? And when you removed the driver that it went away? -- cinap
A quick follow up on the Pallocmem slots. I just eleminated the array in the last commit, as we can caclculate the user page allocation from the conf.mem[] array, so the xinit errors can be avoided completely. Can you confirm that this works on the macbook with just increasing the conf.mem[] array size? -- cinap
On April 2, 2021 2:31:24 PM UTC, cinap_lenrek@felloff.net wrote: >This is why we'r loosing amlsost 2GB of user memory because >of the high fragmentation of the memory map. > >The xinit errors are due to us running out of pallocmem slots. > >change the Palloc struct in /sys/src/9/port/portdat.h: > >- Pallocmem mem[16]; /* physical user page banks */ >+ Pallocmem mem[32]; /* physical user page banks */ Updated, and was able to boot. >We could also try to minimize the memory loss by sorting the >Conf.mem[] array by region size. > >For the machine check, do you confirm that it is related to >the bcm ethernet driver? And when you removed the driver >that it went away? Yes, I removed the bcm driver and that's how I was able to boot successfully before changing Pallocmem.
ok, i'll stop trying to get this macbook working in this release as we obviously need to do more work with etherbcm to get it supported out of the box. -- cinap
On April 2, 2021 6:31:56 PM UTC, cinap_lenrek@felloff.net wrote: >A quick follow up on the Pallocmem slots. > >I just eleminated the array in the last commit, as we can >caclculate the user page allocation from the conf.mem[] >array, so the xinit errors can be avoided completely. > >Can you confirm that this works on the macbook with >just increasing the conf.mem[] array size? I updated and built two ISOs, one with etherbcm added back in to pc64 and one without. The one without bcm boots, but slightly less overall mem is found, the difference being kernel data. Initial: 4009MB memory: 1688M kernel data, 2321M user, 2946M swap vs changeset 8390: 3928MB memory: 1607M kernel data, 2321M user, 2946M swap Both kmesgs are available at https://blog.fallglow.com/misc/mbpro The other ISO, in which I added back in etherbcm, causes the same machine check error as before.
unsubscribe
unsubscribe
Trying to do an install on a remote server via ssh that has qemu. I suppose i'm doing this with -nographic kind of like qemu-system-x86_64 -serial stdio 9front.img -boot d 9front-xxxx-i386.iso -m 1024 With pipes such as /tmp/guest.in /tmp/guest.out I'm receiving data. Booting from DVD/CD... *e820 ..... ... ... cdboot=yes mouseport=ask monitor=ask vgasize=ask bootfile=/386/9pc But it stops at that last line and nothing. Any thoughts or recommendations? Is it possible? Or do I have to build the image local then copy the 9front.img to remote system. I worry that I will run into same situation where it gets stuck.
10.01.2022 09:44:51 thinktankworkspaces@gmail.com:
> Trying to do an install on a remote server via ssh that has qemu.
>
> I suppose i'm doing this with -nographic
>
> kind of like qemu-system-x86_64 -serial stdio 9front.img -boot d
> 9front-xxxx-i386.iso -m 1024
>
> With pipes such as /tmp/guest.in /tmp/guest.out
>
> I'm receiving data.
>
> Booting from DVD/CD... *e820 ..... ... ... cdboot=yes
> mouseport=ask monitor=ask vgasize=ask bootfile=/386/9pc
>
>
> But it stops at that last line and nothing. Any thoughts or
> recommendations? Is it possible? Or do I have to build the image
> local then copy the 9front.img to remote system. I worry that I will
> run into same situation where it gets stuck.
Please check plan9.ini(8) man page and look for console=. I believe
that's what you want/need.
I can't give more advise since I didn't use it (yet).
sirjofri
-------- Original Message --------
> Trying to do an install on a remote server via ssh that has qemu.
>
> I suppose i'm doing this with -nographic
>
> kind of like qemu-system-x86_64 -serial stdio 9front.img -boot d
> 9front-xxxx-i386.iso -m 1024
>
> With pipes such as /tmp/guest.in /tmp/guest.out
>
> I'm receiving data.
>
> Booting from DVD/CD... *e820 ..... ... ... cdboot=yes
> mouseport=ask monitor=ask vgasize=ask bootfile=/386/9pc
>
>
> But it stops at that last line and nothing. Any thoughts or
> recommendations? Is it possible? Or do I have to build the image
> local then copy the 9front.img to remote system. I worry that I will
> run into same situation where it gets stuck.
>
try console=0.
(before 9boot timeouts and tries to boot)
[-- Attachment #1: Type: text/plain, Size: 389 bytes --] Okay this is where it get confusing. So I suspect I mount the 9front-xxxx=i386.iso. Which is generally in read only mode. Copy the contents into another directory and edit the plan9.ini file. Then repackage the iso with the altered .ini file and reset the boot record? Now I have a new but modified iso that has console=0. I can then try to install it on my target remote system via ssh/ [-- Attachment #2: Type: message/rfc822, Size: 4319 bytes --] From: sirjofri <sirjofri+ml-9front@sirjofri.de> To: 9front@9front.org Subject: Re: [9front] Date: Mon, 10 Jan 2022 10:21:56 +0000 (UTC) Message-ID: <3cd7037b-6fa3-4ebd-b602-e65f6989872e@sirjofri.de> 10.01.2022 09:44:51 thinktankworkspaces@gmail.com: > Trying to do an install on a remote server via ssh that has qemu. > > I suppose i'm doing this with -nographic > > kind of like qemu-system-x86_64 -serial stdio 9front.img -boot d > 9front-xxxx-i386.iso -m 1024 > > With pipes such as /tmp/guest.in /tmp/guest.out > > I'm receiving data. > > Booting from DVD/CD... *e820 ..... ... ... cdboot=yes > mouseport=ask monitor=ask vgasize=ask bootfile=/386/9pc > > > But it stops at that last line and nothing. Any thoughts or > recommendations? Is it possible? Or do I have to build the image > local then copy the 9front.img to remote system. I worry that I will > run into same situation where it gets stuck. Please check plan9.ini(8) man page and look for console=. I believe that's what you want/need. I can't give more advise since I didn't use it (yet). sirjofri
10.01.2022 18:25:59 thinktankworkspaces@gmail.com:
> Okay this is where it get confusing. So I suspect I mount the
> 9front-xxxx=i386.iso. Which is generally in read only mode. Copy the
> contents into another directory and edit the plan9.ini file. Then
> repackage the iso with the altered .ini file and reset the boot
> record? Now I have a new but modified iso that has console=0. I can
> then try to install it on my target remote system via ssh/
I guess after dd'ing the iso to a usb drive you can just edit the
plan9.ini file in the fat directory. It's not so easy when having to deal
with CDs for obvious reasons.
However, you should have luck with mounting a copy of the iso, changing
the file (and saving the iso), then overwriting the first sector(s) with
the contents of the original iso. Make soure you don't overwrite the FAT
and contents, the partition tables should be the same anyways.
It's also possible to generate a fresh iso with your settings if you have
an installed 9front system. You wouldn't need to run sysupdates after
installation, but this is definitely more work.
Disclaimer: I never did any of these things with 9front.
Good luck
sirjofri
[-- Attachment #1: Type: text/plain, Size: 1642 bytes --] Super frustrating. I'm sure I'm making it more difficult I tried following 4.2.2.1 It seems like things should be easier. 9bootfat, 9pc, ini and 9front.iso. I think the frustrating part was being stuck dealing with a usb device. I don't care about thumb drives. All of this should be accomplished with an iso or 9front.bin or something similar. I ended up doing a dd from /dev/SDUxxx -of cd.iso But it was exactly 32G image. I have a limitation because its on AWS with an EBS of 32G maximum. In theory I should have been mount the ISO and dump the data, then modify ini. But how in the world do you write the mbr you can't do that to a directory disk/mbr -r mbr /dev/sdUxxx So really I'm not sure how iso's are created in 9front. I suspect some sort of rockridge format and a generic bootloader. Here is what I ended up doing. I fired up qemu locally and performed the install. Then I logged in and changed the ini file and added console=0. Then I copied the 9front.img to the AWS ec2 instance. Everything came up fine text mode. Nice! and thak you for the help. Honestly I would like to use the ec2 bare metal. Its already a hypervisor. I just don't know what to do to make that happen. I suspect I would need to dump the data into another EBS then force the EC2 to load it. But i'm also not sure of the files required beyond digging into inst/start and looking at the rc scripts. Or a docker would be nice. I saw a docker out there but it was two years old. It also ran on alpine linux, so someone manged to copy some files over. Maybe I don't want docker. Bare metal is better any thoughts would be much appreciated. [-- Attachment #2: Type: message/rfc822, Size: 4587 bytes --] From: sirjofri <sirjofri+ml-9front@sirjofri.de> To: 9front@9front.org Subject: Re: [9front] Date: Mon, 10 Jan 2022 23:33:38 +0000 (UTC) Message-ID: <89cc4583-2f86-49f0-98b6-69dec8c45816@sirjofri.de> 10.01.2022 18:25:59 thinktankworkspaces@gmail.com: > Okay this is where it get confusing. So I suspect I mount the > 9front-xxxx=i386.iso. Which is generally in read only mode. Copy the > contents into another directory and edit the plan9.ini file. Then > repackage the iso with the altered .ini file and reset the boot > record? Now I have a new but modified iso that has console=0. I can > then try to install it on my target remote system via ssh/ I guess after dd'ing the iso to a usb drive you can just edit the plan9.ini file in the fat directory. It's not so easy when having to deal with CDs for obvious reasons. However, you should have luck with mounting a copy of the iso, changing the file (and saving the iso), then overwriting the first sector(s) with the contents of the original iso. Make soure you don't overwrite the FAT and contents, the partition tables should be the same anyways. It's also possible to generate a fresh iso with your settings if you have an installed 9front system. You wouldn't need to run sysupdates after installation, but this is definitely more work. Disclaimer: I never did any of these things with 9front. Good luck sirjofri
12.01.2022 02:16:57 thinktankworkspaces@gmail.com: > Super frustrating. I'm sure I'm making it more difficult > > I tried following 4.2.2.1 > > It seems like things should be easier. 9bootfat, 9pc, ini and > 9front.iso. I think the frustrating part was being stuck dealing with a > usb device. I don't care about thumb drives. All of this should > be accomplished with an iso or 9front.bin or something similar. > > I ended up doing a dd from /dev/SDUxxx -of cd.iso > > But it was exactly 32G image. I have a limitation because its on > AWS with an EBS of 32G maximum. Since you dd'd the iso to the usb drive before you can also just dd that amount of data back to an image file. I don't exactly know the parameter now, but the man page lists it. > In theory I should have been mount the ISO and dump the data, then > modify ini. But how in the world do you write the mbr you can't do > that to a directory > > disk/mbr -r mbr /dev/sdUxxx The sdUxxx directory contails lots of files for lowlevel interaction. E.g it contains a ctl and data, and a file for each partition you can mount. In this case I'm pretty sure you can call the command on the data file (which is the disk ignoring all partitions). > So really I'm not sure how iso's are created in 9front. I suspect > some sort of rockridge format and a generic bootloader. 9front has its own bootloader, at least for x86/amd64 standard machines. However, some people got 9front booting with other linux bootloaders. As for the iso, I can't really help you. I never created an iso (I planned to do it) on 9front with the 9front system. However, there are commands and filesystem that support the generation of iso files in general. I did it some time ago since it is easier to burn an iso to cd than a whole directory of files. lookman iso > Here is what I ended up doing. I fired up qemu locally and performed > the install. Then I logged in and changed the ini file and added > console=0. Then I copied the 9front.img to the AWS ec2 instance. > Everything came up fine text mode. Nice! and thak you for the help. Have you tried dding the iso to a usb drive and edit the file in the fat directory? (And dding back) It might even be possible that you can mount the iso somehow and change the file there. I'm not sure about it and I don't know how it handles the mbr then... I hope this helps sirjofri
> [...] > > Since you dd'd the iso to the usb drive before you can also just dd > that amount of data back to an image file. I don't exactly know the > parameter now, but the man page lists it. > > [...] As long as you're on P9, that should work: dd -if /dev/sdXXX/disk -of outfile.iso -bs 4k -count 8192k as long as the product of bs and count args are exactly the 32 GB. With Unix/linux/bsd it should be the same, except that args are as in MVS (if=/dev/sdY of=outfile.iso etc.). Problem could be that the initial dd when preparing the usb went to the (1st?) partition of the USB instead of the raw (whole) device. Maybe it's possible to read&compare the first few bytes, e.g. dd -if /dev/sdXXX -bs 1b -count 1 | xd -1x the same for image.iso > The sdUxxx directory contails lots of files for lowlevel interaction. > E.g it contains a ctl and data, and a file for each partition you can > mount. > > In this case I'm pretty sure you can call the command on the data > file (which is the disk ignoring all partitions). > > [...] > > 9front has its own bootloader, at least for x86/amd64 standard > machines. However, some people got 9front booting with other linux > bootloaders. correct, but IMO that works like: BIOS -> "other bootloader" -> 9pc/9pc64 -> plan9 kernel where the 9pc/9pc64 plan9 bootloader still needs to be in a given position or to be contiguous on disk - refer "bootloader magic" or the like somewhere in the fqa. But didn't try that with qemu at all, IIRC that was the init. problem. > [...] > > Have you tried dding the iso to a usb drive and edit the file in the > fat directory? (And dding back) > > It might even be possible that you can mount the iso somehow and > change the file there. I'm not sure about it and I don't know how it > handles the mbr then... For little edits NOT violating block boundaries, even in-binary-edits are fine, did that a few time using sed, but you have to double (triple,...) check the boundaries before. Or you could even split the image file apart (with dd) into prefix + file contents + suffix, edit the 2nd one, compare size and reassemble, if it's contiguous - but all that's bit dangerous.
12.01.2022 10:29:48 Eckard Brauer <eckard.brauer@gmx.de>:
>> 9front has its own bootloader, at least for x86/amd64 standard
>> machines. However, some people got 9front booting with other linux
>> bootloaders.
>
> correct, but IMO that works like:
>
> BIOS -> "other bootloader" -> 9pc/9pc64 -> plan9 kernel
>
> where the 9pc/9pc64 plan9 bootloader still needs to be in a given
> position or to be contiguous on disk - refer "bootloader magic" or the
> like somewhere in the fqa.
Afaik the 9pc/64 is the kernel. At least that's what is compiled when cd
/sys/src/9/pc64 && mk install.
But there's also the minimal initial disk or something like that,
containing some basic programs for networking etc.
sirjofri
correct, and the plan 9 kernel supports being directly loaded by linux
bootloaders just like a linux kernel (where you would have vmlinuz for
example).
On 1/12/22, sirjofri <sirjofri+ml-9front@sirjofri.de> wrote:
>
> 12.01.2022 10:29:48 Eckard Brauer <eckard.brauer@gmx.de>:
>
>>> 9front has its own bootloader, at least for x86/amd64 standard
>>> machines. However, some people got 9front booting with other linux
>>> bootloaders.
>>
>> correct, but IMO that works like:
>>
>> BIOS -> "other bootloader" -> 9pc/9pc64 -> plan9 kernel
>>
>> where the 9pc/9pc64 plan9 bootloader still needs to be in a given
>> position or to be contiguous on disk - refer "bootloader magic" or the
>> like somewhere in the fqa.
>
> Afaik the 9pc/64 is the kernel. At least that's what is compiled when cd
> /sys/src/9/pc64 && mk install.
>
> But there's also the minimal initial disk or something like that,
> containing some basic programs for networking etc.
>
> sirjofri
>
clues here: http://fqa.9front.org/fqa5.html#5.3 sl
[-- Attachment #1: Type: text/plain, Size: 353 bytes --] Simply brilliant. I need to save this email somewhere and remember this logic. But honestly I'm tired of qemu. I really need to read up on how the booatloader works and how to bootstrap an AWS ec2 instance. I never used 'xd' command before so thats interesting. There seems to be some sort of syntatical magic here in plan9 thats missing in other OS's [-- Attachment #2: Type: message/rfc822, Size: 8663 bytes --] From: Eckard Brauer <eckard.brauer@gmx.de> To: 9front@9front.org Subject: Re: [9front] Date: Wed, 12 Jan 2022 10:29:48 +0100 Message-ID: <20220112102948.4a6d7d53@gmx.de> > [...] > > Since you dd'd the iso to the usb drive before you can also just dd > that amount of data back to an image file. I don't exactly know the > parameter now, but the man page lists it. > > [...] As long as you're on P9, that should work: dd -if /dev/sdXXX/disk -of outfile.iso -bs 4k -count 8192k as long as the product of bs and count args are exactly the 32 GB. With Unix/linux/bsd it should be the same, except that args are as in MVS (if=/dev/sdY of=outfile.iso etc.). Problem could be that the initial dd when preparing the usb went to the (1st?) partition of the USB instead of the raw (whole) device. Maybe it's possible to read&compare the first few bytes, e.g. dd -if /dev/sdXXX -bs 1b -count 1 | xd -1x the same for image.iso > The sdUxxx directory contails lots of files for lowlevel interaction. > E.g it contains a ctl and data, and a file for each partition you can > mount. > > In this case I'm pretty sure you can call the command on the data > file (which is the disk ignoring all partitions). > > [...] > > 9front has its own bootloader, at least for x86/amd64 standard > machines. However, some people got 9front booting with other linux > bootloaders. correct, but IMO that works like: BIOS -> "other bootloader" -> 9pc/9pc64 -> plan9 kernel where the 9pc/9pc64 plan9 bootloader still needs to be in a given position or to be contiguous on disk - refer "bootloader magic" or the like somewhere in the fqa. But didn't try that with qemu at all, IIRC that was the init. problem. > [...] > > Have you tried dding the iso to a usb drive and edit the file in the > fat directory? (And dding back) > > It might even be possible that you can mount the iso somehow and > change the file there. I'm not sure about it and I don't know how it > handles the mbr then... For little edits NOT violating block boundaries, even in-binary-edits are fine, did that a few time using sed, but you have to double (triple,...) check the boundaries before. Or you could even split the image file apart (with dd) into prefix + file contents + suffix, edit the 2nd one, compare size and reassemble, if it's contiguous - but all that's bit dangerous.
[-- Attachment #1: Type: text/plain, Size: 1256 bytes --] No. Is it that easy. can I just swap out vmlinuz with 9bootfat and 9pc I feel like when an EC2 is launched for the first time its amazon linux or ubuntu which ever you pick. By default it picks up a t3.micro which also includes an EBS of about 2G. Kind of small but you can resize it. The mbr is is already written and the bootlaoder is vmlinuz. If I swap it out I'm still in an ext2 or ext3/4 file system so it wouldn't matter. So basically I create another EBS then tell linux to format it fdisk and set fat then format it. I can set mbr. But then its a matter of placing the files in the right directories on that new EBS. Then telling my ec2 linux to reboot but on a different ebs volume and boom! I'm booting in 9front. I still feel this is a waste or I'm doing it in the wrong order. So right now I have my ec2 running qemu and its working fine. I could also try and tell AWS to spin up another EBS volume and creatively mount it then run dd if=/mnt/9front.img of=/dev/to_new_volume etc... with the right flags. Then tell ec2 to boot on a new volume. I guess the only benefit is speed because qemu works but I was hoping to retire it. At this moment I'm starting to feel lazy do I push forward or settle. I need to think. Thanks again! [-- Attachment #2: Type: message/rfc822, Size: 6202 bytes --] From: hiro <23hiro@gmail.com> To: 9front@9front.org Subject: Re: [9front] Date: Wed, 12 Jan 2022 14:40:09 +0100 Message-ID: <CAFSF3XNCiHtVyg=p7jnjuRYWA3LvfMceRH__gqOq-y97oc9LzA@mail.gmail.com> correct, and the plan 9 kernel supports being directly loaded by linux bootloaders just like a linux kernel (where you would have vmlinuz for example). On 1/12/22, sirjofri <sirjofri+ml-9front@sirjofri.de> wrote: > > 12.01.2022 10:29:48 Eckard Brauer <eckard.brauer@gmx.de>: > >>> 9front has its own bootloader, at least for x86/amd64 standard >>> machines. However, some people got 9front booting with other linux >>> bootloaders. >> >> correct, but IMO that works like: >> >> BIOS -> "other bootloader" -> 9pc/9pc64 -> plan9 kernel >> >> where the 9pc/9pc64 plan9 bootloader still needs to be in a given >> position or to be contiguous on disk - refer "bootloader magic" or the >> like somewhere in the fqa. > > Afaik the 9pc/64 is the kernel. At least that's what is compiled when cd > /sys/src/9/pc64 && mk install. > > But there's also the minimal initial disk or something like that, > containing some basic programs for networking etc. > > sirjofri >
[-- Attachment #1: Type: text/plain, Size: 53 bytes --] OMG thanks. So the mk files handles the ISO creation [-- Attachment #2: Type: message/rfc822, Size: 3260 bytes --] From: Stanley Lieber <sl@stanleylieber.com> To: 9front@9front.org Subject: Re: [9front] Date: Wed, 12 Jan 2022 14:18:24 +0000 Message-ID: <D9C8C87A-E18D-4127-B204-31E6C8731A28@stanleylieber.com> clues here: http://fqa.9front.org/fqa5.html#5.3 sl
On 1/12/22, thinktankworkspaces@gmail.com <thinktankworkspaces@gmail.com> wrote: > No. Is it that easy. can I just swap out vmlinuz with 9bootfat and 9pc https://fqa.9front.org/fqa3.html#3.3.1.2.1
it is supporting the multiboot standard. any multiboot capable bootloader (grub, coreboot, qemu, syslinux, linux kexec) can start our kernel file directly, the plan9.ini is (optionally) passed as a "module" (like initrd). this is done by having a second entry point in the kernel dedicated for multiboot, which also handles things like getting the framebuffer configuration and memory map from multiboot parameters and converting them into internal plan9.ini format. 9boot and /dev/reboot (yes, you can start a plan9 kernel from a plan9 kernel) enter the kernel thru the classical a.out entry point. -- cinap
unsubscribe
Quoth roy niang <roy@royniang.com>:
> unsubscribe
You send that at 9front-owner@9front.org :)