Werner changed the topic of #armbian to: armbian - Linux for ARM development boards | www.armbian.com | Github: github.com/armbian | Commits: #armbian-commits | Developer talk: #armbian-devel | Forum/Twitter feed: #armbian-rss | Type 'help' for help | Logs: -> irc.armbian.com
flyback has quit [Ping timeout: 252 seconds]
flyback has joined #armbian
ced117 has quit [Ping timeout: 252 seconds]
ced117 has joined #armbian
ced117 has quit [Changing host]
ced117 has joined #armbian
califax- has joined #armbian
califax has quit [Ping timeout: 276 seconds]
califax- is now known as califax
Hiccup has joined #armbian
CrashTestDummy has joined #armbian
CrashTestDummy3 has quit [Ping timeout: 246 seconds]
ddurst has quit [Ping timeout: 250 seconds]
ddurst has joined #armbian
Hiccup has quit [Remote host closed the connection]
archetech has joined #armbian
ddurst has quit [Ping timeout: 265 seconds]
f476 has quit [Ping timeout: 264 seconds]
archetech has quit [Ping timeout: 260 seconds]
archetech has joined #armbian
f476 has joined #armbian
ddurst has joined #armbian
slacker_HD has joined #armbian
slacker_HD has quit [Client Quit]
<Armbian-Discord>
<kprasadvnsi> The amount of upstream patches Mediatek is submitting for their MT8183 is just 180 turn from what they usually do.🤣
<Armbian-Discord>
<rpardini> I'm indeed impressed. Anyone has such a beast?
<Armbian-Discord>
<kprasadvnsi> It ship into tablet and Chrombooks that usually go for around $250-$350
<Armbian-Discord>
<rpardini> Yeah, but I only found one (Acer?) thats EUR 500+
<Armbian-Discord>
<rpardini> And they're shipping ChromeOS with 32-bit userland still
<Armbian-Discord>
<rpardini> so not all is good
<Armbian-Discord>
<kprasadvnsi> Here in India HP Chrombook 11a selling for about $320
<Armbian-Discord>
<rpardini> Could not find that, 11a's for sale here are Intel Celeron N3350 (?!)
<Armbian-Discord>
<kprasadvnsi> My hope is that all this upstreaming work by Mediatek will help with their p60, p70 SoC used in mid range phone. The internals are basically the same.
archetech has quit [Quit: Konversation terminated!]
Proxysna has joined #armbian
archetyp has joined #armbian
CrashTestDummy2 has joined #armbian
CrashTestDummy has quit [Ping timeout: 252 seconds]
Hiccup has joined #armbian
f476 has quit [Remote host closed the connection]
sunshavi has quit [Remote host closed the connection]
sunshavi has joined #armbian
phipli has quit [Ping timeout: 252 seconds]
Fleck has quit [Ping timeout: 252 seconds]
Flecks has joined #armbian
phipli has joined #armbian
[TheBug] has quit [Ping timeout: 252 seconds]
[TheBug] has joined #armbian
Hiccup has quit [Remote host closed the connection]
f476 has joined #armbian
archetyp has quit [Quit: Leaving]
archetyp has joined #armbian
[TheBug] has quit [Changing host]
[TheBug] has joined #armbian
<nekomancer[m]>
ban mediatek!
wd has quit [Ping timeout: 252 seconds]
<Armbian-Discord>
<Tonymac32> Lol as opposed to any of these other beacons of quality we use?
<c0rnelius>
:)
Redentor has joined #armbian
wd has joined #armbian
<Armbian-Discord>
<RichNeese> mr TM32 what are you doing
<steev>
since y'all build a lot of images and test them... have y'all seen ext4 just drop its journal while resizing the filesystem?
<c0rnelius>
What are you doing to resize? Like whats ur method of attack?
<[TheBug]>
would sound like you somehow resized it maybe too small and eliminated the space the journal was stored in the process?
<[TheBug]>
because otherwise it will force an fsck in advance which should confirm the journal state before allowing a resize
<[TheBug]>
and then once you finish resize you should ALWAYS fsck again
<[TheBug]>
so if something does break it is repaired
<[TheBug]>
before you start using the system again
<c0rnelius>
I normally use growpart and than resize2fs... Which is usually pretty kosher. You should also force the fsck in the cmdline `fsck.repair=yes`
Redentor has quit [Quit: Leaving]
<stipa>
kprasadvnsi: what are the odds of those phones having fully functional linux support?
<steev>
c0rnelius: parted to increase to ~100%, and then resize2fs, but for whatever reason *every* time i use ext4, it drops the journal. on armhf devices, a reboot and fsck, it's fine but arm64 devices the journal is just gonzo
<[TheBug]>
are you fscking before resize2fs?
<steev>
i am not
<[TheBug]>
if not you should be doing an fsck.ext4 -f -y /dev
<[TheBug]>
before you resize
<steev>
interesting, i've never had to do that before
<[TheBug]>
then once resize is completed
<[TheBug]>
this makes sure the file system you are resizing is cleaned and not super fragmented
<steev>
well it's on the first boot, so i'd hope it is
<steev>
isn't*
<steev>
i do fsck it before booting and there are no issues
<c0rnelius>
You aren't losing ur PARTUUID during resize on firstboot when on armhf? Anyway, I would place a force fsck in the cmdline and look into growpart. Its a very simple way of achieving the said goal with zero effort.
<steev>
yeah i'm familiar with growpart, i think i might just switch to it
<c0rnelius>
You only need the script and the depends... which is just fdisk I thinks?
<[TheBug]>
I was trying to find a good reference for this and I have found that a lot of references do lack the direction to fsck before resize2fs but any good documentation on using resize2fs should provide the steps of , change the partition, fsck, resize2fs, fsck again
<c0rnelius>
Good thing about growpart is works with pretty much everything. You just need to switch up the resize depending on the FSTYPE.
<[TheBug]>
growpart is essentiall just a frontend for resize2fs if I read correctly, so I guess if just following its context is easier than manually going through the process it could be the easier approach